Re: RFR: 8235710: Remove the legacy elliptic curves [v2]
On Wed, 28 Oct 2020 10:52:27 GMT, Magnus Ihse Bursie wrote: >> throw new IllegalStateException( >> new InvalidAlgorithmParameterException( >> "Curve not supported: Private: " + >> ((privNC != null) ? privNC.toString() : " unknown") + >> ", PublicKey:" + >> ((pubNC != null) ? pubNC.toString() : " unknown"))); > > I opened https://bugs.openjdk.java.net/browse/JDK-8255530 for the remaining > cleanup. I have the change in a workspace, just hadn't created the bug yet.. thanks - PR: https://git.openjdk.java.net/jdk/pull/289
Integrated: 8235710: Remove the legacy elliptic curves
On Mon, 21 Sep 2020 21:10:58 GMT, Anthony Scarpino wrote: > This change removes the native elliptic curves library code; as well as, and > calls to that code, tests, and files > associated with those libraries. The makefiles have been changed to remove > from all source builds of the ec code. The > SunEC system property is removed and java.security configurations changed to > reflect the removed curves. This will > remove the following elliptic curves from SunEC: secp112r1, secp112r2, > secp128r1, secp128r2, secp160k1, secp160r1, > secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, > sect113r2, sect131r1, sect131r2, > sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, > sect239k1, sect283k1, sect283r1, > sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 > c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, > X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 > prime192v2, X9.62 prime192v3, X9.62 > prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 > brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 This pull request has now been integrated. Changeset: 0b83fc01 Author:Anthony Scarpino URL: https://git.openjdk.java.net/jdk/commit/0b83fc01 Stats: 20155 lines in 77 files changed: 28 ins; 20048 del; 79 mod 8235710: Remove the legacy elliptic curves Reviewed-by: xuelei, erikj - PR: https://git.openjdk.java.net/jdk/pull/289
Re: RFR: 8235710: Remove the legacy elliptic curves [v3]
On Thu, 24 Sep 2020 21:37:14 GMT, Weijun Wang wrote: >> jdk.disabled.namedCurves is commented out and I don't think it's good for >> every operation disabled algorithms call to >> check an empty property. The description for the disabledAlgorithm >> properties say you have to use "include", so I >> don't think it is necessary to we keep it active.. > > I just think this is an unnecessary behavior change. After all, the purpose > of `jdk.disabled.namedCurves` is to be > included in other disabledAlgorithms properties. > No strong opinion on this. Please decide yourself. I understand what you are saying. The property only existed because there were so many curves that would have overwhelmed the disabledAlgorithms. I also don't like making this a permanent addition to the disabledAlgorithm properties. It's possible we may remove the property in the future as it's likely unnecessary going forward. - PR: https://git.openjdk.java.net/jdk/pull/289
Re: RFR: 8235710: Remove the legacy elliptic curves [v3]
On Thu, 24 Sep 2020 19:48:45 GMT, Weijun Wang wrote: >> Anthony Scarpino has updated the pull request incrementally with one >> additional commit since the last revision: >> >> change exception for ec keyagreement >> fix supportedcurves in SunEC > > src/java.base/share/conf/security/java.security line 636: > >> 634: # >> 635: jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & usage TLSServer, >> \ >> 636: RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224 > > `jdk.disabled.namedCurves` still exists. If someone decides to add a curve > there, shouldn't it be also disabled here? jdk.disabled.namedCurves is commented out and I don't think it's good for every operation disabled algorithms call to check an empty property. The description for the disabledAlgorithm properties say you have to use "include", so I don't think it is necessary to we keep it active.. - PR: https://git.openjdk.java.net/jdk/pull/289
Re: RFR: 8235710: Remove the legacy elliptic curves [v3]
> This change removes the native elliptic curves library code; as well as, and > calls to that code, tests, and files > associated with those libraries. The makefiles have been changed to remove > from all source builds of the ec code. The > SunEC system property is removed and java.security configurations changed to > reflect the removed curves. This will > remove the following elliptic curves from SunEC: secp112r1, secp112r2, > secp128r1, secp128r2, secp160k1, secp160r1, > secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, > sect113r2, sect131r1, sect131r2, > sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, > sect239k1, sect283k1, sect283r1, > sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 > c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, > X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 > prime192v2, X9.62 prime192v3, X9.62 > prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 > brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: change exception for ec keyagreement fix supportedcurves in SunEC - Changes: - all: https://git.openjdk.java.net/jdk/pull/289/files - new: https://git.openjdk.java.net/jdk/pull/289/files/8a04ce7a..1f9820ab Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=289=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=289=01-02 Stats: 20 lines in 3 files changed: 4 ins; 10 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/289.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/289/head:pull/289 PR: https://git.openjdk.java.net/jdk/pull/289
Re: RFR: 8235710: Remove the legacy elliptic curves [v2]
On Wed, 23 Sep 2020 17:07:21 GMT, Valerie Peng wrote: >> Anthony Scarpino has updated the pull request incrementally with one >> additional commit since the last revision: >> >> remove JDKOPT_DETECT_INTREE_EC from configure.ac > > src/jdk.crypto.ec/share/classes/sun/security/ec/SunEC.java line 219: > >> 217: >> 218: Collection supportedCurves; >> 219: supportedCurves = CurveDB.getSupportedCurves(); > > Shouldn't the supportedCurves be the hardcoded 3 curves? Ah yes. Thanks for seeing that. - PR: https://git.openjdk.java.net/jdk/pull/289
Re: RFR: 8235710: Remove the legacy elliptic curves [v2]
On Tue, 22 Sep 2020 13:53:12 GMT, Sean Mullan wrote: >> Anthony Scarpino has updated the pull request incrementally with one >> additional commit since the last revision: >> >> remove JDKOPT_DETECT_INTREE_EC from configure.ac > > src/jdk.crypto.ec/share/classes/sun/security/ec/ECDHKeyAgreement.java line > 180: > >> 178: ((privNC != null) ? privNC.toString() : " >> unknown") + >> 179: ", PublicKey:" + >> 180: ((pubNC != null) ? pubNC.toString() : " >> unknown"))); > > Spacing issues: "PublicKey:" should be "PublicKey: " and " unknown" should be > "unknown". After considering the keys closer, I don't need to specify the key anymore. PrivateKey and PublicKey were removed - PR: https://git.openjdk.java.net/jdk/pull/289
Re: RFR: 8235710: Remove the legacy elliptic curves [v2]
> This change removes the native elliptic curves library code; as well as, and > calls to that code, tests, and files > associated with those libraries. The makefiles have been changed to remove > from all source builds of the ec code. The > SunEC system property is removed and java.security configurations changed to > reflect the removed curves. This will > remove the following elliptic curves from SunEC: secp112r1, secp112r2, > secp128r1, secp128r2, secp160k1, secp160r1, > secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, > sect113r2, sect131r1, sect131r2, > sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, > sect239k1, sect283k1, sect283r1, > sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 > c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, > X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 > prime192v2, X9.62 prime192v3, X9.62 > prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 > brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: remove JDKOPT_DETECT_INTREE_EC from configure.ac - Changes: - all: https://git.openjdk.java.net/jdk/pull/289/files - new: https://git.openjdk.java.net/jdk/pull/289/files/47eee3f4..8a04ce7a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=289=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=289=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/289.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/289/head:pull/289 PR: https://git.openjdk.java.net/jdk/pull/289
Re: RFR: 8235710: Remove the legacy elliptic curves [v2]
On Mon, 21 Sep 2020 23:50:07 GMT, Erik Joelsson wrote: >> Anthony Scarpino has updated the pull request incrementally with one >> additional commit since the last revision: >> >> remove JDKOPT_DETECT_INTREE_EC from configure.ac > > make/autoconf/jdk-options.m4 line 234: > >> 232: # Enable or disable the elliptic curve crypto implementation >> 233: # >> 234: AC_DEFUN_ONCE([JDKOPT_DETECT_INTREE_EC], > > There should be a call to this macro from either configure.ac or this file > that also needs to be removed. found it in configure.ac and removed - PR: https://git.openjdk.java.net/jdk/pull/289
RFR: 8235710: Remove the legacy elliptic curves
This change removes the native elliptic curves library code; as well as, and calls to that code, tests, and files associated with those libraries. The makefiles have been changed to remove from all source builds of the ec code. The SunEC system property is removed and java.security configurations changed to reflect the removed curves. This will remove the following elliptic curves from SunEC: secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 - Commit messages: - 8235710: Remove the legacy elliptic curves Changes: https://git.openjdk.java.net/jdk/pull/289/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=289=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8235710 Stats: 20143 lines in 75 files changed: 25 ins; 20038 del; 80 mod Patch: https://git.openjdk.java.net/jdk/pull/289.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/289/head:pull/289 PR: https://git.openjdk.java.net/jdk/pull/289
Re: RFR: 8210647: libsaproc is being compiled without optimization.
I encountered this too when I build with ‘make’; however if I build through JIB the error didn’t occur. Tony > On Sep 18, 2018, at 2:08 AM, Thomas Stüfe wrote: > > Hi Severin, > > I get reproducable build errors with your fix on my machine (Ubuntu 16.4). > > When I build release (no special build options), I get: > > /shared/projects/openjdk/jdk-jdk/source/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c: > In function ‘read_exec_segments’: > /shared/projects/openjdk/jdk-jdk/source/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c:798:7: > error: ignoring return value of ‘pread’, declared with attribute > warn_unused_result [-Werror=unused-result] > pread(ph->core->exec_fd, interp_name, exec_php->p_filesz, > exec_php->p_offset); > ^ > > When I remove your change (reset opt to NONE) error goes away. I have > no idea why optimization influences warning level though. Any ideas? > > (Of course, one could just fix the warning, but I wonder if I am the > only one with this problem) > > Best Regards, Thomas > > > > On Mon, Sep 17, 2018 at 6:25 AM, Sharath Ballal > wrote: >> Hi Severin, >> >> Looks good to me. >> >> >> Thanks, >> Sharath (not a Reviewer) >> >> >> -Original Message- >> From: Severin Gehwolf [mailto:sgehw...@redhat.com] >> Sent: Friday, September 14, 2018 7:04 PM >> To: build-dev; serviceability-dev >> Subject: RFR: 8210647: libsaproc is being compiled without optimization. >> >> Hi, >> >> Could I please get a review of this one-liner fix. It changes optimization >> of libsaproc from -O0 to -O3 (as per Magnus' suggestion). >> I've run servicability tests and haven't seen any new failures. >> Thoughts? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210647 >> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210647/webrev.01/ >> >> Thanks, >> Severin >> >>
Re: [9] RFR 8079898: Resolve disabled warnings for libj2ucrypto
On 12/07/2016 03:21 PM, Valerie Peng wrote: Anyone can help reviewing this? The fix is straight forward, just renamed the DEBUG to J2UC_DEBUG to address the E_MACRO_REDEFINED warning. In addition, I also updated the nativeCrypto.h to remove the workaround for a Solaris12-specific issue which has now been fixed. Bug: https://bugs.openjdk.java.net/browse/JDK-8079898 Webrev: http://cr.openjdk.java.net/~valeriep/8079898/webrev.00/ JPRT result looks fine. Thanks, Valerie looks fine to me. Tony
RFR 8074838: Resolve disabled warnings for libj2pkcs11
Hi, Can I get a review of this change to remove the warning suppression and fix the minor compiler issues that it was hiding in the pkcs11 wrapper library. http://cr.openjdk.java.net/~ascarpino/8074838/webrev/ thanks Tony
Re: RFR 8140422: Add mechanism to allow non default root CAs to be not subject to algorithm restrictions
I believe I got everyone's comments. I've updated the webrev. http://cr.openjdk.java.net/~ascarpino/8140422/webrev.02/ Thanks Tony On 02/29/2016 08:55 AM, Anthony Scarpino wrote: Currently CertPath algorithm restrictions allow or deny all certificates. This change adds the ability to reject certificate chains that contain a restricted algorithm and the chain terminates at a root CA; therefore, allowing a self-signed or chain that does not terminate at a root CA. https://bugs.openjdk.java.net/browse/JDK-8140422 Thanks Tony
Re: RFR 8140422: Add mechanism to allow non default root CAs to be not subject to algorithm restrictions
Ok.. thanks.. I'll make those changes.. Tony On 03/12/2016 07:37 AM, Erik Joelsson wrote: Hello Anthony, I realize you followed the patterns already in the file and we apparently haven't updated that file to follow latest standards. I would like you to change the following: $(ECHO) foo should be $(call LogInfo, foo) and $(MKDIR) -p foo should be $(call MakeDir, foo) I also don't know what the "|| exit 1" is good for. I think it should just be removed. Finally for indentation, in recipes we recommend: some command with arguments \ <4 spaces>some more arguments Otherwise it looks good. /Erik On 2016-03-11 22:43, Anthony Scarpino wrote: I updated the webrev and added the build-dev list as there are two makefile changes. http://cr.openjdk.java.net/~ascarpino/8140422/webrev.01/ thanks Tony On 02/29/2016 08:55 AM, Anthony Scarpino wrote: I need a code review of this change: Currently CertPath algorithm restrictions allow or deny all certificates. This change adds the ability to reject certificate chains that contain a restricted algorithm and the chain terminates at a root CA; therefore, allowing a self-signed or chain that does not terminate at a root CA. https://bugs.openjdk.java.net/browse/JDK-8140422
Re: RFR 8140422: Add mechanism to allow non default root CAs to be not subject to algorithm restrictions
ok.. thanks Tony On 03/18/2016 10:27 AM, Erik Joelsson wrote: Much better, and thank you for fixing the existing mkdir/echo lines too. Just one nit, for this continuation: $(TOOL_CACERTSHASHER) -i $(GENDATA_CACERTSHASHER_IN) \ -o $(GENDATA_CACERTSHASHER) please use tab+4spaces for the second line. No need to resend webrev for that. See [1] for our build system code conventions. [1] http://openjdk.java.net/groups/build/doc/code-conventions.html /Erik On 2016-03-18 18:09, Anthony Scarpino wrote: I believe I got everyone's comments. I've updated the webrev. http://cr.openjdk.java.net/~ascarpino/8140422/webrev.02/ Thanks Tony On 02/29/2016 08:55 AM, Anthony Scarpino wrote: Currently CertPath algorithm restrictions allow or deny all certificates. This change adds the ability to reject certificate chains that contain a restricted algorithm and the chain terminates at a root CA; therefore, allowing a self-signed or chain that does not terminate at a root CA. https://bugs.openjdk.java.net/browse/JDK-8140422 Thanks Tony
Re: RFR 8140422: Add mechanism to allow non default root CAs to be not subject to algorithm restrictions
I updated the webrev and added the build-dev list as there are two makefile changes. http://cr.openjdk.java.net/~ascarpino/8140422/webrev.01/ thanks Tony On 02/29/2016 08:55 AM, Anthony Scarpino wrote: I need a code review of this change: Currently CertPath algorithm restrictions allow or deny all certificates. This change adds the ability to reject certificate chains that contain a restricted algorithm and the chain terminates at a root CA; therefore, allowing a self-signed or chain that does not terminate at a root CA. https://bugs.openjdk.java.net/browse/JDK-8140422
RFR 8133151: Preferred provider configuration for JCE
Hi all, I'm need a review of the last developement piece to JEP 246, the configuration changes. I've copied the build-dev in case there were any comments on the minor changes in the make directory related to the java.security file. http://cr.openjdk.java.net/~ascarpino/8133151/webrev/ thanks Tony
Re: build failure in perfMemory_solaris.cpp?
I created one:
https://bugs.openjdk.java.net/browse/JDK-8071501
Tony
On 01/23/2015 10:07 AM, Bradford Wetmore wrote:
Is there a bug id yet? I haven't seen one showing up in a quick search
for dd_fd or perfMemory_solaris.cpp.
For the record, I'm on what I think is the required platform/compilers:
% uname -a
SunOS sca00bkv 5.11 11.1 sun4v sparc sun4v
% more /etc/release
Oracle Solaris 11.1 SPARC
Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights
reserved.
Assembled 06 November 2013
% grep BUILD_CC out.txt
BUILD_CC:= /java/devtools/sparc/SUNWspro/SS12u3/bin/cc
Brad
On 1/23/2015 8:32 AM, Volker Simonis wrote:
Hi,
we can see the same in our nightly OpenJDK 8/9 builds
(http://cr.openjdk.java.net/~simonis/ppc-aix-port/) and would be
interested in a solution as well.
Thanks,
Volker
On Fri, Jan 23, 2015 at 5:19 AM, David Holmes
david.hol...@oracle.com wrote:
Hi Anthony,
On 23/01/2015 10:33 AM, Anthony Scarpino wrote:
Hi,
I just pulled the jdk9/dev gate today and hit a build failure on SPARC
Solaris 11.1 when compiling perfMemory_solaris.cpp in hotspot. I'm
using SS12u3 compilers. Anyone else see a similar error or know what
might be going wrong?
...hotspot/src/os/solaris/vm/perfMemory_solaris.cpp, line 337: Error:
dd_fd is not a member of DIR.
...hotspot/src/os/solaris/vm/perfMemory_solaris.cpp, line 369: Error:
dd_fd is not a member of DIR.
gmake[8]: *** [perfMemory_solaris.o] Error 2
This code was brought in via the recent CPU integration of bug
8050807. (Hi
Jerry! - cc'd)
It looks like Solaris has two potential definitions of DIR:
#if defined(__USE_LEGACY_PROTOTYPES__)
/* traditional SVR4 definition */
typedef struct {
int dd_fd; /* file descriptor */
int dd_loc; /* offset in block */
int dd_size;/* amount of valid data */
char*dd_buf;/* directory block */
} DIR; /* stream data from opendir() */
#else
/* default definition (POSIX conformant) */
typedef struct {
int d_fd; /* file descriptor */
int d_loc; /* offset in block */
int d_size; /* amount of valid data */
char*d_buf; /* directory block */
} DIR; /* stream data from opendir() */
#endif /* __USE_LEGACY_PROTOTYPES__ */
I can't see what controls __USE_LEGACY_PROTOTYPES__ but presumably
either
something in Solaris 11.1, or something in SS12u3 is causing this
difference.
David
thanks
Tony
build failure in perfMemory_solaris.cpp?
Hi, I just pulled the jdk9/dev gate today and hit a build failure on SPARC Solaris 11.1 when compiling perfMemory_solaris.cpp in hotspot. I'm using SS12u3 compilers. Anyone else see a similar error or know what might be going wrong? ...hotspot/src/os/solaris/vm/perfMemory_solaris.cpp, line 337: Error: dd_fd is not a member of DIR. ...hotspot/src/os/solaris/vm/perfMemory_solaris.cpp, line 369: Error: dd_fd is not a member of DIR. gmake[8]: *** [perfMemory_solaris.o] Error 2 thanks Tony
Code review request: 8031372 JDK 9 Specification-Version in jar files is still 1.8
Hi, I have a change that needs a review to the manifest.mf file for the Specification-Version from 1.8 to 1.9. This is needed as part of the build signing of crypto signed jar files. Being from the security side and not the build side of the openjdk world, if there is a better way to address this, please let me know. http://cr.openjdk.java.net/~ascarpino/8031372/webrev.00/ thanks Tony
