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