Menu
▾
▴
silgraphite-devel — SILGraphite development
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(28) |
Dec
(50) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(143) |
Feb
(48) |
Mar
(27) |
Apr
(22) |
May
(20) |
Jun
(45) |
Jul
(117) |
Aug
(108) |
Sep
(55) |
Oct
(41) |
Nov
(46) |
Dec
(25) |
| 2004 |
Jan
(20) |
Feb
(42) |
Mar
(29) |
Apr
(16) |
May
(38) |
Jun
(21) |
Jul
(5) |
Aug
(23) |
Sep
(26) |
Oct
(62) |
Nov
(25) |
Dec
(109) |
| 2005 |
Jan
(26) |
Feb
(44) |
Mar
(17) |
Apr
(4) |
May
(24) |
Jun
(10) |
Jul
|
Aug
(35) |
Sep
(60) |
Oct
(49) |
Nov
(30) |
Dec
(58) |
| 2006 |
Jan
(58) |
Feb
(25) |
Mar
(57) |
Apr
(14) |
May
(4) |
Jun
|
Jul
(3) |
Aug
(6) |
Sep
(2) |
Oct
(8) |
Nov
(12) |
Dec
(20) |
| 2007 |
Jan
(7) |
Feb
(27) |
Mar
(85) |
Apr
(51) |
May
(45) |
Jun
(21) |
Jul
(54) |
Aug
(34) |
Sep
(13) |
Oct
(19) |
Nov
(20) |
Dec
|
| 2008 |
Jan
(78) |
Feb
(44) |
Mar
(17) |
Apr
(3) |
May
(19) |
Jun
(2) |
Jul
(8) |
Aug
(15) |
Sep
(13) |
Oct
(10) |
Nov
(1) |
Dec
(3) |
| 2009 |
Jan
|
Feb
(11) |
Mar
|
Apr
(4) |
May
(4) |
Jun
(8) |
Jul
(20) |
Aug
(26) |
Sep
(2) |
Oct
(8) |
Nov
(2) |
Dec
|
| 2010 |
Jan
(18) |
Feb
|
Mar
(1) |
Apr
(49) |
May
(20) |
Jun
(12) |
Jul
(5) |
Aug
(6) |
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(1) |
| 2011 |
Jan
(3) |
Feb
(4) |
Mar
(1) |
Apr
(3) |
May
|
Jun
(7) |
Jul
(30) |
Aug
(17) |
Sep
(26) |
Oct
(15) |
Nov
|
Dec
(4) |
| 2012 |
Jan
(3) |
Feb
(15) |
Mar
(20) |
Apr
(5) |
May
(1) |
Jun
(42) |
Jul
(11) |
Aug
(10) |
Sep
(12) |
Oct
|
Nov
(5) |
Dec
|
| 2013 |
Jan
(6) |
Feb
(2) |
Mar
(2) |
Apr
(3) |
May
(4) |
Jun
(6) |
Jul
(4) |
Aug
|
Sep
|
Oct
(3) |
Nov
(6) |
Dec
|
| 2015 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(10) |
Sep
(2) |
Oct
(2) |
Nov
|
Dec
|
| 2016 |
Jan
(17) |
Feb
(3) |
Mar
(11) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Martin H. <mar...@si...> - 2020-04-01 05:19:36
|
Dear All, Graphite isn't dead, it's just maturing and it has been over a year since our last release. This release fixes a few minor bugs, some with possible security implications, so those who want to cherry pick can get in contact. Having said that, this version is API compatible with previous versions and any new features (the ability to support unlisted features) are only present in as yet unreleased fonts. So I would recommend those wanting just a security release to take the latest version. The files are available from the usual sources: https://github.com/silnrsi/graphite/releases/download/1.3.14/graphite2-1.3.14.tgz https://github.com/silnrsi/graphite/releases/download/1.3.14/graphite2-minimal-1.3.14.tgz https://github.com/silnrsi/graphite/releases/download/1.3.14/graphite2-1.3.14.sha256sum https://sourceforge.net/projects/silgraphite/files/graphite2/graphite2-1.3.14.tgz/download https://sourceforge.net/projects/silgraphite/files/graphite2/graphite2-minimal-1.3.14.tgz/download https://sourceforge.net/projects/silgraphite/files/graphite2/graphite2-1.3.14.sha256sum/download We're still thinking of deprecating sourceforge :) Yours, Martin Hosken. |
|
From: Martin H. <mar...@si...> - 2018-03-05 06:25:48
|
Dear All, We are pleased to announce a new release of the Graphite2 engine. The primary purpose of this release is to release the various bugs that were fixed as a result of a pentest code review. The review only exposed minor issues. The only other changes to this release are minor bug fixes in the collision avoidance and lz4 decompressor. No known CVEs were used in the making of this release. The files are available from the usual sources: https://github.com/silnrsi/graphite/releases/download/1.3.11/graphite2-1.3.11.tgz https://github.com/silnrsi/graphite/releases/download/1.3.11/graphite2-minimal-1.3.11.tgz https://github.com/silnrsi/graphite/releases/download/1.3.11/graphite2-1.3.11.sha1sum https://sourceforge.net/projects/silgraphite/files/graphite2/graphite2-1.3.11.tgz/download https://sourceforge.net/projects/silgraphite/files/graphite2/graphite2-minimal-1.3.11.tgz/download https://sourceforge.net/projects/silgraphite/files/graphite2/graphite2-1.3.11.sha1sum/download We are thinking of deprecating the sourceforge release channel. Please let us know if this would be a problem for you. Yours, Martin Hosken |
|
From: Martin H. <mar...@si...> - 2017-05-05 16:38:11
|
Dear All, Available immediately is v1.3.10 of the Graphite engine. This version is basically a bunch of fuzz bug fixes. You'll want them all. All current and all near future CVEs are covered by this release. The release is available from all the usual haunts: https://sourceforge.net/projects/silgraphite/files/graphite2/graphite2-1.3.10.tgz/download https://sourceforge.net/projects/silgraphite/files/graphite2/graphite2-minimal-1.3.10.tgz/download https://sourceforge.net/projects/silgraphite/files/graphite2/graphite2-1.3.10.sha1sum/download https://github.com/silnrsi/graphite/releases/download/1.3.10/graphite2-1.3.10.tgz https://github.com/silnrsi/graphite/releases/download/1.3.10/graphite2-minimal-1.3.10.tgz https://github.com/silnrsi/graphite/releases/download/1.3.10/graphite2-1.3.10.sha1sum Thank you. Yours, Martin |
|
From: Martin H. <mar...@si...> - 2016-11-11 10:53:01
|
Dear All, The latest Graphite engine has been released. It fixes a few minor bugs in the collision avoidance, but those changes may move some nuktas as smidgen (but enough to look nicer!). There is also what I consider may be a potential security bug. If anyone wants the details for cherry picking, please contact me privately. The sources are available from the usual places: https://github.com/silnrsi/graphite/releases/tag/1.3.9 https://sourceforge.net/projects/silgraphite/files/graphite2/ The Changelog says: . Add Collision COLL_ISSPACE to allow for visible spaces in collision avoidance . Add segment and pass direction information to tracing output . Bug fix rule length testing in 32-bit . Increase slanted margin distances for collision avoidance . Change kerning algorithm to simple outline expansion. Seems to make no visible difference. . Add trace2svg to test tools My hope, probably forlorn, is that this release will stand for a good long while. Yours, Martin |
|
From: Martin H. <mar...@si...> - 2016-03-31 05:00:08
|
Dear All, Herewith release 1.3.8 of the graphite engine. This release is primarily a feature bug fix release with what I expect to be no security bugs in there even if a few fuzz bugs have been fixed. The primary aim of releasing now is to get the feature bugs fixed in downstream apps like libreoffice and firefox. The rate of fuzz bug identification fell off a cliff after 1.3.7. The files are available from the usual places: https://github.com/silnrsi/graphite/releases/download/1.3.8/graphite2-1.3.8.tgz https://github.com/silnrsi/graphite/releases/download/1.3.8/graphite2-minimal-1.3.8.tgz https://github.com/silnrsi/graphite/releases/download/1.3.8/graphite2-1.3.8.sha1sum https://sourceforge.net/projects/silgraphite/files/graphite2/graphite2-1.3.8.tgz/download https://sourceforge.net/projects/silgraphite/files/graphite2/graphite2-minimal-1.3.8.tgz/download https://sourceforge.net/projects/silgraphite/files/graphite2/graphite2-1.3.8.sha1sum/download And from the changelog: . Various bug fixes arising from fuzzing . Fix regression that stopped piglatin from working . Make collision avoidance kerning give more regular results . Minor modification to clustering algorithm to handle variable width chars Yours, Martin |
|
From: Martin H. <mar...@si...> - 2016-03-15 07:35:50
|
Dear All, After lots of fuzzing, a whole new crop of bugs have been fixed. We are all quietly hopeful that the rate of discovery will fall off sharply now. This release is available from the usual suspects: https://github.com/silnrsi/graphite/releases/download/1.3.7/graphite2-1.3.7.tgz https://github.com/silnrsi/graphite/releases/download/1.3.7/graphite2-minimal-1.3.7.tgz https://github.com/silnrsi/graphite/releases/download/1.3.7/graphite-1.3.7.sha1sum https://sourceforge.net/projects/silgraphite/files/graphite2/graphite2-1.3.7.tgz/download https://sourceforge.net/projects/silgraphite/files/graphite2/graphite2-minimal-1.3.7.tgz/download https://sourceforge.net/projects/silgraphite/files/graphite2/graphite-1.3.7.sha1sum/download There are no known security reports relevant to this release of Graphite, but there will probably be some and I will make available the details once the reports exist and I hear about them. For those interested in less nefarious uses of Graphite, we are announcing that we intend to get rid of the Segment Cache. If you are using it, you might like to let us know. If we don't hear from anyone, we will assume nobody is using it and get rid of it quicker. Yours, Martin |
|
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 |
|
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 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 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-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-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-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 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 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-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-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: Martin H. <mar...@si...> - 2016-02-08 01:46:53
|
Dear All, Just to report that the it was these security bugs: http://blog.talosintel.com/2016/02/vulnerability-spotlight-libgraphite.html that I was referring to in the recent 1.3.5 changelog. Yours, Martin |
|
From: Martin H. <mar...@si...> - 2016-01-26 15:30:37
|
Dear Rene, > On Mon, Jan 25, 2016 at 07:26:35PM -0600, Martin Hosken wrote: > > Could we patch the 1.3.5 when building for 1.1.3 replacement and libgraphite2.so.2.0.0 such that the libtool values are appropriate given that the API supports the v2 library without change. That it also supports the v3 api is incidental and not important for an update to 1.1.3. > > We could, I thought about that too and I wanted to say that I am lost where in > cmake this was set but I found it already :) > > Did it and works. Congratulations and thanks. BTW the doc/release.txt is our release process. I'm open to suggestions on improvements there. > The question still is whether it will be accepted or not because it's a pretty > big diff even compared to "stock" 1.3.5..[1]. But that is my problem... Thank you. Yours, Martin |
|
From: Rene E. <re...@de...> - 2016-01-26 09:45:34
|
Hi, On Mon, Jan 25, 2016 at 07:26:35PM -0600, Martin Hosken wrote: > Could we patch the 1.3.5 when building for 1.1.3 replacement and libgraphite2.so.2.0.0 such that the libtool values are appropriate given that the API supports the v2 library without change. That it also supports the v3 api is incidental and not important for an update to 1.1.3. We could, I thought about that too and I wanted to say that I am lost where in cmake this was set but I found it already :) Did it and works. The question still is whether it will be accepted or not because it's a pretty big diff even compared to "stock" 1.3.5..[1]. But that is my problem... Regards, Rene [1] % debdiff graphite2_1.3.5-1.dsc graphite2_1.3.5-1\~deb7u1.dsc | diffstat changelog | 10 ++++++++ control | 35 +++++++++++++++++++++++++------ libgraphite2-2.0.0-dbg.lintian-overrides | 1 libgraphite2-2.0.0.install | 1 libgraphite2-2.0.0.lintian-overrides | 1 libgraphite2-2.0.0.shlibs | 1 libgraphite2-3-dbg.lintian-overrides | 1 libgraphite2-3-dbg.substvars | 2 - libgraphite2-3.install | 1 libgraphite2-3.links | 2 - libgraphite2-3.lintian-overrides | 1 libgraphite2-3.shlibs | 1 patches/revert-to-old-SONAME.diff | 17 +++++++++++++++ patches/series | 1 rules | 9 ++----- 15 files changed, 64 insertions(+), 20 deletions(-) |
|
From: Martin H. <mar...@si...> - 2016-01-26 01:26:43
|
Dear Rene, > > > 1.1.3 is libgraphite2.so.2.0.0 > > > 1.2.4 and 1.3.5 are libgraphite2.so.3 > > > > That's a packaging choice. > > So, it's not. It's what the build gives and the .so records. > > And normally the package name follows the SONAME, so we'd need the above > anyway, given a package rename and rebuilding the r-deps must not be done in > (old)stable. THAT is a packaging choice, not the difference between SONAMES. Could we patch the 1.3.5 when building for 1.1.3 replacement and libgraphite2.so.2.0.0 such that the libtool values are appropriate given that the API supports the v2 library without change. That it also supports the v3 api is incidental and not important for an update to 1.1.3. > But some keep-track whether its a security fix and what the fix is is needed. > And be it in private notes. I did do that for 1.3.4 following. But oddly we took two bites to get some fixed so it's never simply one bug one patch. I'll try to keep that list going. Yours, Martin |
|
From: Rene E. <re...@de...> - 2016-01-24 10:09:56
|
Hi, On Sat, Jan 23, 2016 at 11:07:40PM -0600, Martin Hosken wrote: > > > Both of these should be upgraded to 1.3.5 which has a compatible interface with all previous versions. If it doesn't then we will work to address that. > > > > This is not true. > > > > 1.1.3 is libgraphite2.so.2.0.0 > > 1.2.4 and 1.3.5 are libgraphite2.so.3 > > That's a packaging choice. So, it's not. It's what the build gives and the .so records. And normally the package name follows the SONAME, so we'd need the above anyway, given a package rename and rebuilding the r-deps must not be done in (old)stable. THAT is a packaging choice, not the difference between SONAMES. > Yes 1.2.4 is v3 of the api but it also has an age of 1 meaning that it supports the v2. This means that the 1.3.5 code could be used as an upgrade within the libgraphite2.so.2.0.0. But I realise that that I do not understand Debian packaging well enough to know whether that is sufficient. The API is not what bothers me here (except that it would violate the "we only patch the bug and do no version updates here) but the problem here is the ABI/SONAME. (even though the ABI is compatible, the SONAME _did_ change) That still would neeed patching 1.3.5 to generate .so.2.0.0 still, or at least record that one in its SONAME - as when we wouldn't stuff built against the new library (like future libreoffice security updates) will end up having a dependency on .so.3 in it's binaries which would require the new package. At least the new packages' contents if we didn't rename the package to follow. A no-go for security updates either way. > Either way. We have no intention of doing a full security analysis on 1.1.3, given it was released over 3.5 years ago. Even 1.2.4 is over 2 years old. I'm afraid I'm not in a position to backport all the core structural changes between the older versions and the current version to handle the changes that solve the security problems. I understand that problem. It's difficult. It's also the case for other security updates sometimes where backporting patches is hard. > It should be noted that between 1.3.4 and 1.3.5 there are no feature changes, just bug fixes. The bug fixes can be split into build process fixes and code fixes. Whereas between 1.2.4 and 1.3.5 there were a lot of bugs fixed. How many were simply fuzz and how many had security implications, I'm afraid I didn't analyse. Instead I just went ahead and fixed them. I see. :( > > Then you should start to separate them. Upgrading to a full new release is a no-go > > (and if API/ABI/SONAME changed is impossible mostly) > > I'll gladly try to learn and do better in the future, especially considering I am expecting to enter a quieter period in Graphite's history. What do you see as the best way to do this? Mark what we consider to be security bug fixes in the git history? Nah, that's even worse given it then is public immediately when someone sees them in git without any responsible disclosure with a fixed release. But some keep-track whether its a security fix and what the fix is is needed. And be it in private notes. Regards, Rene |
|
From: Martin H. <mar...@si...> - 2016-01-24 05:07:51
|
Dear Rene, > > Both of these should be upgraded to 1.3.5 which has a compatible interface with all previous versions. If it doesn't then we will work to address that. > > This is not true. > > 1.1.3 is libgraphite2.so.2.0.0 > 1.2.4 and 1.3.5 are libgraphite2.so.3 That's a packaging choice. Yes 1.2.4 is v3 of the api but it also has an age of 1 meaning that it supports the v2. This means that the 1.3.5 code could be used as an upgrade within the libgraphite2.so.2.0.0. But I realise that that I do not understand Debian packaging well enough to know whether that is sufficient. Either way. We have no intention of doing a full security analysis on 1.1.3, given it was released over 3.5 years ago. Even 1.2.4 is over 2 years old. I'm afraid I'm not in a position to backport all the core structural changes between the older versions and the current version to handle the changes that solve the security problems. It should be noted that between 1.3.4 and 1.3.5 there are no feature changes, just bug fixes. The bug fixes can be split into build process fixes and code fixes. Whereas between 1.2.4 and 1.3.5 there were a lot of bugs fixed. How many were simply fuzz and how many had security implications, I'm afraid I didn't analyse. Instead I just went ahead and fixed them. > Then you should start to separate them. Upgrading to a full new release is a no-go > (and if API/ABI/SONAME changed is impossible mostly) I'll gladly try to learn and do better in the future, especially considering I am expecting to enter a quieter period in Graphite's history. What do you see as the best way to do this? Mark what we consider to be security bug fixes in the git history? Yours, Martin |
25 messages has been excluded from this view by a project administrator.