From iris.clark at oracle.com Mon Feb 2 19:12:48 2015 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 2 Feb 2015 11:12:48 -0800 (PST) Subject: Java SE 6 Maintenance Draft Review (JSR 270) posted to jcp.org Message-ID: The Maintenance Draft Review contents for the Java SE 6 Platform JSR (270) was posted to jcp.org on 30 January [0]. The contents correspond to the updates outlined in the announcement [1]. The Review ends on 2 March 2015 with the Ballot running from 3-9 March 2015. As in the original announcement, assuming that the Maintenance Review Ballot succeeds, Oracle will produce a Maintenance Release [3] of JSR 270 which includes an updated Specification and RI only. The Maintenance Release is expected March 2015. Thanks, iris [0] https://jcp.org/en/jsr/detail?id=270 [1] http://mail.openjdk.java.net/pipermail/jdk6-dev/2015-January/003472.html From omajid at redhat.com Mon Feb 2 22:28:27 2015 From: omajid at redhat.com (Omair Majid) Date: Mon, 2 Feb 2015 17:28:27 -0500 Subject: [PATCH] Post-b34 Fixes In-Reply-To: <1185352924.3661114.1422565869880.JavaMail.zimbra@redhat.com> References: <603963234.3658028.1422565147377.JavaMail.zimbra@redhat.com> <1185352924.3661114.1422565869880.JavaMail.zimbra@redhat.com> Message-ID: <20150202222826.GA30277@redhat.com> * Andrew Hughes [2015-01-29 16:12]: > * OPENJDK6-51: Sync patch for 4873188 with 7 version > > The backport of 4873188 (TLS 1.1 support) accidentally incorporated part > of 7031830 (see below) and placed a chunk of code in a slightly different > position to where it is in 7. Neither issue results in a problem, but > this changeset just makes the diff between 6 & 7 smaller. I looked at the current code in jdk7 and it looks like this: // eventually compress as well. HandshakeStatus hsStatus = writer.writeRecord(eor, ea, writeMAC, writeCipher); /* * We only need to check the sequence number state for * non-handshaking record. * * Note that in order to maintain the handshake status * properly, we check the sequence number after the last * record writing process. As we request renegotiation * or close the connection for wrapped sequence number * when there is enough sequence number space left to * handle a few more records, so the sequence number * of the last record cannot be wrapped. */ if (connectionState < cs_ERROR && !isOutboundDone() && (hsStatus == HandshakeStatus.NOT_HANDSHAKING)) { if (checkSequenceNumber(writeMAC, eor.contentType())) { hsStatus = getHSStatus(null); } } /* * turn off the flag of the first application record if we really * consumed at least byte. */ if (isFirstAppOutputRecord && ea.deltaApp() > 0) { isFirstAppOutputRecord = false; } return hsStatus; The patch, however, changes the current placement in jdk6: writer.writeRecord(eor, ea, writeMAC, writeCipher); /* + * turn off the flag of the first application record if we really + * consumed at least byte. + */ + if (isFirstAppOutputRecord && ea.deltaApp() > 0) { + isFirstAppOutputRecord = false; + } + + /* * We only need to check the sequence number state for * non-handshaking record. * @@ -1279,14 +1287,6 @@ } } - /* - * turn off the flag of the first application record if we really - * consumed at least byte. - */ - if (isFirstAppOutputRecord && ea.deltaApp() > 0) { - isFirstAppOutputRecord = false; - } - return hsStatus; That looks like the current code in jdk6 matches what's in jdk7u and the patch makes it diverge. Is that right? Everything else looks fine. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From gnu.andrew at redhat.com Tue Feb 3 17:11:57 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 3 Feb 2015 12:11:57 -0500 (EST) Subject: [PATCH] Post-b34 Fixes In-Reply-To: <20150202222826.GA30277@redhat.com> References: <603963234.3658028.1422565147377.JavaMail.zimbra@redhat.com> <1185352924.3661114.1422565869880.JavaMail.zimbra@redhat.com> <20150202222826.GA30277@redhat.com> Message-ID: <1330463553.6099772.1422983517680.JavaMail.zimbra@redhat.com> ----- Original Message ----- > * Andrew Hughes [2015-01-29 16:12]: > > * OPENJDK6-51: Sync patch for 4873188 with 7 version > > > > The backport of 4873188 (TLS 1.1 support) accidentally incorporated part > > of 7031830 (see below) and placed a chunk of code in a slightly different > > position to where it is in 7. Neither issue results in a problem, but > > this changeset just makes the diff between 6 & 7 smaller. > > I looked at the current code in jdk7 and it looks like this: > > // eventually compress as well. > HandshakeStatus hsStatus = > writer.writeRecord(eor, ea, writeMAC, writeCipher); > > /* > * We only need to check the sequence number state for > * non-handshaking record. > * > * Note that in order to maintain the handshake status > * properly, we check the sequence number after the last > * record writing process. As we request renegotiation > * or close the connection for wrapped sequence number > * when there is enough sequence number space left to > * handle a few more records, so the sequence number > * of the last record cannot be wrapped. > */ > if (connectionState < cs_ERROR && !isOutboundDone() && > (hsStatus == HandshakeStatus.NOT_HANDSHAKING)) { > if (checkSequenceNumber(writeMAC, eor.contentType())) { > hsStatus = getHSStatus(null); > } > } > > /* > * turn off the flag of the first application record if we really > * consumed at least byte. > */ > if (isFirstAppOutputRecord && ea.deltaApp() > 0) { > isFirstAppOutputRecord = false; > } > > return hsStatus; > > The patch, however, changes the current placement in jdk6: > > writer.writeRecord(eor, ea, writeMAC, writeCipher); > > /* > + * turn off the flag of the first application record if we really > + * consumed at least byte. > + */ > + if (isFirstAppOutputRecord && ea.deltaApp() > 0) { > + isFirstAppOutputRecord = false; > + } > + > + /* > * We only need to check the sequence number state for > * non-handshaking record. > * > @@ -1279,14 +1287,6 @@ > } > } > > - /* > - * turn off the flag of the first application record if we really > - * consumed at least byte. > - */ > - if (isFirstAppOutputRecord && ea.deltaApp() > 0) { > - isFirstAppOutputRecord = false; > - } > - > return hsStatus; > > That looks like the current code in jdk6 matches what's in jdk7u and the > patch > makes it diverge. Is that right? > > Everything else looks fine. > > Thanks, > Omair > > -- > PGP Key: 66484681 (http://pgp.mit.edu/) > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 > No. Good catch. It seems IcedTea has both, thanks to the original security patch putting it in one place, then the upstream changeset placing it in the other. At least our original was right :) I'll post another webrev later. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From gnu.andrew at redhat.com Tue Feb 3 22:26:43 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 3 Feb 2015 17:26:43 -0500 (EST) Subject: [PATCH] Post-b34 Fixes In-Reply-To: <1330463553.6099772.1422983517680.JavaMail.zimbra@redhat.com> References: <603963234.3658028.1422565147377.JavaMail.zimbra@redhat.com> <1185352924.3661114.1422565869880.JavaMail.zimbra@redhat.com> <20150202222826.GA30277@redhat.com> <1330463553.6099772.1422983517680.JavaMail.zimbra@redhat.com> Message-ID: <912194022.6325864.1423002403969.JavaMail.zimbra@redhat.com> ----- Original Message ----- > > > ----- Original Message ----- > > * Andrew Hughes [2015-01-29 16:12]: > > > * OPENJDK6-51: Sync patch for 4873188 with 7 version > > > > > > The backport of 4873188 (TLS 1.1 support) accidentally incorporated part > > > of 7031830 (see below) and placed a chunk of code in a slightly different > > > position to where it is in 7. Neither issue results in a problem, but > > > this changeset just makes the diff between 6 & 7 smaller. > > > > I looked at the current code in jdk7 and it looks like this: > > > > // eventually compress as well. > > HandshakeStatus hsStatus = > > writer.writeRecord(eor, ea, writeMAC, writeCipher); > > > > /* > > * We only need to check the sequence number state for > > * non-handshaking record. > > * > > * Note that in order to maintain the handshake status > > * properly, we check the sequence number after the last > > * record writing process. As we request renegotiation > > * or close the connection for wrapped sequence number > > * when there is enough sequence number space left to > > * handle a few more records, so the sequence number > > * of the last record cannot be wrapped. > > */ > > if (connectionState < cs_ERROR && !isOutboundDone() && > > (hsStatus == HandshakeStatus.NOT_HANDSHAKING)) { > > if (checkSequenceNumber(writeMAC, eor.contentType())) { > > hsStatus = getHSStatus(null); > > } > > } > > > > /* > > * turn off the flag of the first application record if we really > > * consumed at least byte. > > */ > > if (isFirstAppOutputRecord && ea.deltaApp() > 0) { > > isFirstAppOutputRecord = false; > > } > > > > return hsStatus; > > > > The patch, however, changes the current placement in jdk6: > > > > writer.writeRecord(eor, ea, writeMAC, writeCipher); > > > > /* > > + * turn off the flag of the first application record if we really > > + * consumed at least byte. > > + */ > > + if (isFirstAppOutputRecord && ea.deltaApp() > 0) { > > + isFirstAppOutputRecord = false; > > + } > > + > > + /* > > * We only need to check the sequence number state for > > * non-handshaking record. > > * > > @@ -1279,14 +1287,6 @@ > > } > > } > > > > - /* > > - * turn off the flag of the first application record if we really > > - * consumed at least byte. > > - */ > > - if (isFirstAppOutputRecord && ea.deltaApp() > 0) { > > - isFirstAppOutputRecord = false; > > - } > > - > > return hsStatus; > > > > That looks like the current code in jdk6 matches what's in jdk7u and the > > patch > > makes it diverge. Is that right? > > > > Everything else looks fine. > > > > Thanks, > > Omair > > > > -- > > PGP Key: 66484681 (http://pgp.mit.edu/) > > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 > > > > No. Good catch. > > It seems IcedTea has both, thanks to the original security patch putting > it in one place, then the upstream changeset placing it in the other. > > At least our original was right :) I'll post another webrev later. > -- > Andrew :) > Revised version: http://cr.openjdk.java.net/~andrew/openjdk6/secfix/webrev.02/ -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From omajid at redhat.com Tue Feb 3 22:29:47 2015 From: omajid at redhat.com (Omair Majid) Date: Tue, 3 Feb 2015 17:29:47 -0500 Subject: [PATCH] Post-b34 Fixes In-Reply-To: <912194022.6325864.1423002403969.JavaMail.zimbra@redhat.com> References: <603963234.3658028.1422565147377.JavaMail.zimbra@redhat.com> <1185352924.3661114.1422565869880.JavaMail.zimbra@redhat.com> <20150202222826.GA30277@redhat.com> <1330463553.6099772.1422983517680.JavaMail.zimbra@redhat.com> <912194022.6325864.1423002403969.JavaMail.zimbra@redhat.com> Message-ID: <20150203222947.GC15450@redhat.com> * Andrew Hughes [2015-02-03 17:26]: > Revised version: > > http://cr.openjdk.java.net/~andrew/openjdk6/secfix/webrev.02/ Looks okay to me. Cheers, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From gnu.andrew at redhat.com Wed Feb 4 02:07:02 2015 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 04 Feb 2015 02:07:02 +0000 Subject: hg: jdk6/jdk6/jdk: 6 new changesets Message-ID: <201502040207.t14273IR023609@aojmv0008> Changeset: 7154766da4dc Author: andrew Date: 2015-01-21 20:02 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/7154766da4dc OPENJDK6-51: Sync patch for 4873188 with 7 version Reviewed-by: omajid ! src/share/classes/sun/security/ssl/CipherBox.java Changeset: 042e39055298 Author: wetmore Date: 2015-01-21 20:14 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/042e39055298 7031830: bad_record_mac failure on TLSv1.2 enabled connection with SSLEngine Reviewed-by: xuelei, weijun, asaha ! src/share/classes/sun/security/ssl/CipherBox.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java Changeset: c86af5605caa Author: andrew Date: 2015-01-21 20:27 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/c86af5605caa OPENJDK6-53: strict-aliasing warnings issued on PPC32 Summary: Apply -fno-strict-aliasing on all platforms and use PPC CFLAGS_REQUIRED from 7027910 Reviewed-by: omajid ! make/common/Defs-linux.gmk Changeset: 7123b37fc748 Author: andrew Date: 2015-01-21 20:57 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/7123b37fc748 OPENJDK6-52: Application of 6786276 introduces compatibility issue Summary: Add back ISO-3166 code CS and adjust LocaleTest to account for the extra country. Reviewed-by: omajid ! src/share/classes/java/util/LocaleISOData.java + test/java/util/Locale/Bug6786276.java ! test/java/util/Locale/LocaleTest.java Changeset: 156ced965765 Author: chegar Date: 2008-07-29 09:53 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/156ced965765 6730740: Fix for 6729881 has apparently broken several 64 bit tests: "Bad address" Reviewed-by: alanb, jccollet ! src/solaris/native/java/net/linux_close.c ! src/solaris/native/java/net/net_util_md.c Changeset: c228a234a3f3 Author: andrew Date: 2015-01-29 18:54 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/c228a234a3f3 OPENJDK6-54: 6911104 reintroduces test fragment removed in existing 6964018 backport Summary: Remove duplicate fragment Reviewed-by: omajid ! test/sun/tools/common/CommonSetup.sh From saba.uk2000 at yahoo.com Sat Feb 7 19:16:48 2015 From: saba.uk2000 at yahoo.com (Mostafa Salehi) Date: Sat, 7 Feb 2015 19:16:48 +0000 Subject: No subject Message-ID: <1423336608.37264.YahooMailIosMobile@web171506.mail.ir2.yahoo.com> An HTML attachment was scrubbed... URL: