From: Martin H. <mar...@si...> - 2016-01-20 21:32:58
|
Dear All, Announcing the latest release of the Graphite2 engine. This is just a bug fix release. The files are available from: http://sourceforge.net/projects/silgraphite/files/graphite2/graphite2-1.3.5.tgz/download http://sourceforge.net/projects/silgraphite/files/graphite2/graphite2-minimal-1.3.5.tgz/download https://github.com/silnrsi/graphite/releases/download/1.3.5/graphite2-1.3.5.tgz https://github.com/silnrsi/graphite/releases/download/1.3.5/graphite2-minimal-1.3.5.tgz Those locations also have .sha1sum Notice that the minimal source tree just contains the minimum files needed for building and embedding the graphite library with no tests, etc. The full tree including tests is in the main source tarball. Here is the changelog: 1.3.5 . Bug fixes . Security bug fix . Fix ARM misalignment problem . Track latest cmake Enjoy. GB, Martin |
From: Rene E. <re...@de...> - 2016-01-20 22:34:18
|
Hi, On Wed, Jan 20, 2016 at 03:01:22PM -0600, Martin Hosken wrote: > 1.3.5 > . Bug fixes > . Security bug fix Hm? What? Details? What versions affected? What is the bug/fix? Will we need to fix past versions? That one is not enough info at all and too brief. 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 |
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-21 02:28:06
|
Dear Rene, > On Wed, Jan 20, 2016 at 03:01:22PM -0600, Martin Hosken wrote: > > 1.3.5 > > . Bug fixes > > . Security bug fix > > Hm? What? Details? What versions affected? What is the bug/fix? > Will we need to fix past versions? I don't know the principles here. Is it best to give full disclosure or just give that it's a security bug fix and therefore people should fix past versions ideally? Yours, Martin |
From: Rene E. <re...@de...> - 2016-01-21 08:36:40
|
On Wed, Jan 20, 2016 at 08:01:39PM -0600, Martin Hosken wrote: > Dear Rene, > > > On Wed, Jan 20, 2016 at 03:01:22PM -0600, Martin Hosken wrote: > > > 1.3.5 > > > . Bug fixes > > > . Security bug fix > > > > Hm? What? Details? What versions affected? What is the bug/fix? > > Will we need to fix past versions? > > I don't know the principles here. Is it best to give full disclosure or just give that it's a security bug fix and therefore people should fix past versions ideally? If it was a "real" exploitable security bug, yes. And IMHO "or" in your above sentence does not make sense at all - did you mean "and"?; if it is one people _should_ fix past versions and this of course includes the patch one needs to apply and descriprion of the bug (for the security announcement). See e.g. http://www.debian.org/security/ And now since it's in the changelog/the announcement, everyone knows there is "something" now anyway... Regards, Rene |
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-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 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: John T. <joh...@si...> - 2016-01-21 15:18:07
|
Seems to me that if there is a serious, exploitable security problem we should first inform any colleagues who might want to patch their products (e.g., FireFox) before the problem is widely 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. 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. JohnT On Thu, Jan 21, 2016 at 2:11 AM, Rene Engelhard <re...@de...> wrote: > On Wed, Jan 20, 2016 at 08:01:39PM -0600, Martin Hosken wrote: > > Dear Rene, > > > > > On Wed, Jan 20, 2016 at 03:01:22PM -0600, Martin Hosken wrote: > > > > 1.3.5 > > > > . Bug fixes > > > > . Security bug fix > > > > > > Hm? What? Details? What versions affected? What is the bug/fix? > > > Will we need to fix past versions? > > > > I don't know the principles here. Is it best to give full disclosure or > just give that it's a security bug fix and therefore people should fix past > versions ideally? > > If it was a "real" exploitable security bug, yes. And IMHO "or" in your > above sentence does not make sense at all - did you mean "and"?; if it is > one > people _should_ fix past versions and this of course includes the patch one > needs to apply and descriprion of the bug (for the security announcement). > > See e.g. http://www.debian.org/security/ > > And now since it's in the changelog/the announcement, everyone knows there > is "something" now anyway... > > Regards, > > Rene > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 > _______________________________________________ > Silgraphite-devel mailing list > Sil...@li... > https://lists.sourceforge.net/lists/listinfo/silgraphite-devel > |
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 |
From: Neil M. <nei...@si...> - 2016-01-21 16:10:16
|
<html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> On 21/01/16 01:11 AM, Rene Engelhard wrote:<br> <blockquote cite="mid:201...@re..." type="cite">... if it is [an exploitable security bug] people _should_ fix past versions and this of course includes the patch one needs to apply and description of the bug (for the security announcement).<br> </blockquote> <br> There's some implicit information here that needs to be made explicit. Both Debian and Ubuntu operate a policy that security vulnerabilities are _not_ fixed by upgrading to a newer upstream version. Instead, a minimal patch is applied that just fixes the vulnerability and nothing else. See <a class="moz-txt-link-rfc2396E" href="https://wiki.ubuntu.com/StableReleaseUpdates"><https://wiki.ubuntu.com/StableReleaseUpdates></a> for a full explanation.<br> <br> Usually this can be done by cherry-picking the upstream commit(s) that fix the bug, but sometimes there are conflicts. It greatly eases the burden on third-party integrators if the upstream developers can provide those patches, since they're in a much better position to see how to resolve conflicts, if any.<br> <br> Ideally, these patches would be provided, eg by contacting the Debian security team, _before_ the upstream commits are made available publicly. The Debian security FAQ says:<br> <br> <blockquote type="cite">If you learn about a security problem, either in one of your own packages or in someone else's please always contact the security team. If the Debian security team confirms the vulnerability and other vendors are likely to be vulnerable as well, they usually contact other vendors as well. If the vulnerability is not yet public they will try to coordinate security advisories with the other vendors, so all major distributions are in sync.</blockquote> <br> </body> </html> |
From: Rene E. <re...@de...> - 2016-01-21 16:22:28
|
On Thu, Jan 21, 2016 at 08:40:13AM -0700, Neil Mayhew wrote: > Ideally, these patches would be provided, eg by contacting the Debian > security team, _before_ the upstream commits are made available publicly. It suffices to make the actual fixes available. And they are in git (see below). > The Debian security FAQ says: > > If you learn about a security problem, either in one of your own > packages or in someone else's please always contact the security team. > If the Debian security team confirms the vulnerability and other vendors > are likely to be vulnerable as well, they usually contact other vendors > as well. If the vulnerability is not yet public they will try to > coordinate security advisories with the other vendors, so all major > distributions are in sync. Which is directed to the package maintainers. If it's already public they either prepare packages themselves by using above mentioned patches or I upload them to the security queue myself (which I did for the LibreOffice updates in the past) I don't think that upstreams should contact every individual security team. :) But right now we are talking in vain here since the entry in the ChangeLog is to completely unclear. Whether it's a minimal problem, some fuzz problem (which might or might not be exploitable, git shows fuzz patches some months old...) or something else. That should be cleared up by the graphite2 people first. Regards, Rene |
From: Martin H. <mar...@si...> - 2016-01-22 14:55:54
|
Dear All, > > The Debian security FAQ says: > > > > If you learn about a security problem, either in one of your own > > packages or in someone else's please always contact the security team. > > If the Debian security team confirms the vulnerability and other vendors > > are likely to be vulnerable as well, they usually contact other vendors > > as well. If the vulnerability is not yet public they will try to > > coordinate security advisories with the other vendors, so all major > > distributions are in sync. > > Which is directed to the package maintainers. > > If it's already public they either prepare packages themselves by using above mentioned > patches or I upload them to the security queue myself (which I did for the LibreOffice updates > in the past) > I don't think that upstreams should contact every individual security team. :) > > But right now we are talking in vain here since the entry in the ChangeLog is to completely > unclear. Whether it's a minimal problem, some fuzz problem (which might or might not be > exploitable, git shows fuzz patches some months old...) or something else. > > That should be cleared up by the graphite2 people first. OK. Here goes. The bugs will be disclosed in due course from here: http://www.talosintel.com/vulnerability-reports/ as: TALOS-CAN-0058: A suitably crafted font can result in arbitrary code execution. TALOS-CAN-0059: A suitably crafted font can result in a buffer overflow. Debian bug: On ARM, use of collision avoidance can result in a misaligned memory access violation. I have no idea *when* the TALOS bugs will be made public, but if anyone really wants the details, I am happy to send them the bug reports offline. Firefox has already been informed and is in process. Yours, Martin |
From: Rene E. <re...@de...> - 2016-01-22 15:51:47
|
Hi, On Fri, Jan 22, 2016 at 08:55:42AM -0600, Martin Hosken wrote: > The bugs will be disclosed in due course from here: http://www.talosintel.com/vulnerability-reports/ as: > > TALOS-CAN-0058: > A suitably crafted font can result in arbitrary code execution. > > TALOS-CAN-0059: > A suitably crafted font can result in a buffer overflow. OK. > I have no idea *when* the TALOS bugs will be made public, but if anyone really wants the details, I am happy to send them the bug reports offline. Please. Ideally including which versions are affected (in my case I'd need to patch 1.1.3 and 1.2.4) and which patches fix it... Regards, Rene |
From: Martin H. <mar...@si...> - 2016-01-23 17:08:46
|
Dear Rene, > Please. > Ideally including which versions are affected (in my case I'd need to patch > 1.1.3 and 1.2.4) and which patches fix it... There are no patches against 1.2.4 or 1.1.3. 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. I'm afraid we have not kept track of precisely which patches provide security level bug fixes and there are a lot between 1.1.3 and 1.3.5. In addition, the code has changed a lot between those versions such that identifying which security bugs apply on which version of the code and even whether the bug fix works in that context is a difficult path to take. Instead it's easier just to upgrade the library. The project's policy is to ensure backward compatibility at the API level, but not at the feature level. We also don't separate security bug fixes from feature bug fixes. Sometimes the category is easy to identify but often it is not. Yours, Martin |
From: Rene E. <re...@de...> - 2016-01-23 18:41:09
|
Hi, On Sat, Jan 23, 2016 at 11:08:37AM -0600, Martin Hosken wrote: > > Please. > > Ideally including which versions are affected (in my case I'd need to patch > > 1.1.3 and 1.2.4) and which patches fix it... > > There are no patches against 1.2.4 or 1.1.3. As Neil already said, we don't do that[1]. Whether it has a compatible interface or not is not relevant. > 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 so at least r-deps need to be rebuilt, too. Which is a no-go[2]. You want us to release a graphite2 and a libreoffice and a ... update? > I'm afraid we have not kept track of precisely which patches provide security level bug fixes and there are a lot between 1.1.3 and 1.3.5. In addition, the code has changed a lot between those versions such that identifying which security bugs apply on which version of the code and even whether the bug fix works in that context is a difficult path to take. Instead it's easier just to upgrade the library. > But it's not what makes most sense. > The project's policy is to ensure backward compatibility at the API level, but not at the feature level. We also don't separate security bug fixes from feature bug fixes. Sometimes the category is easy to identify but often it is not. 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) Regards, Rene [1] except in cases where upstreams behave brokenly and didn't publicalize issues or patches themselves in a sensible manner. Like MySQL... This is NOT the rule. [2] It can happen in cases for [1] but it's rare. |