Created attachment 459664 [details] The screenshot Tried with nss 3.28 and icedtea-bin-3.2.0 and this happens. I'll attach a screenshot to show. This does not happen with nss 3.27 and lower.
Created attachment 459666 [details] The emerge --info
The first thing to do is confirm whether this is just a -bin incompatibility or if icedtea itself needs fixing.
I've compiled icedtea 3.2.0 against nss 3.28.1 and it works as expected whilst -bin fails. So I guess this is a -bin issue.
*** Bug 605928 has been marked as a duplicate of this bug. ***
(In reply to Ian Whyman (thev00d00) from comment #3) > I've compiled icedtea 3.2.0 against nss 3.28.1 and it works as expected > whilst -bin fails. > > So I guess this is a -bin issue. Indeed it's a -bin issue. Other packages work fine with nss 3.28, i.e., Firefox.
The reporter has only provided a screenshot of failure, thus it is hard to asses if I have the same issue, although it seems so. Downgrading to dev-libs/nss-3.27.2 fixes crashes. Tested with dev-java/icedtea-bin-3.2.0. Part of crash log for googlers: # SIGSEGV (0xb) at pc=0x0000003f8ea8e930, pid=9859, tid=0x00007fbbd0e2e700 # # JRE version: OpenJDK Runtime Environment (8.0_111-b14) (build 1.8.0_111-b14) # Java VM: OpenJDK 64-Bit Server VM (25.111-b14 mixed mode linux-amd64 compressed oops) # Derivative: IcedTea 3.2.0 # Distribution: Gentoo Base System release 2.2, package Gentoo icedtea-3.2.0 # Problematic frame: # C [libc.so.6+0x8e930] ------ Stack: [0x00007fbbd0d2e000,0x00007fbbd0e2f000], sp=0x00007fbbd0e2c3c8, free space=1016k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libc.so.6+0x8e930] C [libsunec.so+0x1110] C [libsunec.so+0x127a] Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair+0x12a j sun.security.ec.ECKeyPairGenerator.generateECKeyPair(I[B[B)[Ljava/lang/Object;+0 j sun.security.ec.ECKeyPairGenerator.generateKeyPair()Ljava/security/KeyPair;+56 j java.security.KeyPairGenerator$Delegate.generateKeyPair()Ljava/security/KeyPair;+23 j sun.security.ssl.ECDHCrypt.<init>(Ljava/security/spec/ECParameterSpec;Ljava/security/SecureRandom;)V+17 j sun.security.ssl.ClientHandshaker.serverKeyExchange(Lsun/security/ssl/HandshakeMessage$ECDH_ServerKeyExchange;)V+44 j sun.security.ssl.ClientHandshaker.processMessage(BI)V+582 j sun.security.ssl.Handshaker.processLoop()V+96
Same problem here with dev-java/icedtea-bin-7.2.6.8 and dev-libs/nss-3.28.1. Same exceptions as attached screenshot : > Downloading: https://s3.amazonaws.com/Minecraft.Download/launcher/launcher.pack.lzma > Exception: javax.net.ssl.SSLException: java.security.ProviderException: java.lang.NegativeArraySizeException With dev-java/icedtea-bin-3.2.0 I'm getting the same SIGSEGV as comment #6. Switching from dev-java/icedtea-bin-7.2.6.8 to dev-java/icedtea-7.2.6.8::gentoo fixed the problem.
No need for further comments, I get the picture. The next icedtea release will be out before long due to vulnerabilities so I'll wait till then. nss 3.28 has been stabilised on all the relevant arches so I'll build against that and make it a requirement. The bad news is the ppc64 build host has died but hopefully it'll be back soon.
*** Bug 606458 has been marked as a duplicate of this bug. ***
The SunEC provider in IcedTea links against the system NSS installation in a way which uses both dynamic linking, but also has to statically link some code which isn't available by dynamic linking. As a result, an update to NSS may require a rebuild of IcedTea. If there's a way to enforce this in the ebuild, we should add it. I would recommend using dev-java/icedtea where possible. icedtea-bin is really only meant for bootstrapping and leads to problems like this. In the case of 3.28, there may be more changes required in the OpenJDK code. See the Fedora bug https://bugzilla.redhat.com/show_bug.cgi?id=1415137 for details.
(In reply to Andrew John Hughes from comment #10) > The SunEC provider in IcedTea links against the system NSS installation in a > way which uses both dynamic linking, but also has to statically link some > code which isn't available by dynamic linking. As a result, an update to NSS > may require a rebuild of IcedTea. If there's a way to enforce this in the > ebuild, we should add it. You can trigger rebuilds against subslot changes but there are no subslots for dev-libs/nss and they wouldn't add any for such a use case. > I would recommend using dev-java/icedtea where possible. icedtea-bin is > really only meant for bootstrapping and leads to problems like this. It's not been too bad but yeah, it can happen. It's not ideal but if this is likely to happen again then I'd link NSS entirely statically. That doesn't appear to be an option though.
I got UniFi wi-fi controller broken on ssl (only) with icedtea-bin-3.2.0 & nss-3.28.1. Looking more, I found icedtea-bin-3.2.0 dropped useflag "nss", which just uncomment one line in jre/lib/security/java.security in icedtea-bin-7.2.6.8. Uncommenting same line in icedtea-bin-3.2.0 make UniFi working again. PS security.provider.10=sun.security.pkcs11.SunPKCS11 ${java.home}/lib/security/nss.cfg
PPS My injection into dev-java/icedtea-bin prepare: [[ " $USE " != *' nss '* ]] && sed -i -e 's:^#\(security\.provider\.10=sun\.security\.pkcs11\.SunPKCS11\):\1:' `find "${WORKDIR}" -name java.security`
Sorry for flood, it works only short time... ;(
Hello. The easiest way to fix this issue is to downgrade dev-libs/nss to 3.27.2. I've just cloned "git://anongit.gentoo.org/repo/gentoo.git" and checkout commit id "177c7b1881ecbfb5189f7619f28d26fe086eb6f5". This is the last commit where 3.27.2 exists. I've emerged this ebuild with "cacert" use and this bug was fixed.
No need to do that, icedtea-bin-3.3.0 is now in the tree. It just needs to be stabilized.
I see the same error for the non binary version of icedtea (dev-java/icedtea-3.2.0) using eclipse neon with egit push/pull: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=3305
(In reply to Till Schäfer from comment #17) > I see the same error for the non binary version of icedtea > (dev-java/icedtea-3.2.0) using eclipse neon with egit push/pull: > > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=3305 You haven't said whether you've tried rebuilding icedtea since upgrading nss.
emerge history says: I did not :-/
... and seems to be fixed after upgrading to 3.3.0
Well, I had to upgrade it to the 3.3.0 and using the icedtea package (not the -bin one), and 3.2.0 and 3.3.0 work fine. I hope the same with the -bin 3.3.0.
nss-3.29.1 and this nasty bug is back. Tried to rebuild icedtea-3.3.0 with no luck.
(In reply to Ivan Ivanich from comment #22) > nss-3.29.1 and this nasty bug is back. Tried to rebuild icedtea-3.3.0 with > no luck. That's weird: I'm using the source-based Icedtea, the bug went back, rebuilt Icedtea and all works fine.
(In reply to jorgicio from comment #23) > (In reply to Ivan Ivanich from comment #22) > > nss-3.29.1 and this nasty bug is back. Tried to rebuild icedtea-3.3.0 with > > no luck. > > That's weird: I'm using the source-based Icedtea, the bug went back, rebuilt > Icedtea and all works fine. Ech, either way this is crappy news. There's also no obvious solution this time as it doesn't look like a security bump so 3.29 will not go stable immediately. I'll look at this more closely to see what our options are.
I've looked into this now. It's confusing because NSS is used in two ways, for the SunEC provider and for the SunPKCS11 provider. The latter is usually disabled but Comment #12 showed that the issue can be worked around by enabling it. SunPKCS11 has a lower priority but I guess it still falls back to this when SunEC fails. icedtea:7 had an nss flag to flip this switch in java.security but it was removed for icedtea:8. gnu_andrew, could you remind me why this is? I have some vague recollections but they're probably wrong. :) I think that leaves us with 3 options for icedtea-bin: 1. Enable SunPKCS11 all the time to act as a fallback when SunEC breaks. 2. Disable SunEC. I think this may break some applications like I2P. 3. Link NSS entirely statically. I tried to find out more about how it links some parts statically but couldn't find the relevant code. gnu_andrew, could you please point me in the right direction?
I don't see the problem here. Comment #23 suggests rebuilding fixes the problem.
(In reply to Andrew John Hughes from comment #26) > I don't see the problem here. Comment #23 suggests rebuilding fixes the > problem. Right but I need a solution for -bin that isn't going to keep breaking every time there's an nss bump. I will sometimes need to support more than one version at a time because of stable/unstable differences. I know you don't like -bin but it's not going away so I'd at least like to pick the option that you think is best.
I run into similar problem (no crash - just exceptions) again with icedtea when the rebuild fixed the problem so it would be nice if rebuilds were automatic (PS. if -bin is meant to be for bootstrapping only shouldn't it be behind a bootstrap flag? Most language compilers don't have -bin for bootstrapping and just use this flag to use pre-compiled binary instead of system one).
(In reply to Maciej Piechotka from comment #28) > I run into similar problem (no crash - just exceptions) again with icedtea > when the rebuild fixed the problem so it would be nice if rebuilds were > automatic That isn't possible unless subslots are added for every nss minor version and the maintainer won't want to do that. It only happens because it is partially statically linked, which isn't a normal thing to do. > (PS. if -bin is meant to be for bootstrapping only shouldn't it be > behind a bootstrap flag? Most language compilers don't have -bin for > bootstrapping and just use this flag to use pre-compiled binary instead of > system one). I don't intend for it to be just for bootstrapping.
(In reply to James Le Cuirot from comment #29) > (In reply to Maciej Piechotka from comment #28) > > I run into similar problem (no crash - just exceptions) again with icedtea > > when the rebuild fixed the problem so it would be nice if rebuilds were > > automatic > > That isn't possible unless subslots are added for every nss minor version > and the maintainer won't want to do that. It only happens because it is > partially statically linked, which isn't a normal thing to do. So if NSS is breaking ABI in general, then I am willing to entertain a subslot. However, as I believe the icedtea-bin issue is more nuanced than that (ie its not about the standard symbols but something to do with how it both statically and dynamically links to nss??) I don't think subslots and slot operators are the right way to handle this one. What I recommend here to at least help with the issue is to peg the NSS dep to a particular version. At least then, either NSS won't upgrade icedtea-bin will have to upgrade (usually the former iirc). It's not as pretty for the end user but we don't have a whole lot of choice unless we just want the breakage to happen. It'll also let you manage the stable-vs-~arch situation a bit better.
(In reply to Ian Stakenvicius from comment #30) > So if NSS is breaking ABI in general, then I am willing to entertain a > subslot. However, as I believe the icedtea-bin issue is more nuanced than > that (ie its not about the standard symbols but something to do with how it > both statically and dynamically links to nss??) I don't think subslots and > slot operators are the right way to handle this one. I wish I could tell you more but I couldn't find the relevant code. > What I recommend here to at least help with the issue is to peg the NSS dep > to a particular version. At least then, either NSS won't upgrade > icedtea-bin will have to upgrade (usually the former iirc). It's not as > pretty for the end user but we don't have a whole lot of choice unless we > just want the breakage to happen. It'll also let you manage the > stable-vs-~arch situation a bit better. I think just statically linking it would be the lesser evil. It's my preferred choice and I'll give it a go later. That way it won't hold NSS back for other applications and I won't have to continually keep on top of the updates. Building icedtea-bin on 4 arches (potentially 6 soon) is a little time-consuming. It is at least updated frequently enough that the NSS version won't fall far behind.
I understand this a bit better now after having found the story behind it. https://bugzilla.redhat.com/show_bug.cgi?id=1075702 As I thought, the SunPKCS11 NSS provider has memory leaks so let's not use that. I initially tried passing --disable-system-nss to OpenJDK, thinking it would use its own in-tree code but it didn't build libsunec.so at all. I now see that IcedTea deliberately deletes the in-tree code. I think I trust our own NSS package more than the in-tree code so I'll go ahead with statically linking that if I can.
(In reply to James Le Cuirot from comment #32) > ...I'll go ahead with statically linking that if I can. I didn't realise how horrific the NSS build system is. It builds static libraries anyway and I could use a hook to install them but I also have to deal with NSPR and I didn't like where this was going so I changed tack and tried OpenJDK's in-tree code instead. That just required a small patch against IcedTea and it built successfully. I'll now build across the other arches. It's effectively a bundled library but at least I get to build it from source and I'm the only one who suffers the extra build time.
I've fixed this for 3.3.0 in -r1. Please try it and let me know if it works for you. I'll deal with 7.2 when I bump it soon.
7.2.6.9 also deals with this and will be stabilized very soon. I noticed that 7.2.6.8 is broken against 3.29 but works against 3.29.1. This made me wonder whether they'd broken it and then put it back the way it was or otherwise fixed it. Further investigation revealed this to be the case so I guess we could have just left it the way it was but there's no guarantee it won't break again in future. Upstream has been advised to use the API properly so I'll review this decision if and when that happens.
Facing same issue with Nexus maven repository app. Following the discussion here I upgraded nss and after I recompiled icedtea to versions: dev-java/icedtea-7.2.6.9 dev-libs/nss-3.29.3 Now the error disappeared.
See-Also: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=3307
(In reply to James Le Cuirot from comment #34) > I've fixed this for 3.3.0 in -r1. Please try it and let me know if it works > for you. I'll deal with 7.2 when I bump it soon. -r1 fixed JOSM for me == good :) Thanks! dev-java/icedtea-bin-3.3.0-r1 dev-libs/nss-3.29.3
icedtea-bin-3.3.0 installed. After dev-libs/nss-3.29.5 was stabilized, when running minecraft launcher I got some : > Exception: javax.net.ssl.SSLException: java.security.ProviderException: java.io.IOException: Only uncompressed point format supported Upgrading to icedtea-bin-3.3.0-r1 fixed it.
*** Bug 617648 has been marked as a duplicate of this bug. ***
icedtea-bin package should have strict dependence on dev-libs/nss version. dev-java/icedtea-bin-3.3.0, =dev-libs/nss-3.28.1 dev-java/icedtea-bin-3.3.0-r1, =dev-libs/nss-3.29.5 probably version that icedtea-bin binary package was compiled with. otherwise icedtea-bin is not working correctly, as described in this bug, combination of dev-java/icedtea-bin-3.3.0 + dev-libs/nss-3.29.5 gives exception: Exception: javax.net.ssl.SSLException: java.security.ProviderException: java.io.IOException: Only uncompressed point format supported and in our applications http ssl connections are not working.
I had hoped a new icedtea would hit soon but evidently not soon enough so I've marked 3.3.0-r1 stable. It doesn't need the nss dependency adjusting because it doesn't use an external nss at all. It's bundled now.
(In reply to James Le Cuirot from comment #42) > I had hoped a new icedtea would hit soon but evidently not soon enough so > I've marked 3.3.0-r1 stable. It doesn't need the nss dependency adjusting > because it doesn't use an external nss at all. It's bundled now. Reportedly, as of nss-3.29.5 and nss-3.31, they fixed the ABI issue that was causing icedtea-bin etc. to break, so -in theory- new nss may work fine with icedtea-bin-3.2.0?
(In reply to Ian Stakenvicius from comment #43) > Reportedly, as of nss-3.29.5 and nss-3.31, they fixed the ABI issue that was > causing icedtea-bin etc. to break, so -in theory- new nss may work fine with > icedtea-bin-3.2.0? I take it you mean 3.3.0. Yes, if you read back, you'll see I realised afterwards that this wasn't a permanent breakage. However, there is still talk of getting icedtea to interface with nss in a safer way so I'll continue to bundle it for now while the dust settles and see whether they improve the situation.
(In reply to James Le Cuirot from comment #44) > (In reply to Ian Stakenvicius from comment #43) > > Reportedly, as of nss-3.29.5 and nss-3.31, they fixed the ABI issue that was > > causing icedtea-bin etc. to break, so -in theory- new nss may work fine with > > icedtea-bin-3.2.0? > > I take it you mean 3.3.0. Yes, if you read back, you'll see I realised > afterwards that this wasn't a permanent breakage. However, there is still > talk of getting icedtea to interface with nss in a safer way so I'll > continue to bundle it for now while the dust settles and see whether they > improve the situation. No, I meant 3.2.0, the one that initially broke with nss-3.28. That is, I believe nss-3.29.5 is ABI compatible with nss-3.27. Again, I can't confirm this per se as it's just based on what I read in the NSS commit logs.
(In reply to Ian Stakenvicius from comment #45) > No, I meant 3.2.0, the one that initially broke with nss-3.28. That is, I > believe nss-3.29.5 is ABI compatible with nss-3.27. Again, I can't confirm > this per se as it's just based on what I read in the NSS commit logs. Sorry yes, that is true of 3.2.0 (and not 3.3.0) but 3.2.0 was vulnerable and removed.
tnx much, dev-java/icedtea-bin-3.3.0-r1 works ok for me (http ssl client)
as icedtea-bin uses a bundled nss there is no need to keep this open. It has already been addressed per comments in 3.3.0-r1 which already went stable.
