| 1 |
On 12/03/2016 03:22 AM, Mart Raudsepp wrote: |
| 2 |
> Ühel kenal päeval, R, 02.12.2016 kell 15:44, kirjutas Agostino Sarubbo: |
| 3 |
>> On Friday 02 December 2016 23:17:13 Aaron Bauman wrote: |
| 4 |
>>> I would like the council to consider dropping IA-64 and SPARC from |
| 5 |
>>> the |
| 6 |
>>> supported list of stable architectures to increase the security |
| 7 |
>>> posture |
| 8 |
>>> of the tree. |
| 9 |
>> I would like to ask to keep the things as is. |
| 10 |
>> |
| 11 |
>> The slowdown is caused from the fact that there are no rules for the |
| 12 |
>> stabilization requests. |
| 13 |
>> We (kensington mainly + wg-stable group) are working to have more |
| 14 |
>> automations. |
| 15 |
> He is talking about security stabilization bugs here. |
| 16 |
> |
| 17 |
> I don't understand why stable and security stable have to be connected, |
| 18 |
> and why fringe arches are considered stopping the drafting and send-out |
| 19 |
> of GLSA. The tooling could special case ia64 and sparc to tell that |
| 20 |
> it's not marked stable there yet or whatever when it isn't yet. The |
| 21 |
> dozen users will know what to do. |
| 22 |
|
| 23 |
They must be connected, because we cannot properly clean the tree if |
| 24 |
they are not. Otherwise, we would break the dependency tree. As long |
| 25 |
as the packages are marked stable, we can somewhat ensure that users |
| 26 |
will not be exposed to vulnerable code, but not entirely. We cannot |
| 27 |
publish a GLSA if there is no stable upgrade path for the user either. |
| 28 |
Why would that be acceptable? Given a "dozen users will know what to |
| 29 |
do," then why build tooling for such a small audience? If they know |
| 30 |
what to do, then we should expect that they will know what to do without |
| 31 |
being a stable arch. |
| 32 |
|
| 33 |
> Or as a temporary measure propose the removal of these arches from the |
| 34 |
> list of security supported (I don't believe one of them is security |
| 35 |
> supported even now), and move back to security supported once the |
| 36 |
> process is more streamlined from the workflow efforts going into there |
| 37 |
> now. |
| 38 |
> |
| 39 |
> |
| 40 |
|
| 41 |
Aside from the above items, I think this proposal becomes confusing for |
| 42 |
the user. My arch is stable... but not security supported? |
Archives