Where did the openssl upgrade go wrong?

[Princess Nell]

net-misc/nxclient is broken since the most recent openssl upgrade because the 0.9.8 libs cannot be found. Yet:

[toralf]

Didn't a revdep-rebuild help ?

[Princess Nell]

Apparently not. Maybe it doesn't check files under /usr/NX?

[Veldrin]

maybe a emerge -1 openssl:0.9.8 could help...

I do not use nx-client, but apparently they are still using jpeg-6b too...

V.
_________________
read the portage output!
If my answer is too concise, ask for an explanation.

[toralf]

Well, I use a proprietary VPN solution here under Gentoo where I hard-nosed symlinked the libs from openssl 1.0.0b-r1 to libssl.so.0.9.8 - and it worked for that particular app - probably worth a try

[Princess Nell]

Doesn't work in this case, it looks specifically for 0.9.8.

The weird thing is that the e* tools tell me this version of openssl is installed, but the files are gone after revdep-rebuild.

[Veldrin]

what tools are you using?

eix tells me, that there are 2 slotted versions of openssl available...
what does qlist openssl return? I am specially interested what versions of libcrypto and libssl are listed...

V.
_________________
read the portage output!
If my answer is too concise, ask for an explanation.

[Princess Nell]

[samo]

Did you try to emerge nxclient after the update of openssl?

I had also some problems after the update last weekend and I solved the problems by following the hints in /var/log/portage/elog/summary.log.

[gentoo_ram]

The nxssh binary is linked against the 0.9.8 version of libcrypto. There's really nothing you can do about it. I personally copied the 0.9.8 versions of the library files into /usr/NX/lib and this worked. You don't need the libraries in /usr/lib (at least for this package).

[CodeNoodler]

Hello gentoo-ers

Well, I usually pay attention to the messages posted after emerge updates, but curiously I did not get the revdep-rebuild instructions after openssl-1.0.0b-r1 was updated onto my system "world".

But as I proceeded merrily ignorant, I did run a routine broad spectrum revdep-rebuild after which my system broke because on next boot I got all the notices about libssl.0.9.8 and libcrypto.0.9.8 being missing.

After some forum mining I eventually re-emerged the old openssl-0.9.8p and, lo, my system worked once more.
I then, out of curiosity, re-emerged the latest openssl-1.0.0b-r1 to see the "revdep-rebuild --library <libname.so>" messages I apparently must have missed -- but there was nothing of the sort.

Instead, I saw the following.

[Hu]

[CodeNoodler]

Thanks for the response.

But the nature of the problem with the emerge of dev-libs/openssl-1.0.0b-r1 and its side effects still puzzles me.

At my current state, I can see where the desired/intentional presence of a prev slotted version would imply that I would not want to take measures to remove old libs, and thus the "<libname>.so.n.n" pruning instructions might be unwise. Hence a possible code branch; but the nature of the feedback from emerge indicates a much less graceful exit from such a condition. This may indicate a problem that still exists? Plus, I cannot be sure if it is the same message generated by the initial problematic encounter with the openssl update. It could be that the artefacts resulting in this ungraceful message sequence also is responsible for accidental slotting of the package version.

As far as I can tell, it was the normal emerge-based package management that slotted my openssl pkg in the first place. I think I did notice that both versions were still present while I was undertaking diagnosis of my sick gentoo-box, though at this point it might be considered mere memory recollection and subject to possible brain glitch. Granted, I did later execute an explicit install of the elder version while repairing my system. (Crime scene was thusly compromised. Oops.)

If there was a hitch in my emerge process that kept the old version "apparently though erroneously" slotted (instead of properly managing its vital and non-vital bits) might it have caused the revdep library rebuild instructions from my view when it should not have?

While not able to swear without further research, I am pretty sure that most upgrades requiring library revdep-rebuilds have not generally invoked slotting in the interim.

And now, do I have to be a bit insecure about being able to uninstall my slotted dev-libs/openssl-0.9.8p without suffering some subtle problems that will crop up when I least expect it? I've never had to do explicit unmerges following other similar library management activities.

[Hu]

Check your /var/log/emerge.log to see what was added, removed, and upgraded, and in what order. The 0.9.8 slot is provided for people who must have the old ABI names, usually to support proprietary programs that have not been rebuilt with the newer library. I am not sure what you mean by feedback from emerge indicating an ungraceful exit. The snippet you showed does not indicate any problems with the ebuild, though the c_rehash utility reacted badly to the presence of broken symbolic links in your CA directory.

Installing =dev-libs/openssl-1.0.0b-r1 the first time (as an upgrade from <=dev-libs/openssl-0.9.8o) should have preserved the old library names, but done so by making them part of the new 1.0.0b-r1 package. It should then have told you to do revdep-rebuild prior to removing those libraries. It should never remove those libraries on its own, nor should it create a new slotted install on its own.

[CodeNoodler]

By ungraceful I just meant that something less-than-expected by the ebuild processes was encountered (missing files) implying that I had manifested an accidental condition (which might mean troubled waters ahead). I am at a loss as to how the CA directory or the related links got busted, or how to fix it at this time.

My emerge.log indicates that both openssl-0.9.8p and openssl-1.0.0b-r1 were installed at the same emerge world pass. Some following equery checks show that acroread-9.4.0 still requires openssl-0.9.8* (it was upgraded from "o" to "p") -- which may imply that I should not yet have gotten any revdep related library removal instructions, even if it still installed the latter version (and should it have done that, given the still existing dependency? How was the -1.0 series planted on my system in the first place?).

In any case, something I did afterward, perhaps my generic revdep-rebuild pass, must have scrogged the libssl.so and libcrypto.so libraries causing my system to falter during the reboot process next time around because the boot feed showed complaints about the missing libs.

Perhaps expectedly, Acroread crashed under brief testing, since I had gone ahead and earlier executed all that library revdep stuff which I thought I had missed - so something wants those libs. I will probably re-emerge the old openssl for now and then determine if it makes sense to try to have both installed. It is not clear to me that they can gracefully coexist without some trickery, so I might just mask further openssl updates for the time being if it keeps trying to "accidentally" recreate the troubled situation.

[Hu]

In what order were the two packages installed? Could you provide the output of grep openssl /var/log/emerge.log? The CA directory probably broke on its own, as part of the normal removal of certificates. Remove the dangling symbolic links to fix it.

Portage upgraded to >=dev-libs/openssl-1.0.0a-r3 because that is the right thing to do. Installing dev-libs/openssl:0.9.8 is a necessary evil to avoid breaking closed source applications that are not linked against the newer version of OpenSSL. Unless you need some feature provided only by Acroread, I suggest replacing it with a PDF reader that does not require a legacy version of OpenSSL, so that you can remove dev-libs/openssl:0.9.8 from the system. Regardless of whether you switch to a different PDF reader, I would not remove or mask the newer versions of OpenSSL. They contain potentially relevant security fixes, relative to the older versions.

[Edit: s/proprietary/closed source/ to more accurately reflect that the problem is programs which users cannot rebuild with the newer OpenSSL, irrespective of the licensing status of the programs.]

[CodeNoodler]

Re: broken CA directory

[Hu]

[CodeNoodler]

Whoops. That makes sense. Okay, I've stepped a few installation seqs earlier into the emerge.log ...

It appears that for some reason, openssl-0.9.8o-r2 got installed even after the update to openssl-1.0.0a-r3 got inserted and successfully unmerged openssl-0.9.8o.

[Hu]

[CodeNoodler]

Well, examining the logfiles, I did think it made sense to see the slotting of the elder openssl since it was called in by Acroread at that time. But remember, the weirdness began when my general revdep-rebuild apparently cleared something, and my system started failing during normal boot cycle when other functions were looking for the dev/libs/openssl-0.9.8p libraries and could not find them. It was then that I started looking into this openssl version-related library matter. I just inferred that if it was properly slotted in some expected/understood manner, then my box would not have gotten busted by typically normal maintenance activity.

And then there was the noise openssl-1.0.0b-r1 reported about the busted links to the certificate files which ... I cannot tell if it even affected the /usr/lib/lib{ssl,crypto} thing at all. I removed the broken links, and they did not seem to get replaced, nor were there any complaints; so I guess there is some script that just processes contents found in the directory or was not otherwise looking for those file/link handles in particular? Okay, I guess. Anyhoo ...

Out of curiosity I went ahead and emerged the world dependencies with Acroread on board to see what happens. It pulled in the older openssl-0.9.8p as a slot (as we should expect) .. but then it reported ...

[Princess Nell]

Well, my problem was a bit different. openssl-0.9.8p was installed, but the corresponding libs were gone after revdep-rebuild.