From: Rene E. <re...@de...> - 2016-01-21 15:27:05
|
Hi, On Thu, Jan 21, 2016 at 08:12:41AM -0600, John Thomson wrote: > Seems to me that if there is a serious, exploitable security problem we That is the question, yes.. > should first inform any colleagues who might want to patch their products > (e.g., FireFox) before the problem is widely known. No, we shouldn't. One could, but it's not a requirement. If firefox has a embedded copy of graphite2, well... It should use system-graphite and then there is no problem if the distro patches graphite2. And the problem is already known. No details, and not widely (just this ML), but known. > After that, I would think a public announcement should try to give some > details of the scope of the problem (i.e., how much damage could be done > by exploiting it?) without giving details that would greatly help hackers. You need to give the exact patch to have stuff patched. And when one releases the patch it gets public whatsoever. At least for patching older versions. One can "sneak" a new graphite 1.3.5 into development, that doesn't help for fixing (if it is affected) graphite2 | 1.1.3-1 | wheezy | source graphite2 | 1.2.4-3 | jessie-kfreebsd | source graphite2 | 1.2.4-3 | jessie | source for example. > In the end, Graphite is open source. Someone only has to look at the repo > to see what changed recently, and probably, the commit label identifies > exactly the change that fixes a security problem and thus points straight > at what was previously vulnerable. Yes, and that already happened. You already see the commits in github and together with this non-verbose changelog entry people might be able to look this up. This is exactly why one should do such stuff directly with info to get people being able to patch it quickly, not trying to shove it under the carpet. As other (even bigger) projects do responsibly. Regards, Rene |