| Summary: | dev-libs/openssl-1.0.0a: upgrade sometimes needs to `c_rehash /etc/ssl/certs/` | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | SpanKY <vapier> |
| Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | eras, hasufell |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=475352 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 333117 | ||
|
Description
SpanKY
2010-08-16 20:51:54 UTC
Try running "c_rehash /etc/ssl/certs/" yes, that fixes things ive never head of that util, it doesnt have a manpage, and it doesnt respond to normal --help options ... this doesnt modify any files installed by packages into that dir, so i guess we should run that in postinst on $ROOT/etc/ssl/certs/ postinst sounds like a plan this would be the fifth time I've seen this problem and everytime running it helped btw, it's a perl script and perl is in DEPEND of openssl, but not RDEPEND, how does that impact binpkgs? perl is in DEPEND because of the build system needing perl. the idea was to avoid runtime deps. c_rehash looks pretty simple ... should be easy to re-implement in posix shell ive added an automatic c_rehash to pkg_postinst. the perl issue we'll clone. http://sources.gentoo.org/dev-libs/openssl/openssl-1.0.0a-r1.ebuild?r1=1.1&r2=1.2 (In reply to comment #5) > ive added an automatic c_rehash to pkg_postinst. Hmm, hash functions changed between openssl-0.9.8 and openssl-1.0.0: From the CHANGES file in the root of the OpenSSL 1.0.0 distribution: "Enhance the hash format used for certificate directory links. The new form uses the canonical encoding (meaning equivalent names will work even if they aren't identical) and uses SHA1 instead of MD5. This form is incompatible with the older format and as a result c_rehash should be used to rebuild symbolic links. [Steve Henson]" So, c_rehash should only be needed once on the upgrade from 0.9.8 to 1.0.0. Putting it in pkg_postinst seems like an overkill. Perhaps has_verison && c_rehash in pkg_preinst? Also, for completeness sake: If we want to be really clever, we should be able to hash two copies of the same set of certificates each with a different version of c_rehash (and corresponding utilities from the appropriate OpenSSL version) and then combine the set of symbolic links into a final directory that should work with either library. I wouldn't but just as a FYI. (In reply to comment #6) > Hmm, hash functions changed between openssl-0.9.8 and openssl-1.0.0: should have read Hmm, hash functins in c_rehash changed between openssl-0.9.8 and openssl-1.0.0: Sorry. i think i'll hold off adding the clever code which doesnt run the c_rehash when necessary to help out all the people who have already installed openssl-1 unless you have a way of checking the files in $ROOT/etc/ssl/certs/ and so we can avoid doing a check of what version of openssl was previously installed ... (In reply to comment #8) > i think i'll hold off adding the clever code which doesnt run the c_rehash when > necessary to help out all the people who have already installed openssl-1 Noted. > unless you have a way of checking the files in $ROOT/etc/ssl/certs/ and so we > can avoid doing a check of what version of openssl was previously installed ... Nope. Current practice of c_rehash in pkg_postinst is the simple and foolproof solution afterall. Thanks for looking into it. Apart from the ebuild being very low quality, the handling of certs in app-misc/ca-certificates is not properly done either. All that postinst hackery is bad. For people who want to understand how openssl figures out about certs, read https://www.happyassassin.net/2015/01/12/a-note-about-ssltls-trusted-certificate-stores-and-platforms/ What the ebuild/devs should do is: * don't use debian hacks * only install the trusted db bundle (which is currently in a wrong location and as such openssl cannot find it and wants the hash-style directoriy which we generate with c_rehash), but don't build the hash-style directory at all... if users want to handle certs manually, they should use app-crypt/p11-kit which allows to build both the bundle and the hash-style ca-directory. And then all the stuff update-ca-certificates does becomes a sed-one-liner in src_install without any symlinks needed. * put the building of the trusted db bundle behind a USE flag instead of assuming that people trust all that stuff * use proper install methods and not cp/mv in src_compile and src_install |