| 1 |
On 12/09/16 13:54, Aaron Bauman wrote: |
| 2 |
> |
| 3 |
> |
| 4 |
> On 12/03/2016 03:22 AM, Mart Raudsepp wrote: |
| 5 |
>> Ühel kenal päeval, R, 02.12.2016 kell 15:44, kirjutas Agostino Sarubbo: |
| 6 |
>>> On Friday 02 December 2016 23:17:13 Aaron Bauman wrote: |
| 7 |
>>>> I would like the council to consider dropping IA-64 and SPARC from |
| 8 |
>>>> the |
| 9 |
>>>> supported list of stable architectures to increase the security |
| 10 |
>>>> posture |
| 11 |
>>>> of the tree. |
| 12 |
>>> I would like to ask to keep the things as is. |
| 13 |
>>> |
| 14 |
>>> The slowdown is caused from the fact that there are no rules for the |
| 15 |
>>> stabilization requests. |
| 16 |
>>> We (kensington mainly + wg-stable group) are working to have more |
| 17 |
>>> automations. |
| 18 |
>> He is talking about security stabilization bugs here. |
| 19 |
>> |
| 20 |
>> I don't understand why stable and security stable have to be connected, |
| 21 |
>> and why fringe arches are considered stopping the drafting and send-out |
| 22 |
>> of GLSA. The tooling could special case ia64 and sparc to tell that |
| 23 |
>> it's not marked stable there yet or whatever when it isn't yet. The |
| 24 |
>> dozen users will know what to do. |
| 25 |
> |
| 26 |
> They must be connected, because we cannot properly clean the tree if |
| 27 |
> they are not. Otherwise, we would break the dependency tree. As long |
| 28 |
> as the packages are marked stable, we can somewhat ensure that users |
| 29 |
> will not be exposed to vulnerable code, but not entirely. We cannot |
| 30 |
> publish a GLSA if there is no stable upgrade path for the user either. |
| 31 |
> Why would that be acceptable? Given a "dozen users will know what to |
| 32 |
> do," then why build tooling for such a small audience? If they know |
| 33 |
> what to do, then we should expect that they will know what to do without |
| 34 |
> being a stable arch. |
| 35 |
> |
| 36 |
... why? |
| 37 |
|
| 38 |
I mean: there *is* a security issue, so better tell me about it now so I |
| 39 |
can apply workarounds (e.g. disabling services) instead of waiting an |
| 40 |
unbounded time until it is stable on all architectures (why do I care |
| 41 |
about architecture X lagging?) and then telling me that I was exposed |
| 42 |
for the last dozen timeunits. |
| 43 |
|
| 44 |
From my point of view it is rather confusing ... |
Archives