Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 605430 - dev-java/icedtea-bin fails to run with >=dev-libs/nss-3.28
Summary: dev-java/icedtea-bin fails to run with >=dev-libs/nss-3.28
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Java team
URL:
Whiteboard:
Keywords: InVCS
: 605928 606458 617648 (view as bug list)
Depends on: CVE-2016-5285, CVE-2016-8635 607676
Blocks: 609562
  Show dependency tree
 
Reported: 2017-01-12 01:51 UTC by jorgicio
Modified: 2019-03-31 19:48 UTC (History)
13 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
The screenshot (Pantallazo-2017-01-11 22-45-02.png,842.67 KB, image/png)
2017-01-12 01:51 UTC, jorgicio
Details
The emerge --info (emerge-info.txt,7.81 KB, text/plain)
2017-01-12 01:51 UTC, jorgicio
Details

Note You need to log in before you can comment on or make changes to this bug.
Description jorgicio 2017-01-12 01:51:27 UTC
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.
Comment 1 jorgicio 2017-01-12 01:51:58 UTC
Created attachment 459666 [details]
The emerge --info
Comment 2 James Le Cuirot gentoo-dev 2017-01-12 08:03:09 UTC
The first thing to do is confirm whether this is just a -bin incompatibility or if icedtea itself needs fixing.
Comment 3 Ian Whyman (thev00d00) (RETIRED) gentoo-dev 2017-01-13 12:12:23 UTC
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.
Comment 4 Lars Wendler (Polynomial-C) gentoo-dev 2017-01-16 17:51:02 UTC
*** Bug 605928 has been marked as a duplicate of this bug. ***
Comment 5 jorgicio 2017-01-19 19:24:40 UTC
(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.
Comment 6 MarisN 2017-01-21 07:50:11 UTC
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
Comment 7 Fab 2017-01-21 15:46:58 UTC
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.
Comment 8 James Le Cuirot gentoo-dev 2017-01-21 17:28:55 UTC
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.
Comment 9 Ian Whyman (thev00d00) (RETIRED) gentoo-dev 2017-01-23 22:00:25 UTC
*** Bug 606458 has been marked as a duplicate of this bug. ***
Comment 10 Andrew John Hughes 2017-01-24 22:49:11 UTC
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.
Comment 11 James Le Cuirot gentoo-dev 2017-01-24 23:05:38 UTC
(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.
Comment 12 Denis Kaganovich 2017-01-26 14:05:53 UTC
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
Comment 13 Denis Kaganovich 2017-01-26 14:27:29 UTC
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`
Comment 14 Denis Kaganovich 2017-01-27 09:17:38 UTC
Sorry for flood, it works only short time... ;(
Comment 15 Andrew Aladjev 2017-01-30 10:12:26 UTC
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.
Comment 16 James Le Cuirot gentoo-dev 2017-01-30 10:18:28 UTC
No need to do that, icedtea-bin-3.3.0 is now in the tree. It just needs to be stabilized.
Comment 17 Till Schäfer 2017-01-30 14:33:36 UTC
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
Comment 18 James Le Cuirot gentoo-dev 2017-01-30 14:37:47 UTC
(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.
Comment 19 Till Schäfer 2017-01-30 14:44:57 UTC
emerge history says: I did not :-/
Comment 20 Till Schäfer 2017-01-30 14:55:30 UTC
... and seems to be fixed after upgrading to 3.3.0
Comment 21 jorgicio 2017-01-30 16:43:25 UTC
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.
Comment 22 Ivan Grynko 2017-02-22 17:14:39 UTC
nss-3.29.1 and this nasty bug is back. Tried to rebuild icedtea-3.3.0 with no luck.
Comment 23 jorgicio 2017-02-22 17:16:54 UTC
(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.
Comment 24 James Le Cuirot gentoo-dev 2017-02-22 17:25:02 UTC
(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.
Comment 25 James Le Cuirot gentoo-dev 2017-02-26 23:27:43 UTC
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?
Comment 26 Andrew John Hughes 2017-03-03 04:25:51 UTC
I don't see the problem here. Comment #23 suggests rebuilding fixes the problem.
Comment 27 James Le Cuirot gentoo-dev 2017-03-03 08:04:53 UTC
(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.
Comment 28 Maciej Piechotka 2017-03-03 15:00:43 UTC
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).
Comment 29 James Le Cuirot gentoo-dev 2017-03-03 15:18:59 UTC
(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.
Comment 30 Ian Stakenvicius (RETIRED) gentoo-dev 2017-03-03 15:40:01 UTC
(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.
Comment 31 James Le Cuirot gentoo-dev 2017-03-04 10:10:09 UTC
(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.
Comment 32 James Le Cuirot gentoo-dev 2017-03-04 22:23:36 UTC
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.
Comment 33 James Le Cuirot gentoo-dev 2017-03-04 23:30:08 UTC
(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.
Comment 34 James Le Cuirot gentoo-dev 2017-03-05 11:53:29 UTC
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.
Comment 35 James Le Cuirot gentoo-dev 2017-03-07 22:06:56 UTC
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.
Comment 36 Ladislav Jech 2017-03-17 17:10:06 UTC
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.
Comment 37 Dennis Schridde 2017-04-04 08:04:18 UTC
See-Also: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=3307
Comment 38 MarisN 2017-04-15 19:34:19 UTC
(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
Comment 39 Fab 2017-04-25 16:22:25 UTC
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.
Comment 40 James Le Cuirot gentoo-dev 2017-05-06 16:08:53 UTC
*** Bug 617648 has been marked as a duplicate of this bug. ***
Comment 41 Jan Hudoba 2017-05-11 11:27:15 UTC
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.
Comment 42 James Le Cuirot gentoo-dev 2017-05-11 11:47:27 UTC
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.
Comment 43 Ian Stakenvicius (RETIRED) gentoo-dev 2017-05-11 13:30:13 UTC
(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?
Comment 44 James Le Cuirot gentoo-dev 2017-05-11 14:17:44 UTC
(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.
Comment 45 Ian Stakenvicius (RETIRED) gentoo-dev 2017-05-11 14:26:57 UTC
(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.
Comment 46 James Le Cuirot gentoo-dev 2017-05-11 14:31:16 UTC
(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.
Comment 47 Jan Hudoba 2017-05-12 11:50:41 UTC
tnx much, dev-java/icedtea-bin-3.3.0-r1 works ok for me (http ssl client)
Comment 48 Jory A. Pratt gentoo-dev 2019-03-31 19:48:36 UTC
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.