Daniel Stenberg (curl, libssh2, rockbox, Horizon etc) har skrivit ett bra inlägg på sin blogg om hur säkerhetsmeddelanden kan förbättras (eng: security advisory – någon med bra ord för detta på svenska?). Daniel ser flera brister i hur den kedja av meddelanden som ofta uppstår leder till osäkerheter. Daniel skriver:
After a security advisory and the accompanying release, something particular always happens. It’s the same every time I’ve done this and there’s really no surprise: one by one the different Linux distros and similar parties start to ship their security advisories and alerts about the same problem and they offer their upgrade paths for their users to get a corrected version of the package.
But I’ll tell you why I think those advisories tend to make me really sad. It’s not because of the flaws they fix or how fast or slow they are to appear. It’s entirely due to the contents of them or perhaps in many times the lack of contents.
When the first distro-based advisory comes out, they often tend not to use the phrasing used in the original advisory (which we’ve crafted on for weeks and coordinated with vendor-sec) but they instead offer their own interpretation. This isn’t necessarily a bad thing, but when the guys simplify matters they tend to blur out the actual cause and make the real issue hard to understand. Not to mention that when the first guy had done a mistake, most others just repeat that without thinking.
Problemet Daniel tar upp är lite som viskningsleken där en kedja av rapportörer ändrar meddelandet på vägen genom kedjan. Daniel har några förslag på hur säkerhetsmeddelanden kan göras bättre:
1. credit the original problem founder/researcher. This way the glory and fame goes to the person(s) who often did a lot of research and hard work.
2. link to the original advisory so that everyone who wants to can get the info and details from the upstream project and their ideas of what the problems are and what the best fixes or work-arounds might be
3. fact-check your error/solution description better and don’t just repeat what someone else wrote unless you know that’s an accurate description
4. don’t repeat others’ simplifications and errors. The act of duplicating someone else’s description is pretty low in general and it would often only be a signal that you haven’t understood the issue in the first place. If you have a rule to not copy others you won’t risk copying their mistakes.
No related posts.
Related posts brought to you by Yet Another Related Posts Plugin.
