Date: Tue, 18 Aug 2009 15:58:03 +0200 From: Simon Josefsson <simon@...efsson.org> To: Jamie Strandboge <jamie@...onical.com> Cc: oss-security@...ts.openwall.com, gnutls-devel@....org Subject: Re: GnuTLS CVE-2009-2730 Patches Jamie Strandboge <jamie@...onical.com> writes: > On Sat, 15 Aug 2009, Simon Josefsson wrote: > >> Jamie Strandboge <jamie-Z7WLFzj8eWMS+FvcfC7Uqw@...lic.gmane.org> writes: >> >> > On Fri, 14 Aug 2009, Simon Josefsson wrote: >> > >> > Attached are preliminary patches for 2.4.1, 2.0.4 and 1.2.9 backported >> > from the advisory. >> >> Thank you! >> >> I have applied the 2.4.x patch on the gnutls_2_4_x branch, so it will be >> built and tested by the daily autobuilder from now on. I've tested that >> the nul-in-x509-names self-test works as expected with the 2.4 library. >> So in theory, it should be easy for me to make a v2.4.4 release from >> that branch. I wonder if this would helps anyone, though? I'd imagine >> that most people concerned with older releases are distributions that >> have to support older GnuTLS releases. And you aren't likely to use a >> new upstream release anyway, since you just apply the patches to your >> version. >> >> I'm also concerned that there have been plenty of _other_ serious >> problems in these old GnuTLS releases (check the security vulnerability >> page), and I haven't back-ported the fixes to those problems to these >> old branches. So if I make a release on that branch, I'd have to check >> what other serious problems would needs to be fixed for that branch to >> be secure -- which sounds like real work (for little gain). >> >> For these two reasons, I'd prefer to help you establish trust in the >> patches you developed rather than make releases on old branches. >> > > I'd agree with this. Vendors have likely backported all those other > fixes. However, having a place for people to get patches for older > releases would likely be beneficial going forward (like you are doing > with this one). This is especially true when considering your > aforementioned lack of resources. Right. If you and others provide patches for older versions, I can apply them on the git branches. Someone could even volunteer to become old-releases-maintainer and do it for me. It would indeed be useful if all vendors could look into the git repository to find the recommended patch for any version, rather than everyone having to spend time on identifying and testing patches by themselves. Alas, I don't have resources to do this, and I believe my time is best spent on maintaining the stable and development branches. /Simon
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.