| 1 |
On Sat, Dec 19, 2015 at 8:24 AM, Tobias Heinlein <keytoaster@g.o> wrote: |
| 2 |
> Hi, |
| 3 |
> |
| 4 |
> On 18.12.2015 21:06, Mike Gilbert wrote: |
| 5 |
>> Hi, please review the news item below. |
| 6 |
> |
| 7 |
> thanks for drafting this news item. However, the usual way to inform |
| 8 |
> users about security flaws is by sending a GLSA. :) |
| 9 |
> |
| 10 |
> Based on your news item, we have drafted a GLSA now. It's currently |
| 11 |
> pending review by one other member of the security team and we will send |
| 12 |
> it in a few hours. |
| 13 |
> |
| 14 |
|
| 15 |
The only concerns I have with this approach are: |
| 16 |
1. In this case timing is fine, but sometimes GLSAs have a |
| 17 |
significant delay, especially when minor archs are involved in |
| 18 |
stabilization. |
| 19 |
2. Users probably don't regularly read GLSAs, since for the most part |
| 20 |
it just tells them to update packages they've probably already |
| 21 |
updated. How do we make ones that actually have instructions beyond |
| 22 |
updating stand out? |
| 23 |
|
| 24 |
I know I stopped reading GLSAs ages ago, because they tended to tell |
| 25 |
me to update to a package I had updated to a week before, and when |
| 26 |
they said something else 90% of the time it was because there was an |
| 27 |
error in the GLSA (usually this happened with subslots and the GLSA |
| 28 |
just said <n is vulnerable and the reality is that there were a number |
| 29 |
of ranges that were vulnerable vs fixed). Granted, I have caught one |
| 30 |
or two episodes over the years where the actual package might not have |
| 31 |
been completely addressed and an older slot needed fixing. |
| 32 |
|
| 33 |
I guess my point isn't that GLSAs are a bad thing, but users need a |
| 34 |
really high S/N ratio if we want them to pay attention. We need to |
| 35 |
separate the mundane from the important. |
| 36 |
|
| 37 |
-- |
| 38 |
Rich |
Archives