The GLSA message contains the following: (...) Affected package: dev-libs/openssl Affected archs: All Vulnerable: <1.0.1j Unaffected: >=1.0.1j>=~0.9.8z_p2 (...) I'm guessing that the Vulnerable/Unaffected fields for this particular GLSA are badly formatted, but the fact is that 0.9.8z_p3 should not trigger the advisory if it is considered as unaffected. Reproducible: Always
*** Bug 535860 has been marked as a duplicate of this bug. ***
SpanKY, Although the nature of this bug is the same as Bug 535860, it does not concern the same versions of openssl. I hope GLSA developers won't miss the current bug thinking it's the same as the old one! I opened a Forum thread on this bug, not having realized it's a GLSA bug: https://forums.gentoo.org/viewtopic-t-1017056-highlight-.html I use "glsa-check -l" after every world update (a good habit, i think), and the sudden apparition of multiple imaginary vulnerabilities at first alarmed me, and now, many days later, is becoming a little annoying... An amusing thought: Since openssl is a basic package, and hence no doubt installed on GLSA developpers' systems, the only way to miss this bug is if they do not really run "glsa-check -l" on their own systems... ;-) Thanks :)
Could someone please finally take care of this? Not only GLSA 201412-39 but also GLSA's 201110-01, 201203-12, 201312-03, 201404-07, 201407-05 and 201503-11 are incorrectly triggered by dev-libs/openssl-0.9.8z_p6:0.9.8 .
The problem is that the current GLSA format doesn't properly support SLOTs. Therefore, whenever a new version in the old OpenSSL branch/slot is released, we have to add these unaffected versions to the GLSAs individually. For most OpenSSL GLSAs, this was done up to 0.9.8z_p5; I have just added versions of up to 0.9.8z_p15 (which don't exist yet) in order to workaround this limitation. The list from comment 3 is indeed complete. I have just reproduced it and grepped through all the other GLSAs. The fixes should be live within the hour. Sorry about the long delay! (In reply to orionbelt2 from comment #2) > An amusing thought: Since openssl is a basic package, and hence no doubt > installed on GLSA developpers' systems, the only way to miss this bug is if > they do not really run "glsa-check -l" on their own systems... ;-) Or they don't have openssl-0.9.8 installed. ;)
Thanks a lot, Tobi, it's fine now. (In reply to Tobias Heinlein from comment #4) > The problem is that the current GLSA format doesn't properly support SLOTs. I guess it may support them the day when fixing these kinds of bugs becomes mortally boring for you guys ;-) > (In reply to orionbelt2 from comment #2) > > An amusing thought: Since openssl is a basic package, and hence no doubt > > installed on GLSA developpers' systems, the only way to miss this bug is if > > they do not really run "glsa-check -l" on their own systems... ;-) > > Or they don't have openssl-0.9.8 installed. ;) Good point, i guess i missed the obvious... Alas, i am facing problems with okular, and occasionally i have to use acroread, which depends on pre-1.x openssl. I hope to find some time to look into the okular problems and hopefully get rid of acroread. Thanks again.
Sorry to bring bad news but that this bug has resurfaced with dev-libs/openssl-0.9.8z_p8. See GLSA 201507-15. I guess this is inevitable as long as GLSA does not support SLOTs, as comment 4 explains...
(In reply to orionbelt2 from comment #6) > Sorry to bring bad news but that this bug has resurfaced with > dev-libs/openssl-0.9.8z_p8. See GLSA 201507-15. > > I guess this is inevitable as long as GLSA does not support SLOTs, as > comment 4 explains... Yup, thanks for the note, we'll just have to add a bunch of new versions to the unaffected packages
Kristian apparently did this on 2016-02-09 "already". However, GLSA 201506-02 and 201507-15 were affected by this too and I just adjusted them. Sorry that this took such a long time to fix again. I promise to look out for this issue the next time we release an OpenSSL advisory.
Many thanks, Tobias, i confirm that the error message has now disappeared :)
