On Tue, Jan 30, 2018 at 02:35:34AM +0100, Kamil Rytarowski wrote: > I'm not biased towards any approach. I just note that the current > approach with shipping binary packages and SA is inefficient and deter > users.
Let's try to be constructive. It's true that releasing SAs is resource consuming and as exciting as writing documentation. So as you can imagine it's hard to find volunteers to do that. For each vulnerability you have to evaluate implications of a bug, consider possible workarounds, check which versions are vulnerable etc. It can take several hours per issue, then it should be reviewed, signed, announced... I'd love to hear from you what's crucial for you. Personally I'd like to receive less formal notifications, just an information "hey shm, update your sources here and there, rebuild stuff and be happy again". I understand that this information is not that useful if you need to consider more factors than average desktop user, but lack of an information, because it stuck in the sec-team queue for years, is even worse. What you think? I'm not sure if involving binary packages here is a good idea since it adds complexity which we try to decrease. I like the approach proposed by our friends from the OpenBSD project - http://www.openbsd.org/errata62.html . It can be applied to most of issues that hit security-team@, and for the special ones (we need to define what the "special" means for an average user) we can issue regular SAs (we can even publish the information before the SA and publish the information when paperwork is done). I'm just thinking loud here... But simple script with a database feed by the security-team@ that let evaluate user if their sources/systems are vulnerable, would be super useful! :) And to be clear, it's not just our problem, I've seen lots of bugs fixed quietly in various open source projects. Nobody cared enough to issue a security notification or realize that bug may have security implications. Stay Safe, Mateusz
