From jan.grant at bristol.ac.uk Wed Aug 1 03:03:57 2007 From: jan.grant at bristol.ac.uk (Jan Grant) Date: Wed, 1 Aug 2007 11:03:57 +0100 (BST) Subject: [security-dev 00010]: BUG: krb5 client leaks UDP, causes failure under load. Message-ID: <20070801103738.P54289@tribble.ilrt.bris.ac.uk> I've tried to raise this in the past; the opening of the relevant bits of the JDK have encouraged me to try again. sun.security.krb5.internal.UDPClient has no close() method; and the UDPClient-using code path in sun.security.krb5.KrbKdcReq (which has a few other close-to-the-coalface errors) consequently leaks FDs (unlike the TCP path, which has a try/finally that closes the socket properly). We're seeing a krb5 client application (the Yale CAS SSO) keel over in no time due to FD exhaustion. A trivial fix (the non-whitespace part of the diff is 8 lines) sorts this out. I've tried to report this in the past without much luck: engineers were initially very responsive then it got picked up and kind of fell flat. Whilst I'm chasing the beauracracy here to get a release signed, I think the patch itself is so trivial it probably doesn't warrant much concern. Full report is stashed here: http://www.freebsd.org/cgi/query-pr.cgi?pr=110912&cat=java including a patch against the contents of jdk_sec-1_5_0-src-scsl.zip; this affects all platforms. A unit test is hard to do; however if you look at support case 37763365 you should find a small piece of code (and associated typescipt) that demonstrates the krb5 client slowly using up UDP sockets. Eventually the GC will kick in and reclaim these; however, (1) relying on GC to manage any resource other than memory is a bug; (2) we're still seeing failures before GC has a chance to work. Let me know what I can do to progress this; according to various reports this fault has been around for a long time. It'd be good to knock it on the head. Cheers, jan -- jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ I am now available for general use under a modified BSD licence. From Seema.Malkani at Sun.COM Wed Aug 1 15:14:40 2007 From: Seema.Malkani at Sun.COM (Seema Malkani) Date: Wed, 01 Aug 2007 15:14:40 -0700 Subject: [security-dev 00011]: Re: BUG: krb5 client leaks UDP, causes failure under load. In-Reply-To: <20070801103738.P54289@tribble.ilrt.bris.ac.uk> References: <20070801103738.P54289@tribble.ilrt.bris.ac.uk> Message-ID: <46B105D0.4050907@Sun.COM> Thanks for reporting this issue. Apologies, don't know the details of how this report was missed. Sun bug-id 6588160 has been created from the webbug that you submitted. If you want us to evaluate your patch, please read following webpage on "how to contribute to the OpenJDK project" and sign the required agreement. http://openjdk.java.net/contribute/ Seema Jan Grant wrote: > I've tried to raise this in the past; the opening of the relevant bits > of the JDK have encouraged me to try again. > > sun.security.krb5.internal.UDPClient has no close() method; and the > UDPClient-using code path in sun.security.krb5.KrbKdcReq (which has a > few other close-to-the-coalface errors) consequently leaks FDs (unlike > the TCP path, which has a try/finally that closes the socket properly). > > We're seeing a krb5 client application (the Yale CAS SSO) keel over in > no time due to FD exhaustion. A trivial fix (the non-whitespace part of > the diff is 8 lines) sorts this out. > > > I've tried to report this in the past without much luck: engineers were > initially very responsive then it got picked up and kind of fell flat. > Whilst I'm chasing the beauracracy here to get a release signed, I think > the patch itself is so trivial it probably doesn't warrant much concern. > > Full report is stashed here: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=110912&cat=java > > including a patch against the contents of jdk_sec-1_5_0-src-scsl.zip; > this affects all platforms. > > A unit test is hard to do; however if you look at support case 37763365 > you should find a small piece of code (and associated typescipt) that > demonstrates the krb5 client slowly using up UDP sockets. > > Eventually the GC will kick in and reclaim these; however, (1) relying > on GC to manage any resource other than memory is a bug; (2) we're still > seeing failures before GC has a chance to work. > > Let me know what I can do to progress this; according to various reports > this fault has been around for a long time. It'd be good to knock it on > the head. > > Cheers, > jan > > From jan.grant at bristol.ac.uk Fri Aug 3 07:46:16 2007 From: jan.grant at bristol.ac.uk (Jan Grant) Date: Fri, 3 Aug 2007 15:46:16 +0100 (BST) Subject: [security-dev 00012]: Re: BUG: krb5 client leaks UDP, causes failure under load. In-Reply-To: <46B105D0.4050907@Sun.COM> References: <20070801103738.P54289@tribble.ilrt.bris.ac.uk> <46B105D0.4050907@Sun.COM> Message-ID: <20070803154516.T19992@tribble.ilrt.bris.ac.uk> On Wed, 1 Aug 2007, Seema Malkani wrote: > Thanks for reporting this issue. > > Apologies, don't know the details of how this report was missed. Sun bug-id > 6588160 has been created from the webbug that you submitted. > > If you want us to evaluate your patch, please read following webpage on "how > to contribute to the OpenJDK project" and sign the required agreement. > http://openjdk.java.net/contribute/ > > Seema Thanks for the prompt response. My contributor agreement should be with you now - just faxed through: Jan Grant, University of Bristol, and it's signed by James Lancaster (who's our head of technology transfer). Cheers, jsn -- jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ Rereleasing dolphins into the wild since 1998. From jfwfreo at tpgi.com.au Sun Aug 12 00:30:41 2007 From: jfwfreo at tpgi.com.au (Jonathan Wilson) Date: Sun, 12 Aug 2007 15:30:41 +0800 Subject: [security-dev 00013]: encryption regulations question Message-ID: <46BEB721.2040602@tpgi.com.au> According to http://www.epic.org/crypto/export_controls/regs_1_00.html specifically point 3 which refers to ?740.13 of the export controls, open source code which can be used for commercial purposes without payment of a license fee to the copyright holder can be exported under a license exemption. Can someone explain to me why this license exemption would not apply to OpenJDK encryption source code released under the GPL? From Andreas.Sterbenz at Sun.COM Sun Aug 12 23:55:02 2007 From: Andreas.Sterbenz at Sun.COM (Andreas Sterbenz) Date: Sun, 12 Aug 2007 23:55:02 -0700 Subject: [security-dev 00014]: Re: encryption regulations question In-Reply-To: <46BEB721.2040602@tpgi.com.au> References: <46BEB721.2040602@tpgi.com.au> Message-ID: <46C00046.9010500@sun.com> Jonathan Wilson wrote: > According to http://www.epic.org/crypto/export_controls/regs_1_00.html > specifically point 3 which refers to ?740.13 of the export controls, > open source code which can be used for commercial purposes without > payment of a license fee to the copyright holder can be exported under a > license exemption. Can someone explain to me why this license exemption > would not apply to OpenJDK encryption source code released under the GPL? Who is suggesting it would not apply? I don't think that Sun did so. If you are asking about the status of the open sourcing of the JDK crypto code, please see http://mail.openjdk.java.net/pipermail/discuss/2007-July/000116.html Andreas.