| 1 |
Ühel kenal päeval, T, 04.12.2018 kell 10:54, kirjutas Kristian |
| 2 |
Fiskerstrand: |
| 3 |
> On 12/4/18 4:41 AM, Michał Górny wrote: |
| 4 |
> > Are you asking the Council to make a policy for security team, |
| 5 |
> > or to override the existing policy of security team? Because this |
| 6 |
> > sounds like you're implying that security team can't make up their |
| 7 |
> > mind. |
| 8 |
> |
| 9 |
> This is indeed part of the ongoing discussion surrounding the GLEP |
| 10 |
> for |
| 11 |
> the security team; Before anything should go to council on this we |
| 12 |
> need |
| 13 |
> to put the the current draft up for a public discussion on the |
| 14 |
> -project |
| 15 |
> mailing list. |
| 16 |
> |
| 17 |
> > |
| 18 |
> > Also, if the Council votes 'yes', what happens next? Does security |
| 19 |
> > accept all stable arches? Do stable arches get demoted implicitly |
| 20 |
> > based |
| 21 |
> > on security project considerations? |
| 22 |
> |
| 23 |
> The assumption would be that security needs to have a say for |
| 24 |
> whenever |
| 25 |
> an arch is added or if requesting to remove an arch. To balance this |
| 26 |
> a a |
| 27 |
> GLEP48-style/QA-style lead approval process is added and criteria to |
| 28 |
> be |
| 29 |
> used for such determination is included. |
| 30 |
> |
| 31 |
> Personally I don't see a problem with the status quo where security |
| 32 |
> supported arches is listed as part of security project's |
| 33 |
> documentation, |
| 34 |
> and removals announced etc. The actual security implication for a lot |
| 35 |
> of |
| 36 |
> these arches will anyways be impacted by members of the team having |
| 37 |
> limited knowledge of particulars, in particular when it come to |
| 38 |
> auditing |
| 39 |
> due to difference in assembly etc, so the major arches will anyways |
| 40 |
> have |
| 41 |
> a better foundation for being handled by the team, so security is |
| 42 |
> relative to what we claim to know and do. |
| 43 |
> |
| 44 |
> In any case, too early for the council to do anything here. |
| 45 |
|
| 46 |
Given this subthread and the points about GLEP, I'm not sure how we can |
| 47 |
discuss these things without even having seen the security GLEP update |
| 48 |
proposal yet. Thus I will not add these items to the agenda (we can |
| 49 |
also call them proposed over a day late, if you want), but rather |
| 50 |
explicitly bring out the open bug about the GLEP update, as it keeps |
| 51 |
getting delayed from meeting to meeting. Hopefully this (and it being a |
| 52 |
prerequisite for the "rejected" agenda items) brings more attention to |
| 53 |
it and at least something becomes ready and appears to the public. |
| 54 |
|
| 55 |
That said, I would very much welcome b-man with this topic to the open |
| 56 |
floor. |
| 57 |
|
| 58 |
|
| 59 |
Mart |
Archives