Bug 732628 – dev-java/icedtea{,-bin}: Multiple vulnerabilities

• Status: IN_PROGRESS
• Product: Gentoo Security

[Description Sam James 2020-07-14 20:51:00 UTC]

Waiting for a release here.

[Comment 1 Georgy Yakovlev 2020-10-28 19:04:57 UTC]

https://icedtea.classpath.org/hg/icedtea8/rev/1954b437af5a

finally tagged upstream. will do a bump soon but binary package will not get stable keywords, maybe except x86 and ppc64be, but we'll see.

[Comment 2 Larry the Git Cow 2020-10-28 19:50:23 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d6cf785c9034e34abb4de413651bd45280dfb683

commit d6cf785c9034e34abb4de413651bd45280dfb683
Author:     Georgy Yakovlev <[e-mail]>
AuthorDate: 2020-10-28 19:32:45 +0000
Commit:     Georgy Yakovlev <[e-mail]>
CommitDate: 2020-10-28 19:50:05 +0000

    dev-java/icedtea: bump to 3.17.0
    
    Bug: https://bugs.gentoo.org/732628
    Package-Manager: Portage-3.0.8, Repoman-3.0.2
    Signed-off-by: Georgy Yakovlev <[e-mail]>

 dev-java/icedtea/Manifest              |  11 +
 dev-java/icedtea/icedtea-3.17.0.ebuild | 378 +++++++++++++++++++++++++++++++++
 2 files changed, 389 insertions(+)

[Comment 3 Andrew John Hughes 2020-10-29 01:39:59 UTC]

(In reply to Georgy Yakovlev from comment #1)
> https://icedtea.classpath.org/hg/icedtea8/rev/1954b437af5a
> 
> finally tagged upstream. will do a bump soon but binary package will not get
> stable keywords, maybe except x86 and ppc64be, but we'll see.

Why would this not get stable keywords? Do you plan to leave people with an unsecure version?

[Comment 4 Georgy Yakovlev 2020-10-29 01:50:53 UTC]

(In reply to Andrew John Hughes from comment #3)
> (In reply to Georgy Yakovlev from comment #1)
> > https://icedtea.classpath.org/hg/icedtea8/rev/1954b437af5a
> > 
> > finally tagged upstream. will do a bump soon but binary package will not get
> > stable keywords, maybe except x86 and ppc64be, but we'll see.
> 
> Why would this not get stable keywords? Do you plan to leave people with an
> unsecure version?

icedtea (the built-from source ebuild) never had stable keywords. it was always marked as ~/unstable in gentoo.

icedtea-bin (which I build myself on own and gentoo HW from that ebuild and distribute to users) had stable keywords all the time.

but since icedtea was untouched for half a year, skipped release, was affected by couple dozen of CVEs, and I could not reach you, after chatting with security team we decided to make openjdk:8  primary JDK, as it gets released right after vulnerabilities disclosed and we usually have zero day or 1 day bumps. so does adoptopenjdk (we use their binaries for bootstrap).


There's nothing personal, just trying to take security seriously and do best for our users.

Also have some companies that use gentoo in production and they would prefer immediate bumps. So do some users.

[Comment 5 Georgy Yakovlev 2020-10-29 02:00:14 UTC]

forgot to answer the question. Users already got an update.

users who have no preference which JDK to use will be upgraded to vanilla  openjdk-8 by package manager.

users who explicitly installed icedtea (source) already have an update.

users who explicitly installed icedtea-bin will have to either install openjdk-8 or explicitly accept new version of icedtea-bin soon as I remove vulnerable package and build new one.

so most are already updated, rest will be up-to-date very soon.

[Comment 6 Georgy Yakovlev 2020-10-29 02:11:00 UTC]

for @security

removed icedtea-3.16.0 from the tree
we already have 3.17.0

icedtea-bin-3.17.0 binary packages in progress, building.

[Comment 7 Andrew John Hughes 2020-10-29 02:52:38 UTC]

(In reply to Georgy Yakovlev from comment #4)
> (In reply to Andrew John Hughes from comment #3)
> > (In reply to Georgy Yakovlev from comment #1)
> > > https://icedtea.classpath.org/hg/icedtea8/rev/1954b437af5a
> > > 
> > > finally tagged upstream. will do a bump soon but binary package will not get
> > > stable keywords, maybe except x86 and ppc64be, but we'll see.
> > 
> > Why would this not get stable keywords? Do you plan to leave people with an
> > unsecure version?
> 
> icedtea (the built-from source ebuild) never had stable keywords. it was
> always marked as ~/unstable in gentoo.
> 
> icedtea-bin (which I build myself on own and gentoo HW from that ebuild and
> distribute to users) had stable keywords all the time.
> 
> but since icedtea was untouched for half a year, skipped release, was
> affected by couple dozen of CVEs, and I could not reach you, after chatting
> with security team we decided to make openjdk:8  primary JDK, as it gets
> released right after vulnerabilities disclosed and we usually have zero day
> or 1 day bumps. so does adoptopenjdk (we use their binaries for bootstrap).
> 
> 
> There's nothing personal, just trying to take security seriously and do best
> for our users.
> 
> Also have some companies that use gentoo in production and they would prefer
> immediate bumps. So do some users.

Yeah, it's me doing the upstream OpenJDK releases as well. And the Fedora and RHEL updates. That and IcedTea is a lot, so it's sadly quite easy for something to go off the rails if there are delays.

So it's not so much a personal affront, as you're still using releases I've created. I assume the openjdk:8 packages are source packages, not binaries?

My concern is that users are being left with something inferior, as upstream 8u still lacks quite a few features compared with what's in IcedTea. That's why I continue to maintain it. In particular, if you have users on ARM, 32-bit users will drop back to an interpreter only build and 64-bit users won't have a working build at all (that's something I'm looking into upstream: https://bugs.openjdk.java.net/browse/JDK-8253036). OpenJDK 8u also still lacks the Shenandoah garbage collector recently added to 11u upstream and available via a USE flag in the IcedTea:8 builds. I don't see that ever going upstream in 8u. There was a lot of pushback for 11u as it was.

So, while I'm not concerned about it being the primary JDK across all platforms, I would like it to still be available and primary for architectures where it provides better support. I've never understood why the source version was not added to stable, but then I've always used testing anyway.

With regards to the delay on this release, it was the victim of a number of factors. When we released 8u262, it was almost immediately still-born due to a regression which resulted in 8u265. So the time that would have been spent doing 3.17 then ended up going on doing another upstream release. We then focused on the 7u & IcedTea 2.6 release because that needed to be finished off and, with no Fedora or RHEL builds any more, IcedTea was the only testing of our last batch of upstream changes there (it's now been taken over by Azul). Other upstream demands then meant it dragged on into October, at which point I decided it made more sense to just head for the next release rather than try and do two back to back.

Both are also big releases for 8u, with major new features (Java Flight Recorder and TLS v1.3) so that resulted in more issues and testing.

I think you did the right thing in prioritising the secure package that was available and sorry for not being contactable. How did you try to reach me? I use this personal e-mail to keep such work distinct from my paid work, but gnu.andrew at redhat will likely get my attention quicker (as should IRC, where I was pinged about the 7 release)

[Comment 8 Georgy Yakovlev 2020-10-29 03:44:49 UTC]

(In reply to Andrew John Hughes from comment #7)
> (In reply to Georgy Yakovlev from comment #4)
> > (In reply to Andrew John Hughes from comment #3)
> > > (In reply to Georgy Yakovlev from comment #1)
> > > > https://icedtea.classpath.org/hg/icedtea8/rev/1954b437af5a
> > > > 
> > > > finally tagged upstream. will do a bump soon but binary package will not get
> > > > stable keywords, maybe except x86 and ppc64be, but we'll see.
> > > 
> > > Why would this not get stable keywords? Do you plan to leave people with an
> > > unsecure version?
> > 
> > icedtea (the built-from source ebuild) never had stable keywords. it was
> > always marked as ~/unstable in gentoo.
> > 
> > icedtea-bin (which I build myself on own and gentoo HW from that ebuild and
> > distribute to users) had stable keywords all the time.
> > 
> > but since icedtea was untouched for half a year, skipped release, was
> > affected by couple dozen of CVEs, and I could not reach you, after chatting
> > with security team we decided to make openjdk:8  primary JDK, as it gets
> > released right after vulnerabilities disclosed and we usually have zero day
> > or 1 day bumps. so does adoptopenjdk (we use their binaries for bootstrap).
> > 
> > 
> > There's nothing personal, just trying to take security seriously and do best
> > for our users.
> > 
> > Also have some companies that use gentoo in production and they would prefer
> > immediate bumps. So do some users.
> 
> Yeah, it's me doing the upstream OpenJDK releases as well. And the Fedora
> and RHEL updates. That and IcedTea is a lot, so it's sadly quite easy for
> something to go off the rails if there are delays.

Can't even imagine amount of work you do with actual source as I struggle to test/build all that on all arches with not-so-frequent release schedule.

> 
> So it's not so much a personal affront, as you're still using releases I've
> created. I assume the openjdk:8 packages are source packages, not binaries?

Yes, absolutely nothing personal. Sorry if I made wrong impression.

We have both binary and source openjdk-8, and a binary jre8 for container people.
I'm using aarch64-shenandoah on arm64 and vanilla elsewhere for source packages.
prebuild binaries come from adoptopenjdk, so I don't build them myself. But they support less arches, so arches that are not supported by adoptopenjdk fully rely on icedtea.

And I would like to have icedtea back in top-notch condition as it, like you say,
contains a lot of stuff which is not in vanilla for various reasons, makes my life easier as downstream maintainer, less patching, valuable features and more arches supported out of the box.
It's the only distribution that builds and works on ALL our arches, arm32 arm64 ppc64be ppc64le x86 and amd64 + some musl libc variants with patching, so it's the default bootstrap JDK. Without it we'd loose binary java on x86, big-endian ppc64 and probably arm32, unless we start bootstrapping + patching vanilla.


> 
> My concern is that users are being left with something inferior, as upstream
> 8u still lacks quite a few features compared with what's in IcedTea. That's
> why I continue to maintain it. In particular, if you have users on ARM,
> 32-bit users will drop back to an interpreter only build and 64-bit users
> won't have a working build at all (that's something I'm looking into
> upstream: https://bugs.openjdk.java.net/browse/JDK-8253036). OpenJDK 8u also
> still lacks the Shenandoah garbage collector recently added to 11u upstream
> and available via a USE flag in the IcedTea:8 builds. I don't see that ever
> going upstream in 8u. There was a lot of pushback for 11u as it was.

arm32 has it's users and that's why I wanted to keep icedtea available there. I can make special arrangement that icedtea stays default there, of course.
like I said above for arm64 I already use aarch64-shenandoah tarballs, so it builds and works.


> 
> So, while I'm not concerned about it being the primary JDK across all
> platforms, I would like it to still be available and primary for
> architectures where it provides better support. I've never understood why
> the source version was not added to stable, but then I've always used
> testing anyway.

we have some repository rules, which prevented it going stable. equal visibility requirement. stable package can't depend on unstable one.
I think something was always unstable it it's dependency graph and prevented it from getting stabilized. But that can be fixed of course.

> 
> With regards to the delay on this release, it was the victim of a number of
> factors. When we released 8u262, it was almost immediately still-born due to
> a regression which resulted in 8u265. So the time that would have been spent
> doing 3.17 then ended up going on doing another upstream release. We then
> focused on the 7u & IcedTea 2.6 release because that needed to be finished
> off and, with no Fedora or RHEL builds any more, IcedTea was the only
> testing of our last batch of upstream changes there (it's now been taken
> over by Azul). Other upstream demands then meant it dragged on into October,
> at which point I decided it made more sense to just head for the next
> release rather than try and do two back to back.

I'm glad you finally sorted it out, I guess pandemic also did not help. Easy to let things slip and even get burned out.
me and security guys were checking for releases daily, I even bumped it without waiting for your overlay bump/announcement to get it in asap.

I actually already prepared commit to security-mask it, but checked hg just before push and saw a release tag made 10hrs ago at the time. huge relief.
removed mask commit and bumped instead.

> 
> Both are also big releases for 8u, with major new features (Java Flight
> Recorder and TLS v1.3) so that resulted in more issues and testing.
> 
> I think you did the right thing in prioritising the secure package that was
> available and sorry for not being contactable. How did you try to reach me?
> I use this personal e-mail to keep such work distinct from my paid work, but
> gnu.andrew at redhat will likely get my attention quicker (as should IRC,
> where I was pinged about the 7 release)

thanks for understanding. I'm glad we figured it out.
I used fsf email and periodically /who on IRC but got unlucky maybe. I'll send email again later, can't use mail at the moment.
I will keep in mind that I can use rh address, but will do it only in serious situations if required.

[Comment 9 Sam James 2021-01-28 03:10:22 UTC]

@gyakovlev: icedtea-bin? ;)

[Comment 10 Georgy Yakovlev 2021-02-12 02:20:24 UTC]

(In reply to Sam James from comment #9)
> @gyakovlev: icedtea-bin? ;)

life happened, just added 3.17.1 to the tree and will try to use that for binpkg.

[Comment 11 John Helmert III 2021-07-08 00:54:37 UTC]

Ping

[Comment 12 Federico Justus Denkena 2022-06-14 18:33:59 UTC]

Vulnerable package (dev-java/icedtea-bin-3.16.0:8) still in tree as stable.

[Comment 13 Hans de Graaff 2024-04-07 08:57:15 UTC]

Given that dev-java/icedtea has been treecleaned at this point and that an icedtea-bin version without these vulnerabilities is still pending, my suggestion is to mask icedtea-bin for removal as well.

I don't see any reverse dependencies for it anymore.

Any objections?

[Comment 14 Volkmar W. Pogatzki 2024-04-07 09:39:18 UTC]

(In reply to Hans de Graaff from comment #13)
> Given that dev-java/icedtea has been treecleaned at this point and that an
> icedtea-bin version without these vulnerabilities is still pending, my
> suggestion is to mask icedtea-bin for removal as well.
> 
> I don't see any reverse dependencies for it anymore.
> 
> Any objections?

tried that already, but then: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3a029d81c27090909a109a3349fe7b8e3e83bbc8

and filed a PR recently https://github.com/gentoo/gentoo/pull/35987 to get it re-removed from virtual/jdk

[Comment 15 Volkmar W. Pogatzki 2024-04-07 19:09:46 UTC]

This commit should allow building openjdk:8 on x86 without icedtea-bin:
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d12dc30217085d3a6605b85e5d7a2a26be81ea7c

[Comment 16 Larry the Git Cow 2024-04-08 07:15:03 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=550bb0595b669648bf88be0b470a7c25c6a3d2a5

commit 550bb0595b669648bf88be0b470a7c25c6a3d2a5
Author:     Volkmar W. Pogatzki <[e-mail]>
AuthorDate: 2022-08-25 08:12:57 +0000
Commit:     Miroslav Šulc <[e-mail]>
CommitDate: 2024-04-08 07:14:46 +0000

    profiles/package.mask: last rite dev-java/{gin,gwt,validation-api,icedtead-bin}
    
    Bug: https://bugs.gentoo.org/848804
    Bug: https://bugs.gentoo.org/732628
    Closes: https://bugs.gentoo.org/830248
    Bug: https://bugs.gentoo.org/716228
    Bug: https://bugs.gentoo.org/853100
    Signed-off-by: Volkmar W. Pogatzki <[e-mail]>
    Closes: https://github.com/gentoo/gentoo/pull/35987
    Signed-off-by: Miroslav Šulc <[e-mail]>

 profiles/package.mask | 12 ++++++++++++
 1 file changed, 12 insertions(+)