Re: Xen Project Security Process Whitepaper v1 is ready for community review

Re: Xen Project Security Process Whitepaper v1 is ready for community review

[Lars Kurth]

Hi all,

I tried to summarize this thread (also see https://lists.xenproject.org/archives/html/xen-devel/2018-05/threads.html#01127), CC'ing everyone that contributed or requested to be on the thread.  I also moved comments into https://docs.google.com/document/d/1FbGV4ZZB9OU8SI4b9ntnM-l6NaQLND8Yfd9u11V5Q5A/edit# 

2.2.2 A XSA-Reissues
I still need to do some number crunching based on a script I have not written yet.

2.2.4. A Too many security supported Xen releases
It seems that the 6 months cycle may be too short. The suggestion was to run a similar consultation about release cycle compared to this. Originally, it was primarily HW vendors pushing for shorter release cycles. I will bring this up at the Summit in a Design Session and report back to the list.

R1) Recommendation: Batching
There seems to be sufficient consensus to spell out batching as an explicit option in the security policy, as long as it is not mandatory. I think it also makes sense to clarify the "Embargo and Disclosure Schedule" section: it affords quite a lot of flexibility to the security team, but it seems that some people are interpreting the 1 week for a fix + 2 weeks embargo as fixed, which at best means the text is not clear enough.

R2) Recommendation: Workload
It seems that my suggestion to not specifically address this through a mechanism in the policy and leave it up to the security team to manage batch size has consensus. Assuming we add batching as an explicit option in the policy, we should also make this explicit.

R3) Recommendation: Predictability
A few people believe that a more predictable XSA release schedule would help. At the same time, there are valid concerns about the security team being overloaded. I am wondering whether we should trial batching towards some undocumented batch release date for a bit and see what the impact is: the policy would allow us to do this. We could also state in the policy that we are trialling this.

2.2.3 B. Git baseline of patches
This created quite a bit of discussion and we did learn a few things:
* From the thread, having to cherry pick a small (around 5-6) patches have to be cherry-picked for XSAs to apply to tarballs this appears to be seen as OK for most users. More patches are a problem
* Recently this issue has become much worse, because some security fixes (or pre-requisites for them) have been developed in public and some XSAs required significant backporting to be able to be run
* A point release has usually <50% security fixes
* There is no appetite amongst existing point release maintainers to maintain a staging branch and an XSA + pre-requisites only branch

In other words, we are at a stale-mate. I see two ways around it
a) Find an additional volunteer to maintain XSA + pre-requisites only branches for releases
b) Find some tooling/test based solution which exposes issues applying XSAs on the last releases of a staging branch for a point release. This is a little bit of a half-baked idea, but it may be worthwhile looking into. 
For example, we could create an OSSTEST, that checks out the last released stable branch and applies outstanding XSAs and pre-requisites based on the meta-info to it (e.g. via xsatool or a variant thereof). This test would fail, if an XSA does not apply, which implies that the pre-requisites are incomplete. If all XSAs apply, we can run the full OSSTEST on it. The test could also produce a list of git commits from staging that include XSAs and pre-requisites that can be applied in order. This should in theory - if doable - help downstreams which are struggling with this problem, while flagging up potential issues to stable maintainers early. Any thoughts? Would this be workable and if so, would it actually help?

Best Regards
Lars

    

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen Project Security Process Whitepaper v1 is ready for community review

[George Dunlap]

On Mon, Jun 4, 2018 at 3:55 PM, Lars Kurth <lars.kurth@citrix.com> wrote:

> 2.2.3 B. Git baseline of patches
> This created quite a bit of discussion and we did learn a few things:
> * From the thread, having to cherry pick a small (around 5-6) patches have to be cherry-picked for XSAs to apply to tarballs this appears to be seen as OK for most users. More patches are a problem
> * Recently this issue has become much worse, because some security fixes (or pre-requisites for them) have been developed in public and some XSAs required significant backporting to be able to be run
> * A point release has usually <50% security fixes
> * There is no appetite amongst existing point release maintainers to maintain a staging branch and an XSA + pre-requisites only branch
>
> In other words, we are at a stale-mate. I see two ways around it
> a) Find an additional volunteer to maintain XSA + pre-requisites only branches for releases
> b) Find some tooling/test based solution which exposes issues applying XSAs on the last releases of a staging branch for a point release. This is a little bit of a half-baked idea, but it may be worthwhile looking into.
> For example, we could create an OSSTEST, that checks out the last released stable branch and applies outstanding XSAs and pre-requisites based on the meta-info to it (e.g. via xsatool or a variant thereof). This test would fail, if an XSA does not apply, which implies that the pre-requisites are incomplete. If all XSAs apply, we can run the full OSSTEST on it. The test could also produce a list of git commits from staging that include XSAs and pre-requisites that can be applied in order. This should in theory - if doable - help downstreams which are struggling with this problem, while flagging up potential issues to stable maintainers early. Any thoughts? Would this be workable and if so, would it actually help?

Here's a question:  What would it take for most downstreams to update
to staging when a public release was made?

Suppose we did this:
1. When we predisclose an issue, freeze the stable branches until the
embargo lifts -- no backports.
2. When the embargo lifts, addition to the patches, we release a new
point release, complete with signed tag and tarball.
3. We only do non-security point releases if we go 4 months without a
security-prompted point release.

At the moment the release process is quite manual, which isn't
terrible for one point release every 4 months per supported release,
but would significantly increase the workload if we did it for every
supported version for every XSA.  We'd have to invest quite a bit in
automating that process, which would make it only worth it if a
significant number of people would find that useful.

The other thing we could probably do is write a tool which would
automatically determine the minimum number of 'extra' patches to
backport from the stable branch to allow the patch to apply and build.
The issue with that, of course, is that such a branch will be an
artificial branch which has almost no testing.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen Project Security Process Whitepaper v1 is ready for community review

[Marek Marczykowski]

[-- Attachment #1.1: Type: text/plain, Size: 4596 bytes --]

On Tue, Jun 05, 2018 at 11:34:28AM +0100, George Dunlap wrote:
> On Mon, Jun 4, 2018 at 3:55 PM, Lars Kurth <lars.kurth@citrix.com> wrote:
> 
> > 2.2.3 B. Git baseline of patches
> > This created quite a bit of discussion and we did learn a few things:
> > * From the thread, having to cherry pick a small (around 5-6) patches have to be cherry-picked for XSAs to apply to tarballs this appears to be seen as OK for most users. More patches are a problem
> > * Recently this issue has become much worse, because some security fixes (or pre-requisites for them) have been developed in public and some XSAs required significant backporting to be able to be run
> > * A point release has usually <50% security fixes
> > * There is no appetite amongst existing point release maintainers to maintain a staging branch and an XSA + pre-requisites only branch
> >
> > In other words, we are at a stale-mate. I see two ways around it
> > a) Find an additional volunteer to maintain XSA + pre-requisites only branches for releases
> > b) Find some tooling/test based solution which exposes issues applying XSAs on the last releases of a staging branch for a point release. This is a little bit of a half-baked idea, but it may be worthwhile looking into.
> > For example, we could create an OSSTEST, that checks out the last released stable branch and applies outstanding XSAs and pre-requisites based on the meta-info to it (e.g. via xsatool or a variant thereof). This test would fail, if an XSA does not apply, which implies that the pre-requisites are incomplete. If all XSAs apply, we can run the full OSSTEST on it. The test could also produce a list of git commits from staging that include XSAs and pre-requisites that can be applied in order. This should in theory - if doable - help downstreams which are struggling with this problem, while flagging up potential issues to stable maintainers early. Any thoughts? Would this be workable and if so, would it actually help?
> 
> Here's a question:  What would it take for most downstreams to update
> to staging when a public release was made?
> 
> Suppose we did this:
> 1. When we predisclose an issue, freeze the stable branches until the
> embargo lifts -- no backports.
> 2. When the embargo lifts, addition to the patches, we release a new
> point release, complete with signed tag and tarball.
> 3. We only do non-security point releases if we go 4 months without a
> security-prompted point release.

IMO this would significantly ease handling of XSAs, at least for us.
This does mean we'll need to test things using stable branch (not
previous point release) during embargo period - as the point release
would be available only after lifting the embargo, but I think that's
manageable.

What if at the predisclose time there are some commits in staging (not
stable), which breaks things (in terms of osstest)? Would them be
bypassed (XSA applied on top of stable, then rebase staging on top of
new stable)? Or something else?

> At the moment the release process is quite manual, which isn't
> terrible for one point release every 4 months per supported release,
> but would significantly increase the workload if we did it for every
> supported version for every XSA.  We'd have to invest quite a bit in
> automating that process, which would make it only worth it if a
> significant number of people would find that useful.

Alternatively this could be triggered only if there are conflicting
changes in stable branch, since last point release (but free stable
anyway, to not leak info about the patches). This should reduce
probability of very frequent point releases (the more recent point
release is, the more likely XSA will apply without problems).
This could be determined mostly automatically by trying to apply patches
on the most recent point release.

> The other thing we could probably do is write a tool which would
> automatically determine the minimum number of 'extra' patches to
> backport from the stable branch to allow the patch to apply and build.
> The issue with that, of course, is that such a branch will be an
> artificial branch which has almost no testing.

I'm bit worried about such solution, although this is exactly what we do
right now. With exception that a) it isn't automated b) we do testing on
our own (and probably others do to, duplicating this work).

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen Project Security Process Whitepaper v1 is ready for community review

[Jan Beulich]

>>> On 05.06.18 at 13:03, <marmarek@invisiblethingslab.com> wrote:
> On Tue, Jun 05, 2018 at 11:34:28AM +0100, George Dunlap wrote:
>> On Mon, Jun 4, 2018 at 3:55 PM, Lars Kurth <lars.kurth@citrix.com> wrote:
>> 
>> > 2.2.3 B. Git baseline of patches
>> > This created quite a bit of discussion and we did learn a few things:
>> > * From the thread, having to cherry pick a small (around 5-6) patches have 
> to be cherry-picked for XSAs to apply to tarballs this appears to be seen as 
> OK for most users. More patches are a problem
>> > * Recently this issue has become much worse, because some security fixes 
> (or pre-requisites for them) have been developed in public and some XSAs 
> required significant backporting to be able to be run
>> > * A point release has usually <50% security fixes
>> > * There is no appetite amongst existing point release maintainers to 
> maintain a staging branch and an XSA + pre-requisites only branch
>> >
>> > In other words, we are at a stale-mate. I see two ways around it
>> > a) Find an additional volunteer to maintain XSA + pre-requisites only 
> branches for releases
>> > b) Find some tooling/test based solution which exposes issues applying XSAs 
> on the last releases of a staging branch for a point release. This is a 
> little bit of a half-baked idea, but it may be worthwhile looking into.
>> > For example, we could create an OSSTEST, that checks out the last released 
> stable branch and applies outstanding XSAs and pre-requisites based on the 
> meta-info to it (e.g. via xsatool or a variant thereof). This test would 
> fail, if an XSA does not apply, which implies that the pre-requisites are 
> incomplete. If all XSAs apply, we can run the full OSSTEST on it. The test 
> could also produce a list of git commits from staging that include XSAs and 
> pre-requisites that can be applied in order. This should in theory - if 
> doable - help downstreams which are struggling with this problem, while 
> flagging up potential issues to stable maintainers early. Any thoughts? Would 
> this be workable and if so, would it actually help?
>> 
>> Here's a question:  What would it take for most downstreams to update
>> to staging when a public release was made?
>> 
>> Suppose we did this:
>> 1. When we predisclose an issue, freeze the stable branches until the
>> embargo lifts -- no backports.
>> 2. When the embargo lifts, addition to the patches, we release a new
>> point release, complete with signed tag and tarball.
>> 3. We only do non-security point releases if we go 4 months without a
>> security-prompted point release.
> 
> IMO this would significantly ease handling of XSAs, at least for us.
> This does mean we'll need to test things using stable branch (not
> previous point release) during embargo period - as the point release
> would be available only after lifting the embargo, but I think that's
> manageable.
> 
> What if at the predisclose time there are some commits in staging (not
> stable), which breaks things (in terms of osstest)? Would them be
> bypassed (XSA applied on top of stable, then rebase staging on top of
> new stable)? Or something else?

I don't think we should get into the business of re-basing any of the
main branches of xen.git. If anything, then merging. But I further
think we also shouldn't break the strict staging -> stable workflow
with the osstest push gate in between. Some delay between public
disclosure and release of the new stable version will hence be
unavoidable. (Just take the current situation as an example, where
we're blocked on an osstest issue [according to my investigation, at
least] with two stable releases - we simply have to wait for the
osstest issue to be dealt with first, and for the pushes of the
branches then to eventually happen.)

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen Project Security Process Whitepaper v1 is ready for community review

[Marek Marczykowski]

[-- Attachment #1.1: Type: text/plain, Size: 4412 bytes --]

On Tue, Jun 05, 2018 at 05:44:48AM -0600, Jan Beulich wrote:
> >>> On 05.06.18 at 13:03, <marmarek@invisiblethingslab.com> wrote:
> > On Tue, Jun 05, 2018 at 11:34:28AM +0100, George Dunlap wrote:
> >> On Mon, Jun 4, 2018 at 3:55 PM, Lars Kurth <lars.kurth@citrix.com> wrote:
> >> 
> >> > 2.2.3 B. Git baseline of patches
> >> > This created quite a bit of discussion and we did learn a few things:
> >> > * From the thread, having to cherry pick a small (around 5-6) patches have 
> > to be cherry-picked for XSAs to apply to tarballs this appears to be seen as 
> > OK for most users. More patches are a problem
> >> > * Recently this issue has become much worse, because some security fixes 
> > (or pre-requisites for them) have been developed in public and some XSAs 
> > required significant backporting to be able to be run
> >> > * A point release has usually <50% security fixes
> >> > * There is no appetite amongst existing point release maintainers to 
> > maintain a staging branch and an XSA + pre-requisites only branch
> >> >
> >> > In other words, we are at a stale-mate. I see two ways around it
> >> > a) Find an additional volunteer to maintain XSA + pre-requisites only 
> > branches for releases
> >> > b) Find some tooling/test based solution which exposes issues applying XSAs 
> > on the last releases of a staging branch for a point release. This is a 
> > little bit of a half-baked idea, but it may be worthwhile looking into.
> >> > For example, we could create an OSSTEST, that checks out the last released 
> > stable branch and applies outstanding XSAs and pre-requisites based on the 
> > meta-info to it (e.g. via xsatool or a variant thereof). This test would 
> > fail, if an XSA does not apply, which implies that the pre-requisites are 
> > incomplete. If all XSAs apply, we can run the full OSSTEST on it. The test 
> > could also produce a list of git commits from staging that include XSAs and 
> > pre-requisites that can be applied in order. This should in theory - if 
> > doable - help downstreams which are struggling with this problem, while 
> > flagging up potential issues to stable maintainers early. Any thoughts? Would 
> > this be workable and if so, would it actually help?
> >> 
> >> Here's a question:  What would it take for most downstreams to update
> >> to staging when a public release was made?
> >> 
> >> Suppose we did this:
> >> 1. When we predisclose an issue, freeze the stable branches until the
> >> embargo lifts -- no backports.
> >> 2. When the embargo lifts, addition to the patches, we release a new
> >> point release, complete with signed tag and tarball.
> >> 3. We only do non-security point releases if we go 4 months without a
> >> security-prompted point release.
> > 
> > IMO this would significantly ease handling of XSAs, at least for us.
> > This does mean we'll need to test things using stable branch (not
> > previous point release) during embargo period - as the point release
> > would be available only after lifting the embargo, but I think that's
> > manageable.
> > 
> > What if at the predisclose time there are some commits in staging (not
> > stable), which breaks things (in terms of osstest)? Would them be
> > bypassed (XSA applied on top of stable, then rebase staging on top of
> > new stable)? Or something else?
> 
> I don't think we should get into the business of re-basing any of the
> main branches of xen.git. If anything, then merging. But I further
> think we also shouldn't break the strict staging -> stable workflow
> with the osstest push gate in between. Some delay between public
> disclosure and release of the new stable version will hence be
> unavoidable. (Just take the current situation as an example, where
> we're blocked on an osstest issue [according to my investigation, at
> least] with two stable releases - we simply have to wait for the
> osstest issue to be dealt with first, and for the pushes of the
> branches then to eventually happen.)

Makes sense. Does it mean in all the cases point release would happen
with a delay from XSA public release? How long does it take for osstest
to push things (assuming no problems)?

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen Project Security Process Whitepaper v1 is ready for community review

[Jan Beulich]

>>> On 05.06.18 at 14:07, <marmarek@invisiblethingslab.com> wrote:
> On Tue, Jun 05, 2018 at 05:44:48AM -0600, Jan Beulich wrote:
>> >>> On 05.06.18 at 13:03, <marmarek@invisiblethingslab.com> wrote:
>> > On Tue, Jun 05, 2018 at 11:34:28AM +0100, George Dunlap wrote:
>> >> Suppose we did this:
>> >> 1. When we predisclose an issue, freeze the stable branches until the
>> >> embargo lifts -- no backports.
>> >> 2. When the embargo lifts, addition to the patches, we release a new
>> >> point release, complete with signed tag and tarball.
>> >> 3. We only do non-security point releases if we go 4 months without a
>> >> security-prompted point release.
>> > 
>> > IMO this would significantly ease handling of XSAs, at least for us.
>> > This does mean we'll need to test things using stable branch (not
>> > previous point release) during embargo period - as the point release
>> > would be available only after lifting the embargo, but I think that's
>> > manageable.
>> > 
>> > What if at the predisclose time there are some commits in staging (not
>> > stable), which breaks things (in terms of osstest)? Would them be
>> > bypassed (XSA applied on top of stable, then rebase staging on top of
>> > new stable)? Or something else?
>> 
>> I don't think we should get into the business of re-basing any of the
>> main branches of xen.git. If anything, then merging. But I further
>> think we also shouldn't break the strict staging -> stable workflow
>> with the osstest push gate in between. Some delay between public
>> disclosure and release of the new stable version will hence be
>> unavoidable. (Just take the current situation as an example, where
>> we're blocked on an osstest issue [according to my investigation, at
>> least] with two stable releases - we simply have to wait for the
>> osstest issue to be dealt with first, and for the pushes of the
>> branches then to eventually happen.)
> 
> Makes sense. Does it mean in all the cases point release would happen
> with a delay from XSA public release? How long does it take for osstest
> to push things (assuming no problems)?

A day or two. Remember that osstest will be quite busy at such times,
testing all active branches at the same time. But please don't forget:
"No problems" is rather a rare exception than the rule.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen Project Security Process Whitepaper v1 is ready for community review

[Steven Haigh]

[-- Attachment #1.1: Type: text/plain, Size: 3943 bytes --]

On Tuesday, 5 June 2018 8:34:28 PM AEST George Dunlap wrote:
> On Mon, Jun 4, 2018 at 3:55 PM, Lars Kurth <lars.kurth@citrix.com> wrote:
> > 2.2.3 B. Git baseline of patches
> > This created quite a bit of discussion and we did learn a few things:
> > * From the thread, having to cherry pick a small (around 5-6) patches have
> > to be cherry-picked for XSAs to apply to tarballs this appears to be seen
> > as OK for most users. More patches are a problem * Recently this issue
> > has become much worse, because some security fixes (or pre-requisites for
> > them) have been developed in public and some XSAs required significant
> > backporting to be able to be run * A point release has usually <50%
> > security fixes
> > * There is no appetite amongst existing point release maintainers to
> > maintain a staging branch and an XSA + pre-requisites only branch
> > 
> > In other words, we are at a stale-mate. I see two ways around it
> > a) Find an additional volunteer to maintain XSA + pre-requisites only
> > branches for releases b) Find some tooling/test based solution which
> > exposes issues applying XSAs on the last releases of a staging branch for
> > a point release. This is a little bit of a half-baked idea, but it may be
> > worthwhile looking into. For example, we could create an OSSTEST, that
> > checks out the last released stable branch and applies outstanding XSAs
> > and pre-requisites based on the meta-info to it (e.g. via xsatool or a
> > variant thereof). This test would fail, if an XSA does not apply, which
> > implies that the pre-requisites are incomplete. If all XSAs apply, we can
> > run the full OSSTEST on it. The test could also produce a list of git
> > commits from staging that include XSAs and pre-requisites that can be
> > applied in order. This should in theory - if doable - help downstreams
> > which are struggling with this problem, while flagging up potential
> > issues to stable maintainers early. Any thoughts? Would this be workable
> > and if so, would it actually help?
> Here's a question:  What would it take for most downstreams to update
> to staging when a public release was made?
> 
> Suppose we did this:
> 1. When we predisclose an issue, freeze the stable branches until the
> embargo lifts -- no backports.
> 2. When the embargo lifts, addition to the patches, we release a new
> point release, complete with signed tag and tarball.
> 3. We only do non-security point releases if we go 4 months without a
> security-prompted point release.
> 
> At the moment the release process is quite manual, which isn't
> terrible for one point release every 4 months per supported release,
> but would significantly increase the workload if we did it for every
> supported version for every XSA.  We'd have to invest quite a bit in
> automating that process, which would make it only worth it if a
> significant number of people would find that useful.
> 
> The other thing we could probably do is write a tool which would
> automatically determine the minimum number of 'extra' patches to
> backport from the stable branch to allow the patch to apply and build.
> The issue with that, of course, is that such a branch will be an
> artificial branch which has almost no testing.

I just wanted to git this a bit of a prod to keep it current.

Right now, we're at a stage where we could probably justify a new release of 
4.6, 4.7, 4.8, 4.9, and 4.10 due to the depth of XSAs contained within that 
can't be patched on top of the release archive.

Its actually easier to rebuild packages often with just updating version 
numbers than do patches to eternity. The kernel packages are one such example 
where this can be easily automated to even build / distribute without human 
interaction.

-- 
Steven Haigh

📧 netwiz@crc.id.au       💻 https://www.crc.id.au
📞 +61 (3) 9001 6090    📱 0412 935 897

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen Project Security Process Whitepaper v1 is ready for community review

[Jan Beulich]

>>> On 27.06.18 at 06:05, <netwiz@crc.id.au> wrote:
> Right now, we're at a stage where we could probably justify a new release of 
> 4.6, 4.7, 4.8, 4.9, and 4.10 due to the depth of XSAs contained within that 
> can't be patched on top of the release archive.

4.7.6 and 4.8.4 are imminent anyway, and 4.9.3 is due in about a
month's time (I'll send a respective call for pointing out missing
backports once I've flushed out my own queue). There's not going to
be another release off the 4.6 branch, at least not one organized by
XenProject. Even us meaning to do so for 4.7 is only because of the
circumstances.

As mentioned before - personally I'm not fancying to do more frequent
stable releases.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen Project Security Process Whitepaper v1 is ready for community review

[Steven Haigh]

[-- Attachment #1.1: Type: text/plain, Size: 1160 bytes --]

On Wednesday, 27 June 2018 7:19:58 PM AEST Jan Beulich wrote:
> >>> On 27.06.18 at 06:05, <netwiz@crc.id.au> wrote:
> > Right now, we're at a stage where we could probably justify a new release
> > of 4.6, 4.7, 4.8, 4.9, and 4.10 due to the depth of XSAs contained within
> > that can't be patched on top of the release archive.
> 
> 4.7.6 and 4.8.4 are imminent anyway, and 4.9.3 is due in about a
> month's time (I'll send a respective call for pointing out missing
> backports once I've flushed out my own queue). There's not going to
> be another release off the 4.6 branch, at least not one organized by
> XenProject. Even us meaning to do so for 4.7 is only because of the
> circumstances.
> 
> As mentioned before - personally I'm not fancying to do more frequent
> stable releases.

Surely we are able to automate the majority of the process?

I could imagine that with a regular release schedule, it could be refined 
enough to automatically package the current git branch based on just 
committing a tag.

-- 
Steven Haigh

📧 netwiz@crc.id.au       💻 https://www.crc.id.au
📞 +61 (3) 9001 6090    📱 0412 935 897

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen Project Security Process Whitepaper v1 is ready for community review

[Lars Kurth]

On 27/06/2018, 22:47, "Steven Haigh" <netwiz@crc.id.au> wrote:

    On Wednesday, 27 June 2018 7:19:58 PM AEST Jan Beulich wrote:
    > >>> On 27.06.18 at 06:05, <netwiz@crc.id.au> wrote:
    > > Right now, we're at a stage where we could probably justify a new release
    > > of 4.6, 4.7, 4.8, 4.9, and 4.10 due to the depth of XSAs contained within
    > > that can't be patched on top of the release archive.
    > 
    > 4.7.6 and 4.8.4 are imminent anyway, and 4.9.3 is due in about a
    > month's time (I'll send a respective call for pointing out missing
    > backports once I've flushed out my own queue). There's not going to
    > be another release off the 4.6 branch, at least not one organized by
    > XenProject. Even us meaning to do so for 4.7 is only because of the
    > circumstances.
    > 
    > As mentioned before - personally I'm not fancying to do more frequent
    > stable releases.
    
    Surely we are able to automate the majority of the process?
    
    I could imagine that with a regular release schedule, it could be refined 
    enough to automatically package the current git branch based on just 
    committing a tag.
    
There was a discussion at the summit in this area, which would be a step in the right direction, which was proposed by Doug from Rackspace and Matt from ARM. I still need to deal with the meeting notes
Lars

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen Project Security Process Whitepaper v1 is ready for community review

[Lars Kurth]

> On 28 Jun 2018, at 02:57, Lars Kurth <lars.kurth@citrix.com> wrote:
> 
> 
> On 27/06/2018, 22:47, "Steven Haigh" <netwiz@crc.id.au> wrote:
> 
>    On Wednesday, 27 June 2018 7:19:58 PM AEST Jan Beulich wrote:
>>>>> On 27.06.18 at 06:05, <netwiz@crc.id.au> wrote:
>>> Right now, we're at a stage where we could probably justify a new release
>>> of 4.6, 4.7, 4.8, 4.9, and 4.10 due to the depth of XSAs contained within
>>> that can't be patched on top of the release archive.
>> 
>> 4.7.6 and 4.8.4 are imminent anyway, and 4.9.3 is due in about a
>> month's time (I'll send a respective call for pointing out missing
>> backports once I've flushed out my own queue). There's not going to
>> be another release off the 4.6 branch, at least not one organized by
>> XenProject. Even us meaning to do so for 4.7 is only because of the
>> circumstances.
>> 
>> As mentioned before - personally I'm not fancying to do more frequent
>> stable releases.
> 
>    Surely we are able to automate the majority of the process?
> 
>    I could imagine that with a regular release schedule, it could be refined 
>    enough to automatically package the current git branch based on just 
>    committing a tag.
> 
> There was a discussion at the summit in this area, which would be a step in the right direction, which was proposed by Doug from Rackspace and Matt from ARM. I still need to deal with the meeting notes
> Lars

The relevant meeting notes are:
* https://lists.xenproject.org/archives/html/xen-devel/2018-07/threads.html#00129 (Testing/Building with Docker/GitLab)
* https://lists.xenproject.org/archives/html/xen-devel/2018-07/threads.html#00166 (Process changes: is the 6 monthly release Cadence too short, Security Process, ...)

If you want to pick up items from these discussions in this thread, please copy the relevant section from the above discussion into this thread.

Lars



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel