Menu
▾
▴
silgraphite-devel
|
From: Martin H. <mar...@si...> - 2016-02-29 07:59:19
|
This is to announce the immediate availability of version 1.3.6 of the Graphite engine. It is available from the usual sources: https://github.com/silnrsi/graphite/releases/download/1.3.6/graphite-1.3.6.tgz https://github.com/silnrsi/graphite/releases/download/1.3.6/graphite-minimal-1.3.6.tgz https://github.com/silnrsi/graphite/releases/download/1.3.6/graphite-1.3.6.sha1sum https://sourceforge.net/projects/silgraphite/files/graphite2/graphite-1.3.6.tgz/download https://sourceforge.net/projects/silgraphite/files/graphite2/graphite-minimal-1.3.6.tgz/download https://sourceforge.net/projects/silgraphite/files/graphite2/graphite-1.3.6.sha1sum/download This is purely a security bug fixes release. There are a number of bug fixes in this release. There are no feature improvements or fixes. The release is binary compatible with any other 1.3.x version and also with 1.2.x (in that it has an API superset and corresponding library version increase and age over the 1.2.x series). For those wanting to backport fixes, they should take all the patches in this version or better yet, just upgrade to 1.3.6. Hope that helps. I'm sorry if I still don't know how to properly report such releases. I'm willing to keep learning. Feel free to submit what I should have said :) Yours, Martin |
|
From: Rene E. <re...@de...> - 2016-02-29 10:29:01
|
[ yes, me again ] Hi, On Mon, Feb 29, 2016 at 02:59:05PM +0700, Martin Hosken wrote: > This is purely a security bug fixes release :( > For those wanting to backport fixes, they should take all the patches in this version or better yet, just upgrade to 1.3.6. ... > Hope that helps. I'm sorry if I still don't know how to properly report such releases. I'm willing to keep learning. Feel free to submit what I should have said :) CVE? some-other-ID? Details? "Some security issues" are not enough. Either you disclose it directly or you disclose it somewhere private (with patches) so that people can get updates out and then dicslose it publically on the release of the "official" new version... We need it for a advisory like https://www.debian.org/security/2016/dsa-3479 (and of course for tracking it..) Regards, Rene |
|
From: Martin H. <mar...@si...> - 2016-03-01 02:32:56
|
Dear Rene, > > Hope that helps. I'm sorry if I still don't know how to properly report such releases. I'm willing to keep learning. Feel free to submit what I should have said :) > > CVE? some-other-ID? Details? I fix and release bugs loooong before they become CVEs. So no. I hope I never have to release code to fix an existing CVE. The first I hear of CVEs is once a bug becomes public and having public security bugs unfixed is not something I ever want to see. If you like I can give you a long list of Mozilla secure bugs that you probably don't have access too. > "Some security issues" are not enough. Either you disclose > it directly or you disclose it somewhere private (with patches) so that people can > get updates out and then dicslose it publically on the release of the "official" new > version... The patches are in the repo. I'm sorry I don't get this. Do I have to produce a special document for every fuzz bug that comes out from the security guys, because there are a lot and that kind of admin will kill me. As far as you are concerned I fixed a bunch of bugs and you are advised that some may have security implications and that therefore you would be wise to take the release. There is no public paper trail on any of them, although there may be in the future. But nobody tells me that until way after I have released the fixes. > We need it for a advisory like > https://www.debian.org/security/2016/dsa-3479 (and of course > for tracking it..) 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: 1) bugs that are fixed in the pre-public announcement period that, therefore do not have a CVE number yet. 2) bugs that will never be announced publicly and so will never get a CVE number 3) the inability before a CVE is announced, of knowing the difference between 1 & 2 Anyway, if and when someone tells me about a CVE on graphite, I will do my best to tell them in which release that particular CVE was already fixed. And on that basis, I fully expect that there will be a 1.3.7 within 90 days. I am kicking myself for not waiting one more day before releasing 1.3.6. ah well. Yours, Martin |
|
From: Rene E. <re...@de...> - 2016-03-01 06:21:06
|
Hi, 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". 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. > 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. > 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. Regards. |
|
From: Martin H. <mar...@si...> - 2016-03-01 07:12:16
|
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 |
|
From: Rene E. <re...@de...> - 2016-03-01 08:16:32
|
Hi, On Tue, Mar 01, 2016 at 01:40:52PM +0700, Martin Hosken wrote: > > 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? If it's not a exploitable security bug, yes. > > 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? Yes, basically. > > > 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. Yeah, that one went wrong already. > 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. Yes, that always is s fine line, I know, but *recommending* to upgrade doesn't immediately make distos who normally do not change versions in their released versions automatically do so. There has to be reasons, and that one has to mentioned in the advisory/uzpdate announcement. Some "might" is not veryx good there.. > 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? Sorry, this is not true. CVEs also get assigned by the respective authors sometimes if they get reported a issue. For LO I know of the past ones that whoever reported it to us and when they didn't have one RH or whoever got us a CVE. TTBOMK that also happens with MySQL and their issues, glibc and their issues, Linux itself, you get it. Of course CVEs also get assigned by sdomeone else (reporter?) too. But a CVE isn't a must (although nice for tracking), *details* and whether one must update is. As said, "Some security things" is totally unclear and make the stuff be in a limbo. Regards, Rene |
|
From: Martin H. <mar...@si...> - 2016-03-08 01:56:01
|
Dear Rene, Mozilla seem to have assigned a bunch of CVEs relevant to the current release. The following CVEs are all fixed by 1.3.6: CVE-2016-1969, CVE-2016-2796, CVE-2016-1977, CVE-2016-2799 There are no other known outstanding CVEs on Graphite. Fuzzing continues and there will be a 1.3.7 in due course (a couple of weeks?) HTH, Yours, Martin |
|
From: Rene E. <re...@de...> - 2016-03-14 07:35:53
|
Hi, On Tue, Mar 08, 2016 at 08:55:44AM +0700, Martin Hosken wrote: > Mozilla seem to have assigned a bunch of CVEs relevant to the current release. The following CVEs are all fixed by 1.3.6: > > CVE-2016-1969, CVE-2016-2796, CVE-2016-1977, CVE-2016-2799 Thanks. Forwarded that to your security team and they pointed me to https://www.mozilla.org/en-US/security/advisories/mfsa2016-37/ But that lists mnore/different CVEs? What about that? And: Why could this be mentioned there and not here when people ask about what the exact issues are? I mean, CVEs are nice, but infos like this are needed to write the advisory without you or the advisory writer looking bad. That said, we got a DSA now yesterday finally: https://www.debian.org/security/2016/dsa-3515DSA Regards, Rene |
|
From: Martin H. <mar...@si...> - 2016-03-14 09:40:05
|
Dear Rene, > Forwarded that to your security team and they pointed me to > https://www.mozilla.org/en-US/security/advisories/mfsa2016-37/ > > But that lists mnore/different CVEs? What about that? > > And: Why could this be mentioned there and not here when people ask about > what the exact issues are? I mean, CVEs are nice, but infos like > this are needed to write the advisory without you or the advisory > writer looking bad. Probably because that was the first I heard of it. I have a correspondence list between CVEs and commit hashes should anyone want it offline. > That said, we got a DSA now yesterday finally: > https://www.debian.org/security/2016/dsa-3515DSA This page didn't come up for me. Yours, Martin |
|
From: Rene E. <re...@de...> - 2016-03-14 09:53:16
|
On Mon, Mar 14, 2016 at 04:39:53PM +0700, Martin Hosken wrote: > I have a correspondence list between CVEs and commit hashes should anyone want it offline. So why was this not posted to this list when I initially asked for information about the issues? In this case it doesn't really matter as ~ anything here was security, but for "normal" circumstances where you don't just update the lib as a whole to a new version but just cherry-üpick the fixed that info is important. > > That said, we got a DSA now yesterday finally: > > https://www.debian.org/security/2016/dsa-3515DSA > > This page didn't come up for me. Yeah, sorry, cut'n'paste error: ttps://www.debian.org/security/2016/dsa-3515 Regards, Rene |
|
From: Martin H. <mar...@si...> - 2016-03-14 10:15:17
|
Dear Rene, > So why was this not posted to this list when I initially asked for information > about the issues? Because the CVEs weren't raised until after 1.3.6 was released. The same will happen for 1.3.7. My understanding is that Mozilla will wait for me to get the release out before they request the CVE allocations. So I can't tell you about something that hasn't happened yet. I would be happy for Mozilla to raise the CVEs earlier. But it is also nice to be able to say that the bug is fixed in a release, when the CVE is raised. There is clearly a chicken and an egg involved in this. In this case I will do the release, and as soon as the CVE allocations are made and I become aware of them (which isn't necessarily immediate) I will produce a mapping from CVEs to commits for those who want it. But since there are no CVEs out (that we are aware of) for what will be in 1.3.7 I cannot give them to you at the point when I release 1.3.7. Yours, Martin |
Thanks for helping keep SourceForge clean.
X