This is the mail archive of the
mailing list for the Cygwin project.
Re: HEADSUP maintainers: Change in openssl package requires change in setup.hint
Corinna Vinschen wrote on 2010-06-24:
On Jun 24 15:55, Matthias Andree wrote:
Corinna Vinschen wrote on 2010-06-24:
>according to the discussion starting here
>the layout of the openssl package has changed so that the runtime
>libraries are now in the libopenssl098 package, rather than in the
>openssl base package.
>The openssl package will be switched from 0.98 to 1.0.0 really soon
>and that switch will also introduce the new runtime package
>libopenssl100. This package is slightly backward incompatible with
What are the plans to deal with the hash vs. oldhash for the CApath
directories? All the directories hosting single-cert-per-file stuff
will have to be rehashed.
There are no plans.
Are the openssl maintainers aware there have been c_rehash fixes
post-1.0.0 release? I've filed one, and one other to generate dual
symlinks with a special c_rehash option which TTBOMK has not been
accepted upstream yet, but can also help with sharing such
directories between -0.9.8 and 1.0.0+ installations, should that be
necessary -- and I guess that would be the case from the existence
of separate packages for 0.9.8X and 1.0.0X.
I have no idea about this stuff. I'm maintaining openssl primarily
since it's required for openssh. If there's anything which isn't
fixed upstream, it won't be fixed for Cygwin. The Cygwin 1.0.0a-1
package is from the vanilla sources. The 0.9.8 runtime libs will
only be kept in place until all packages using it have been converted to
1.0.0. I have no incentive to keep old runtime libs indefinitely.
Then please hold your horses. Do it wrong and the upgrade breaks OpenSSL
on lots of installations.
And: if the upgrade isn't done properly, bug reports about this will often
be misfiled with the application programmers as regressions.
<http://www.fetchmail.info/> bear testimonies of such misfilings :)
Here's the short scoop:
- OpenSSL 1.0.0 uses a different hash for /usr/ssl/certs than 0.9.8 did,
so after the default ssl version is upgraded to 1.0.0, c_rehash needs to
be run on that directory.
- if the *default* version moves from 0.9.8o to 1.0.0a, c_rehash should be
run on /usr/ssl/certs, so that existing certificate configurations just
continue to work.
- while the 0.9.8 library has to be c_rehash (without the second patch I
posted from ticket 2278, and unless you run the patched version with the
extra compatibility argument) removes all old symlinks from
/usr/ssl/certs, so if you run 1.0.0's c_rehash, the 0.9.8 library no
longer finds certificates.
I can fancy the following solutions:
A - coordinate efforts so that *all* ssl-dependent packages have been
recompiled against to 1.0.0a, and then upgrade openssl and all users in
one giant leap, all at the same time.
alternatively, if you must keep 0.9.8,
B - patch c_rehash as I'd proposed to OpenSSL with the patch so as to get
two symlinks for each certificate for a transition period (i. e. until
0.9.8 is gone)
- also put prominent notices that users that rely on applications that
use 0.9.8 need to run c_rehash with the compatibility option
B2 - use my patch against (the 2278 ticket, see previous email) but
further modify it to always run compatibility mode, until 0.9.8 is gone
Independent of all that, consider a holistic approach to consolidate and
manage all certificates for all TLS packages (gnutls, and nss if shipped -
dunno) into these flat-file storages. GnuTLS always uses flat files, and
perhaps should share the default /usr/ssl/cert.pem location (unless it
already does, I didn't check).
Samples could be taken from Debian/Ubuntu with the
/usr/sbin/update-ca-certificates script found in their ca-certificates
Regardless of the path chosen, please make sure there are PROMINENT
NOTICES that users need to rehash their private certs directories after
I'd even propose to patch setup.exe so it can pop up such package-specific
notices, or print them at the end of the installation if in
non-interactive modes, and bump the setup.ini version to encourage
Hoping for a smooth 1.0.0 transition (after having seen some fail...)