Re: [Silgraphite-devel] Release 1.3.6 of graphite2 engine

[Martin H. <mar...@si...>]

Dear Rene,

> On Tue, Mar 01, 2016 at 09:32:42AM +0700, Martin Hosken wrote:
> > Surely that is only for resolving bugs that have been made public in CVE that you need to show due diligence in having fixed. What about:
> 
> Now this one is public when you say "security fixes".

So is "security fixes" a keyword that should be avoided if there is no CVE or such involved?

> Either it's a security fix and we need to do the full game or "just" crashes
> (maybe, maybe not due to fuzz) and we don't need the whole game.

We don't need the whole game, but users are recommended to update because these bugs may have security implications. Does that cover it?

> > 1) bugs that are fixed in the pre-public announcement period that, therefore do not have a CVE number yet.
> 
> You get a CVE when you do that. A CVE isn't public per default.

I wasn't. TELOS referenced a number which I only later realised was their reference and then a CVE was created from the TELOS bug report when it became public, long after I fixed it.

> > 2) bugs that will never be announced publicly and so will never get a CVE number
> 
> But this one is.
> 
> > 3) the inability before a CVE is announced, of knowing the difference between 1 & 2
> 
> OK, but then you can get one if you decide.
> 
> Still, we need some info for updates to (old)stable. "Some undefined security
> issues upstream doesn't want talk about" is not enough and makes _everyone_
> look bad.

OK. Tell me what I should do for the next release which will have a similar crop of bug fixes. I want to say to people: you really should upgrade. There are potential vulnerabilities, but not every bug is a vulnerability even if the bug *might* be turned into a vulnerability.

As far as I am aware, no other opensource project is expected to file its own CVEs against the bugs that it fixes. How are we any different and what are we supposed to do when we find a bug a fix it?

Yours,
Martin