* Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items - Council meeting 2018-12-09
2018-12-04 0:16 ` Aaron Bauman
@ 2018-12-04 0:39 ` M. J. Everitt
2018-12-04 1:29 ` Aaron Bauman
2018-12-04 3:41 ` Michał Górny
2018-12-04 22:51 ` Sergei Trofimovich
2 siblings, 1 reply; 16+ messages in thread
From: M. J. Everitt @ 2018-12-04 0:39 UTC (permalink / raw
To: gentoo-project
[-- Attachment #1.1: Type: text/plain, Size: 2838 bytes --]
On 04/12/18 00:16, Aaron Bauman wrote:
>> On 25.11.2018 15:31, Mart Raudsepp wrote:
>>> In two weeks from now, there will be a council meeting again. Now is
>>> the time to raise and prepare agenda items that you want us to discuss
>>> and/or vote upon.
>>>
>>> Please respond to this message on the gentoo-project mailing list with
>>> agenda items.
>>> The final agenda will be sent out on 2018-12-02, so please make sure
>>> you post any agenda items before that, or we may not be able to
>>> accommodate it into the next meeting.
>>>
>>> The meeting itself will happen on 2018-12-09 19:00 UTC [1] in the
>>> #gentoo-council FreeNode IRC channel.
>>>
>>>
>>> 1. https://www.timeanddate.com/worldclock/fixedtime.html?iso=20181209T19
>>>
>>>
>>> Thanks,
>>> Mart Raudsepp
> I would like to propose, once again, that the council vote on the
> following items:
>
> 1. The council approves all architectures that are maintained as stable
> architectures.
> - e.g. alpha, amd64, arm, arm64, ia64, ppc, ppc64, and x86.
>
> Conversely, the council also may remove/drop such architectures as
> needed (c.f. item 2).
>
> 2. The council approves that all stable architectures are subsequently
> determined to be security supported. Thus, an architecture may not be
> stable and *not* security supported. This disparity has implications in
> processes and timeliness of actions taken to mitigate vulnerabilities
> reported.
> - e.g. amd64 is approved as stable arch and thus is security supported.
> - e.g. arm is dropped as a stable arch thus is no longer security supported.
>
> Overall, both of these items will provide a much clearer understanding
> of how security is able to proceed with mitigating vulnerabilities in
> the tree, how users view and understand what architectures are stable
> and security supported, and allow the security team and maintainers a
> clearer/cleaner process to follow.
>
> Standing by to answer RFI's.
>
> --
> Cheers,
> Aaron
By all means correct me if I'm wrong, but my understanding was that a
stable *arch* meant that there was a consistent dependency tree, and this
was maintained to ensure there was some integrity to that arch's packages.
It had/has nothing to do with security-supported which was another separate
classification entirely.
I see merit in simplifying the categorisation of arch package sets, but I'm
not sure this particular change/proposal will serve much of a purpose,
other than further reinforcing that amd64 is the only arch that Gentoo
officially supports; and sets the wheels in motion for eventual bitrot of
anything else, streamlining the way for deprecation and treecleaning
anything which is not relevant for amd64 arch.
Please clarify that this is not, and will not be the case with this
policy/proposal.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items - Council meeting 2018-12-09
2018-12-04 0:39 ` M. J. Everitt
@ 2018-12-04 1:29 ` Aaron Bauman
0 siblings, 0 replies; 16+ messages in thread
From: Aaron Bauman @ 2018-12-04 1:29 UTC (permalink / raw
To: gentoo-project
[-- Attachment #1: Type: text/plain, Size: 3829 bytes --]
On Tue, Dec 04, 2018 at 12:39:07AM +0000, M. J. Everitt wrote:
> On 04/12/18 00:16, Aaron Bauman wrote:
> >> On 25.11.2018 15:31, Mart Raudsepp wrote:
> >>> In two weeks from now, there will be a council meeting again. Now is
> >>> the time to raise and prepare agenda items that you want us to discuss
> >>> and/or vote upon.
> >>>
> >>> Please respond to this message on the gentoo-project mailing list with
> >>> agenda items.
> >>> The final agenda will be sent out on 2018-12-02, so please make sure
> >>> you post any agenda items before that, or we may not be able to
> >>> accommodate it into the next meeting.
> >>>
> >>> The meeting itself will happen on 2018-12-09 19:00 UTC [1] in the
> >>> #gentoo-council FreeNode IRC channel.
> >>>
> >>>
> >>> 1. https://www.timeanddate.com/worldclock/fixedtime.html?iso=20181209T19
> >>>
> >>>
> >>> Thanks,
> >>> Mart Raudsepp
> > I would like to propose, once again, that the council vote on the
> > following items:
> >
> > 1. The council approves all architectures that are maintained as stable
> > architectures.
> > - e.g. alpha, amd64, arm, arm64, ia64, ppc, ppc64, and x86.
> >
> > Conversely, the council also may remove/drop such architectures as
> > needed (c.f. item 2).
> >
> > 2. The council approves that all stable architectures are subsequently
> > determined to be security supported. Thus, an architecture may not be
> > stable and *not* security supported. This disparity has implications in
> > processes and timeliness of actions taken to mitigate vulnerabilities
> > reported.
> > - e.g. amd64 is approved as stable arch and thus is security supported.
> > - e.g. arm is dropped as a stable arch thus is no longer security supported.
> >
> > Overall, both of these items will provide a much clearer understanding
> > of how security is able to proceed with mitigating vulnerabilities in
> > the tree, how users view and understand what architectures are stable
> > and security supported, and allow the security team and maintainers a
> > clearer/cleaner process to follow.
> >
> > Standing by to answer RFI's.
> >
> > --
> > Cheers,
> > Aaron
> By all means correct me if I'm wrong, but my understanding was that a
> stable *arch* meant that there was a consistent dependency tree, and this
> was maintained to ensure there was some integrity to that arch's packages.
Correct. Which directly correlates to how the security team and
maintainers are able to proceed with security related matters. Very
simply put:
Vulnerability Identified->Package patched/bumped->Stabilization
occurs->Vulnerable package (read... ebuild) is removed->GLSA issued if
required->Bug closed.
> It had/has nothing to do with security-supported which was another separate
> classification entirely.
>
Correct. Historically, it has been treated separately, but due to the
previous statement above it is quite interdependent.
> I see merit in simplifying the categorisation of arch package sets, but I'm
> not sure this particular change/proposal will serve much of a purpose,
> other than further reinforcing that amd64 is the only arch that Gentoo
> officially supports; and sets the wheels in motion for eventual bitrot of
Our intent is not bitrot of any arch. Many "alt-arches"
(uncommon/exotic... pick a description) keep up just fine... if not
exceed more common arches.
> anything else, streamlining the way for deprecation and treecleaning
> anything which is not relevant for amd64 arch.
> Please clarify that this is not, and will not be the case with this
> policy/proposal.
>
This is *not* the case and will never be the case for this proposal. I
don't believe anyone would vote/recommend such a thing if an arch is
capable of being supported.
--
Cheers,
Aaron
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items - Council meeting 2018-12-09
2018-12-04 0:16 ` Aaron Bauman
2018-12-04 0:39 ` M. J. Everitt
@ 2018-12-04 3:41 ` Michał Górny
2018-12-04 9:54 ` Kristian Fiskerstrand
2018-12-04 21:18 ` Aaron Bauman
2018-12-04 22:51 ` Sergei Trofimovich
2 siblings, 2 replies; 16+ messages in thread
From: Michał Górny @ 2018-12-04 3:41 UTC (permalink / raw
To: gentoo-project
[-- Attachment #1: Type: text/plain, Size: 2729 bytes --]
On Mon, 2018-12-03 at 19:16 -0500, Aaron Bauman wrote:
> > On 25.11.2018 15:31, Mart Raudsepp wrote:
> > > In two weeks from now, there will be a council meeting again. Now is
> > > the time to raise and prepare agenda items that you want us to discuss
> > > and/or vote upon.
> > >
> > > Please respond to this message on the gentoo-project mailing list with
> > > agenda items.
> > > The final agenda will be sent out on 2018-12-02, so please make sure
> > > you post any agenda items before that, or we may not be able to
> > > accommodate it into the next meeting.
> > >
> > > The meeting itself will happen on 2018-12-09 19:00 UTC [1] in the
> > > #gentoo-council FreeNode IRC channel.
> > >
> > >
> > > 1. https://www.timeanddate.com/worldclock/fixedtime.html?iso=20181209T19
> > >
> > >
> > > Thanks,
> > > Mart Raudsepp
>
> I would like to propose, once again, that the council vote on the
> following items:
>
> 1. The council approves all architectures that are maintained as stable
> architectures.
> - e.g. alpha, amd64, arm, arm64, ia64, ppc, ppc64, and x86.
>
> Conversely, the council also may remove/drop such architectures as
> needed (c.f. item 2).
What happens if Council votes 'no' to this item? Do all arches become
unstable?
Don't introduce votes for confirming status quo because they make no
sense. If there's a specific change you're proposing, propose it
and be specific so that people can discuss it ahead of time.
> 2. The council approves that all stable architectures are subsequently
> determined to be security supported. Thus, an architecture may not be
> stable and *not* security supported. This disparity has implications in
> processes and timeliness of actions taken to mitigate vulnerabilities
> reported.
> - e.g. amd64 is approved as stable arch and thus is security supported.
> - e.g. arm is dropped as a stable arch thus is no longer security supported.
>
> Overall, both of these items will provide a much clearer understanding
> of how security is able to proceed with mitigating vulnerabilities in
> the tree, how users view and understand what architectures are stable
> and security supported, and allow the security team and maintainers a
> clearer/cleaner process to follow.
>
Are you asking the Council to make a policy for security team,
or to override the existing policy of security team? Because this
sounds like you're implying that security team can't make up their mind.
Also, if the Council votes 'yes', what happens next? Does security
accept all stable arches? Do stable arches get demoted implicitly based
on security project considerations?
--
Best regards,
Michał Górny
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items - Council meeting 2018-12-09
2018-12-04 3:41 ` Michał Górny
@ 2018-12-04 9:54 ` Kristian Fiskerstrand
2018-12-04 10:06 ` Mart Raudsepp
2018-12-04 21:18 ` Aaron Bauman
1 sibling, 1 reply; 16+ messages in thread
From: Kristian Fiskerstrand @ 2018-12-04 9:54 UTC (permalink / raw
To: gentoo-project, Michał Górny
On 12/4/18 4:41 AM, Michał Górny wrote:
> Are you asking the Council to make a policy for security team,
> or to override the existing policy of security team? Because this
> sounds like you're implying that security team can't make up their mind.
This is indeed part of the ongoing discussion surrounding the GLEP for
the security team; Before anything should go to council on this we need
to put the the current draft up for a public discussion on the -project
mailing list.
>
> Also, if the Council votes 'yes', what happens next? Does security
> accept all stable arches? Do stable arches get demoted implicitly based
> on security project considerations?
The assumption would be that security needs to have a say for whenever
an arch is added or if requesting to remove an arch. To balance this a a
GLEP48-style/QA-style lead approval process is added and criteria to be
used for such determination is included.
Personally I don't see a problem with the status quo where security
supported arches is listed as part of security project's documentation,
and removals announced etc. The actual security implication for a lot of
these arches will anyways be impacted by members of the team having
limited knowledge of particulars, in particular when it come to auditing
due to difference in assembly etc, so the major arches will anyways have
a better foundation for being handled by the team, so security is
relative to what we claim to know and do.
In any case, too early for the council to do anything here.
--
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items - Council meeting 2018-12-09
2018-12-04 9:54 ` Kristian Fiskerstrand
@ 2018-12-04 10:06 ` Mart Raudsepp
0 siblings, 0 replies; 16+ messages in thread
From: Mart Raudsepp @ 2018-12-04 10:06 UTC (permalink / raw
To: gentoo-project
[-- Attachment #1: Type: text/plain, Size: 2390 bytes --]
Ühel kenal päeval, T, 04.12.2018 kell 10:54, kirjutas Kristian
Fiskerstrand:
> On 12/4/18 4:41 AM, Michał Górny wrote:
> > Are you asking the Council to make a policy for security team,
> > or to override the existing policy of security team? Because this
> > sounds like you're implying that security team can't make up their
> > mind.
>
> This is indeed part of the ongoing discussion surrounding the GLEP
> for
> the security team; Before anything should go to council on this we
> need
> to put the the current draft up for a public discussion on the
> -project
> mailing list.
>
> >
> > Also, if the Council votes 'yes', what happens next? Does security
> > accept all stable arches? Do stable arches get demoted implicitly
> > based
> > on security project considerations?
>
> The assumption would be that security needs to have a say for
> whenever
> an arch is added or if requesting to remove an arch. To balance this
> a a
> GLEP48-style/QA-style lead approval process is added and criteria to
> be
> used for such determination is included.
>
> Personally I don't see a problem with the status quo where security
> supported arches is listed as part of security project's
> documentation,
> and removals announced etc. The actual security implication for a lot
> of
> these arches will anyways be impacted by members of the team having
> limited knowledge of particulars, in particular when it come to
> auditing
> due to difference in assembly etc, so the major arches will anyways
> have
> a better foundation for being handled by the team, so security is
> relative to what we claim to know and do.
>
> In any case, too early for the council to do anything here.
Given this subthread and the points about GLEP, I'm not sure how we can
discuss these things without even having seen the security GLEP update
proposal yet. Thus I will not add these items to the agenda (we can
also call them proposed over a day late, if you want), but rather
explicitly bring out the open bug about the GLEP update, as it keeps
getting delayed from meeting to meeting. Hopefully this (and it being a
prerequisite for the "rejected" agenda items) brings more attention to
it and at least something becomes ready and appears to the public.
That said, I would very much welcome b-man with this topic to the open
floor.
Mart
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 981 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items - Council meeting 2018-12-09
2018-12-04 3:41 ` Michał Górny
2018-12-04 9:54 ` Kristian Fiskerstrand
@ 2018-12-04 21:18 ` Aaron Bauman
1 sibling, 0 replies; 16+ messages in thread
From: Aaron Bauman @ 2018-12-04 21:18 UTC (permalink / raw
To: gentoo-project
[-- Attachment #1: Type: text/plain, Size: 3532 bytes --]
On Tue, Dec 04, 2018 at 04:41:32AM +0100, Michał Górny wrote:
> On Mon, 2018-12-03 at 19:16 -0500, Aaron Bauman wrote:
> > > On 25.11.2018 15:31, Mart Raudsepp wrote:
> > > > In two weeks from now, there will be a council meeting again. Now is
> > > > the time to raise and prepare agenda items that you want us to discuss
> > > > and/or vote upon.
> > > >
> > > > Please respond to this message on the gentoo-project mailing list with
> > > > agenda items.
> > > > The final agenda will be sent out on 2018-12-02, so please make sure
> > > > you post any agenda items before that, or we may not be able to
> > > > accommodate it into the next meeting.
> > > >
> > > > The meeting itself will happen on 2018-12-09 19:00 UTC [1] in the
> > > > #gentoo-council FreeNode IRC channel.
> > > >
> > > >
> > > > 1. https://www.timeanddate.com/worldclock/fixedtime.html?iso=20181209T19
> > > >
> > > >
> > > > Thanks,
> > > > Mart Raudsepp
> >
> > I would like to propose, once again, that the council vote on the
> > following items:
> >
> > 1. The council approves all architectures that are maintained as stable
> > architectures.
> > - e.g. alpha, amd64, arm, arm64, ia64, ppc, ppc64, and x86.
> >
> > Conversely, the council also may remove/drop such architectures as
> > needed (c.f. item 2).
>
> What happens if Council votes 'no' to this item? Do all arches become
> unstable?
>
Of course not, that would be silly. I suppose better wording would have
been something like:
"The council will begin approving the addition and removal of all
architectures considered stable. Upon approval of this item, all
current stable architectures will remain."
> Don't introduce votes for confirming status quo because they make no
> sense. If there's a specific change you're proposing, propose it
> and be specific so that people can discuss it ahead of time.
>
Ugh... status quo? I am not sure how this is status quo...
> > 2. The council approves that all stable architectures are subsequently
> > determined to be security supported. Thus, an architecture may not be
> > stable and *not* security supported. This disparity has implications in
> > processes and timeliness of actions taken to mitigate vulnerabilities
> > reported.
> > - e.g. amd64 is approved as stable arch and thus is security supported.
> > - e.g. arm is dropped as a stable arch thus is no longer security supported.
> >
> > Overall, both of these items will provide a much clearer understanding
> > of how security is able to proceed with mitigating vulnerabilities in
> > the tree, how users view and understand what architectures are stable
> > and security supported, and allow the security team and maintainers a
> > clearer/cleaner process to follow.
> >
>
> Are you asking the Council to make a policy for security team,
> or to override the existing policy of security team? Because this
> sounds like you're implying that security team can't make up their mind.
>
Absolutely, but we have the GLEP draft in the open now. So, here we go.
> Also, if the Council votes 'yes', what happens next? Does security
> accept all stable arches? Do stable arches get demoted implicitly based
> on security project considerations?
>
Yes, we would accept all stable arches as security supported.
No, security would simply petition the council should an arch need to be
removed from stable.
> --
> Best regards,
> Michał Górny
--
Cheers,
Aaron
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items - Council meeting 2018-12-09
2018-12-04 0:16 ` Aaron Bauman
2018-12-04 0:39 ` M. J. Everitt
2018-12-04 3:41 ` Michał Górny
@ 2018-12-04 22:51 ` Sergei Trofimovich
2 siblings, 0 replies; 16+ messages in thread
From: Sergei Trofimovich @ 2018-12-04 22:51 UTC (permalink / raw
To: gentoo-project
On Mon, 3 Dec 2018 19:16:04 -0500
Aaron Bauman <bman@gentoo.org> wrote:
> > On 25.11.2018 15:31, Mart Raudsepp wrote:
> > > In two weeks from now, there will be a council meeting again. Now is
> > > the time to raise and prepare agenda items that you want us to discuss
> > > and/or vote upon.
> > >
> > > Please respond to this message on the gentoo-project mailing list with
> > > agenda items.
> > > The final agenda will be sent out on 2018-12-02, so please make sure
> > > you post any agenda items before that, or we may not be able to
> > > accommodate it into the next meeting.
> > >
> > > The meeting itself will happen on 2018-12-09 19:00 UTC [1] in the
> > > #gentoo-council FreeNode IRC channel.
> > >
> > >
> > > 1. https://www.timeanddate.com/worldclock/fixedtime.html?iso=20181209T19
> > >
> > >
> > > Thanks,
> > > Mart Raudsepp
>
> I would like to propose, once again, that the council vote on the
> following items:
If it's not the first instance can you link to previous discussion of
the problem?
> 1. The council approves all architectures that are maintained as stable
> architectures.
> - e.g. alpha, amd64, arm, arm64, ia64, ppc, ppc64, and x86.
What is the definition of "maintained as stable architectures" in this
context? I don't think Gentoo defines those today.
The ones that have at least one stable profile in profiles.desc?
"Security Project Structure" defines it in even more vague terms:
'the ebuilds in the Gentoo official ebuild repository marked as "stable"'
Or you plan to introduce/maintain a separate list of stable arches?
> Conversely, the council also may remove/drop such architectures as
> needed (c.f. item 2).
>
> 2. The council approves that all stable architectures are subsequently
> determined to be security supported. Thus, an architecture may not be
> stable and *not* security supported. This disparity has implications in
> processes and timeliness of actions taken to mitigate vulnerabilities
> reported.
> - e.g. amd64 is approved as stable arch and thus is security supported.
> - e.g. arm is dropped as a stable arch thus is no longer security supported.
>
> Overall, both of these items will provide a much clearer understanding
> of how security is able to proceed with mitigating vulnerabilities in
> the tree, how users view and understand what architectures are stable
> and security supported, and allow the security team and maintainers a
> clearer/cleaner process to follow.
>
> Standing by to answer RFI's.
>
> --
> Cheers,
> Aaron
--
Sergei
^ permalink raw reply [flat|nested] 16+ messages in thread