Bugzilla Bug 161835

http://sunsolve.sun.com/search/document.do?assetkey=1-26-102731-1
http://sunsolve.sun.com/search/document.do?assetkey=1-26-102732-1
http://sunsolve.sun.com/search/document.do?assetkey=1-26-102729-1


Fixed with 1.4.2.13/1.5.0.09.


see bug 158659 for further information

Yeah, but latest blackdown is only 1.4.2.03, based on Sun's 1.4.2.10, so we
can't just bump it (upstream looks pretty dead). Though the bugs look like they
are only about applets (which means the nsplugin in browsers) so we could just
stop installing the plugin. But it's the only JDK/JRE with 64bit browser plugin
for amd64. Users would then have to use 32bit browser with emul-linux-x86-java
to have java browser plugin. Unless that 64bit->32bit plugin wrapper that's
used for flash works with java too.

Any news on this one?

(In reply to comment #2)
> Any news on this one?
> 

I don't think it's a big problem to remove nsplugin support from blackdown-jdk
as from what I hear it's prone to crashes but let's get the opinion from the
amd64 arch team. The change would also need to be documented to the Java guide
at least. Maybe we could have a virtual/java-browser-plugin that would pull in
something that provides the plugin.

Ok experiences from gentoo-java mailing lists show that we should remove the
nsplugin support from blackdown-java. Doc monkeys: Please change
http://www.gentoo.org/doc/en/java.xml to update it so that we are disabling the
64 bit plugin which leaves 32 bit plugin as the only option. I can check the
diff if you are unsure about the changes.

(In reply to comment #4)
> Ok experiences from gentoo-java mailing lists show that we should remove the
> nsplugin support from blackdown-java. Doc monkeys: Please change
> http://www.gentoo.org/doc/en/java.xml to update it so that we are disabling the
> 64 bit plugin which leaves 32 bit plugin as the only option. I can check the
> diff if you are unsure about the changes.
> 

Betelgeuse said he'd ask on the gentoo-user ML about this, and I setup a
poll[1] on the forums, so let's get some more widespread user feedback on this
before the thing is removed entirely. :)

[1] http://forums.gentoo.org/viewtopic-t-552110.html

(In reply to comment #5)
> (In reply to comment #4)
> > Ok experiences from gentoo-java mailing lists show that we should remove the
> > nsplugin support from blackdown-java. Doc monkeys: Please change
> > http://www.gentoo.org/doc/en/java.xml to update it so that we are disabling the
> > 64 bit plugin which leaves 32 bit plugin as the only option. I can check the
> > diff if you are unsure about the changes.
> > 
> 
> Betelgeuse said he'd ask on the gentoo-user ML about this, and I setup a
> poll[1] on the forums, so let's get some more widespread user feedback on this
> before the thing is removed entirely. :)
> 
> [1] http://forums.gentoo.org/viewtopic-t-552110.html
> 

Betelgeuse, any comments?  My vote is for p.use.masking the flag for our arch.

use flag masked on the amd64 arch

(In reply to comment #7)
> use flag masked on the amd64 arch

So, uh, does this mean I should go ahead and change the java documentation?

I'd like to comment on the absurdness of the current situation:

The only arch that needs blackdown nsplugin is amd64
The only arch that disables blackdown nsplugin is amd64

In my thinking you should globally disable nsplugin for blackdown, just as you
do for sun-j{re,dk}, but then unmask it for amd64 only, as for all other arches
you'd better use sun-j{re,dk} for nsplugin, while for amd64 you don't have that
option.

Problem is blackdown's plugin is very unstable on amd64. It crashes the browser
allot. Which is most of the reason for masking and making it not available.
Really the only option ATM for a Java plugin on amd64 is to use a 32bit bin
browser, with a emul-linux-x86-java package.

Crashing sometimes is better than never working, and I'd very much like not
having to install all the 32bit emul libraries just so that I have to switch
browser every time I need Java.

(In reply to comment #11)
> Crashing sometimes is better than never working, and I'd very much like not
> having to install all the 32bit emul libraries just so that I have to switch
> browser every time I need Java.

Any user who wants a crashing plugin can just unmask the use flag themselves in
/etc/portage/profile/.

Thanks for the pointer, I'd already tried to put a package.use.mask containing
"dev-java/blackdown-jdk -nsplugin" in /etc/portage (next to package.use and
package.mask), but that didn't work, so I thought I'd have to resort to sed-ing
the portage tree after every sync, but after moving package.use.mask to
/etc/portage/profile/ it started working. Now, just please don't remove the
actual nsplugin logic from the ebuild, even if it gets masked on all arches.

I agree that mask only on amd64 makes no sense.
1) we should mask it everywhere
2) (optionally? betelgeuse suggested this) unmask only for amd64 (x86 can use
sun-jdk) AND only for the ~arch revision (which should then give ewarn that the
plugin is vulnerable and unsupported)
3) update docs, based on the decision about 2) Worth noting is maybe that
there's another alternative, using konqueror you don't need nsplugin, it uses
java (your system/user vm) directly so it can be 64bit sun-jdk as well.
4) emul-linux-java-1.4 is currently blackdown, really should change it to
sun-jdk even if there's fetch restriction

(In reply to comment #7)
> use flag masked on the amd64 arch
> 

And why did you do that? The documentation was supposed to be done first.

(In reply to comment #10)
> Problem is blackdown's plugin is very unstable on amd64. It crashes the browser
> allot. Which is most of the reason for masking and making it not available.
> Really the only option ATM for a Java plugin on amd64 is to use a 32bit bin
> browser, with a emul-linux-x86-java package.
> 

Or maybe, install net-www/nspluginwrapper-0.9.91.4 ;-) 

(In reply to comment #14)
> 4) emul-linux-java-1.4 is currently blackdown, really should change it to
> sun-jdk even if there's fetch restriction
> 

emul-linux-x86-java-1.4* is really needed?

Currently, I only have emul-linux-x86-java-1.5.0.10 installed on my system :-/

(In reply to comment #15)
> (In reply to comment #7)
> > use flag masked on the amd64 arch
> > 
> 
> And why did you do that? The documentation was supposed to be done first.
> 

sorry bout that, didn't catch that one.

Last time I talked to nightmorph, he was going to update it anyway.

(In reply to comment #11)
> Crashing sometimes is better than never working, and I'd very much like not
> having to install all the 32bit emul libraries just so that I have to switch
> browser every time I need Java.
> 

For me it was crashing most all times. Way more than not, IMHO pretty unusable.
As for the 32bit emul Java. I guess you don't want Flash either since that
requires a 32bit browser as well.

For quite some time I was a purist only running 64bit browsers, but after time,
there was no point. Hardly any diff on performance and etc, and 64bit no
java/flash vs 32bit with both. 32bit is likely the best way to go.



(In reply to comment #17)
>
> emul-linux-x86-java-1.4* is really needed?
> 
> Currently, I only have emul-linux-x86-java-1.5.0.10 installed on my system :-/

The only 1.4 emul one packaged is blackdown :( Which IMHO really should be
Sun's. But a 1.5 plugin or greater should be just fine, should be able to view
all 1.4 applets and etc.

I would go with 1.5 or 1.6

(In reply to comment #14)
> I agree that mask only on amd64 makes no sense.
> 1) we should mask it everywhere

Masked everywhere. I didn't unmask it for ~arch because that has the potential
for breakage if we forget to update the profiles with revision bumps. Let's
just document using /etc/portage/profile/package.use.mask to unmask it.

(In reply to comment #18)

Documentation updated.

I did not, however, mention how to unmask the flag locally. The flag was masked
for the obvious reasons you all know -- unresolved security vulnerabilities are
serious issues, to say nothing of blackdown's total instability. We wouldn't
document the usage of masked or removed packages because of their
security/stability problems; it would be just as stupid to document unmasking
the flag.

(In reply to comment #21)
> (In reply to comment #18)
> 
> Documentation updated.
> 

All done here then. Unless the security team wants to write a GLSA for people
to stop using blackdown nsplugin?

(In reply to comment #22)
> (In reply to comment #21)
> > (In reply to comment #18)
> > 
> > Documentation updated.
> > 
> 
> All done here then. Unless the security team wants to write a GLSA for people
> to stop using blackdown nsplugin?

I think that's a good idea. Go all the way and treat this as seriously as any
other package that upstream hasn't fixed -- I'm even for removing the flag from
the ebuild altogether until the issues are fixed. I think that this should be
taken seriously, and well, when packages have unresolved security issues,
they're removed from the tree. Why should the USE flag for blackdown be any
different?

The "pure 64-bit environment argument for keeping the flag in the ebuild"
doesn't apply, as konqueror can use a 64-bit java VM directly without the
plugin flag.

Security please vote on a mask GLSA for this one.

/vote yes for maskglsa - if upstream is dead, there's no other option.

voting yes too.

OK but how will we handle such a GLSA. There is no "affected version",
glsa-check will either always report a vulnerable package, or always an
unaffected package.

BTW does any official source mention that only web applets are vulnerable? Are
you sure standard Java applications (.class) are not vulnerable?

(In reply to comment #28)
> BTW does any official source mention that only web applets are vulnerable? Are
> you sure standard Java applications (.class) are not vulnerable?
> 

"Security Vulnerabilities Related to Serialization in the Java Runtime
Environment may Allow Untrusted Applets to Elevate Privileges"

Normal Java applications run without sandboxing so they can pretty much do what
they want like applications written in C/C++.

Blackdown is "Based on Sun's 1.4.2-10 source code" which means any older
vulnerability there's for sun 1.4.2.10 most probably applies here. Not sure if
I recall any not related to applets.

would it be possible to rev-bump the ebuilds, without the nsplugin USEflag, in
order to force our users to upgrade their system, and to make glsa-check warn
as expected?

Ping java on comment #31.

(In reply to comment #31)
> would it be possible to rev-bump the ebuilds, without the nsplugin USEflag, in
> order to force our users to upgrade their system, and to make glsa-check warn
> as expected?
> 

Well isn't a revision bump with the nsplugin use flag masked as it is ok?

(In reply to comment #33)
> (In reply to comment #31)
> > would it be possible to rev-bump the ebuilds, without the nsplugin USEflag, in
> > order to force our users to upgrade their system, and to make glsa-check warn
> > as expected?
> > 
> 
> Well isn't a revision bump with the nsplugin use flag masked as it is ok?
> 

(sorry for the late answer)

It will be OK, although i prefer not globally killing the nspluging useflag.
Then we will be able to send a correct GLSAs with proper version numbers, and
unsure that a normal "emerge world" will work around the vulnerability.

(In reply to comment #34)
> > Well isn't a revision bump with the nsplugin use flag masked as it is ok?
> > 
> 
> (sorry for the late answer)
> 
> It will be OK, although i prefer not globally killing the nspluging useflag.

Makes no sense to me? Where am I suggesting to kill it?

the "nspluging" useflag would be masked for that package. It would affect all
versions of the package. I would prefer a revision bump, without the "nsplugin"
useflag, and without masking this useflag. Thus, the older versions will not be
affected if someone wants to reemerge an old version. And glsa-check will
continue to complain because of the vulnerability.

But it is late now, and if you disagree, feel free to revbump + mask.

Well, after all, as you prefer :)

(In reply to comment #36)
> the "nspluging" useflag would be masked for that package. It would affect all
> versions of the package. I would prefer a revision bump, without the "nsplugin"
> useflag, and without masking this useflag. Thus, the older versions will not be
> affected if someone wants to reemerge an old version. And glsa-check will
> continue to complain because of the vulnerability.

That would be hard to maintain, assuming we would want to leave some version
with nsplugin around, as some people want to use it no matter what. With all
revbump we would have to revbump both affected and unaffected and update glsa
for the new revbumps.

> But it is late now, and if you disagree, feel free to revbump + mask.

Done
vulnerable:
< blackdown-jdk-1.4.2.03-r14
< blackdown-jre-1.4.2.03-r14

unaffected:
>= blackdown-jdk-1.4.2.03-r14
>= blackdown-jre-1.4.2.03-r14

Just note in the GLSA that in order to stay unaffected, one must not unmask the
masked nsplugin flag. And I realized one needs portage >=2.1.1 for use.mask to
work. Can you force that in the glsa? Our eclass already sets portage DEPEND to
>=2.1 and in the tree there's 2.1.1-r2 the lowest matching this. So maybe glsa
update will already pull this even if user has only 2.1 installed, not sure.

I think the best solution would be to extend glsa to allow built_with_use-like
checks, I can imagine more situations where we use.mask some flag for security
but want to keep it usable for those who don't care.

I notice that on the GLSA forums thread, the text of it reads: 

" Chris Evans has discovered multiple buffer overflows in the Sun JDK and the
Sun JRE possibly related to various AWT and font layout functions. Tom Hawtin
has discovered an unspecified vulnerability in the Sun JDK and the Sun JRE
relating to unintended applet data access. He has also discovered multiple
other unspecified vulnerabilities in the Sun JDK and the Sun JRE allowing
unintended Java applet or application resource acquisition."

Notice the continual references to "Sun", despite the fact that this GLSA is
for the Blackdown Java implementation. There's all the talk about Sun, yet at
the end of the GLSA, it recommends that users switch *to* the Sun Java
implementation to avoid the nsplugin issue. This is a point of confusion for
users; it should be clarified.

GLSA 200705-20, thanks everybody

@caster: well it's possible to add "vulnerable portage<2.1.1" in the GLSA, but
that would bring too much complication in regard of the benefit, imho.

@nightmorph: well mmm, yeah, but the vulnerabilities mentioned in the GLSA are
always fixed at the time the GLSA is sent. (except if it's a "maskglsa", with
masked package).

Why it still (-nsplugin) on amd64?