| 1 |
The problem with that is that a GLSA check will fail at that point, we can not also include the fix are (security project) in the fix section as we do not know what version will be final on stabilization. For example, if you look in Bug Tracker the bugs can go stable but to stabilize them will take a very long time. Sometimes it takes as long to stabilize them that a new version is out before the original is stabilized. (Just a note, not blaming the arches groups here, it is simple the way it is). What about the times that during stabilization a dependency is found and it takes a month or two to fix it? The GLSA goes out, it now tells the users to update to a version that does not exist. |
| 2 |
|
| 3 |
It does sound good, but not practical as it will introduce confusion for the users especially those that do not constantly maintain their system and only update the security patches. |
| 4 |
|
| 5 |
Those users that have a practice of updating (world update) on a schedule (Weekly / Monthly) would receive the patches if the stable version is in the tree. |
| 6 |
|
| 7 |
________________ |
| 8 |
Yury German |
| 9 |
Gentoo Security Team | Planet Gentoo |
| 10 |
Email: blueknight@g.o |
| 11 |
|
| 12 |
|
| 13 |
|
| 14 |
> On Dec 15, 2016, at 2:05 PM, Paweł Hajdan, Jr. <phajdan.jr@g.o> wrote: |
| 15 |
> |
| 16 |
> On 13/12/2016 21:36, Mart Raudsepp wrote: |
| 17 |
>> Solution proposal: |
| 18 |
>> |
| 19 |
>> Push out a GLSA as soon as the relevant fix is available in the tree in |
| 20 |
>> any form (usually when the security bug moves from [ebuild] to [stable] |
| 21 |
>> state), so the fixed_in (unaffected) atoms have become known. |
| 22 |
> |
| 23 |
> Sounds good. |
| 24 |
> |
| 25 |
> Given the GLSA process itself introduces delays, and it seems to start |
| 26 |
> only after [stable], sending it earlier and in a simpler way is a nice |
| 27 |
> simplification of the process. |
| 28 |
> |
| 29 |
> Paweł |
| 30 |
> |
Archives