The file construct.sh distributed with app-emulation/emul-linux-x86-java insecurely writes to files in /tmp numerous times without first checking if the files are symlinks. This could potentially allow for the overwriting of arbitrary files on the filesystem upon installation of app-emulation/emul-linux-x86-java.
amd64 please advise and bump as necessary.
amd64 team? And there is maybe http://sunsolve.sun.com/search/document.do?assetkey=1-26-102729-1 too, i don't know exactly. see bug 158659
The construct.sh script is used only during emerge, and for dev-java/sun-jre-bin{1.5,1.6} too. So if we fix it, there's no point in bump. Doesn't sandbox cover this, though?
(In reply to comment #3) > The construct.sh script is used only during emerge, and for > dev-java/sun-jre-bin{1.5,1.6} too. So if we fix it, there's no point in bump. > Doesn't sandbox cover this, though? OK, sandbox covers the construct.sh insecure temporary file usage. But there is also several vulnerabilities reported in bug 158659, in particular: http://sunsolve.sun.com/search/document.do?assetkey=1-26-102729-1 I think (IMHO) this affects the emulation Java package too.
there was a stable request anyway (bug 151705), so amd64 stable.
What you stabled wasn't fixed at all. I'll list it clearly: 1.5.0.08 - based on sun-jre-bin-1.5.0.08, vulnerable the same way as bug 158659 and bug 162511 - needs to be bumped to 1.5.0.10 first, then stable 1.4.2.03 - based on blackdown-jre, probably vulnerable as bug 161835 - since there's no new blackdown version, we could bump to version based on sun-jre-bin-1.4.2.13 instead of blackdown, at the cost of fetch restriction BTW, I've fixed the problem with /tmp usage by changing it to ${T}. as construct.sh is used only during emerge, no need to bump/stable/glsa for this.
wltjr commited 1.5.0.10, but he's not arch team member with stable system/chroot so can amd64 stable that?
(In reply to comment #7) > wltjr commited 1.5.0.10, but he's not arch team member with stable > system/chroot so can amd64 stable that? > amd64 stable
nothing to do for amd64 here
I vote for a GLSA, see 200701-15.
i'm actually the only active member of the security team, so i can't apply the policy telling that 2 positive votes include a GLSA. Let's have one btw :)
GLSA 200702-08, thx amd and java teams
