This is the mail archive of the cygwin-apps mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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:

>Hi guys,
>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 now,
>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.
<> and <> 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 package.

Regardless of the path chosen, please make sure there are PROMINENT NOTICES that users need to rehash their private certs directories after the upgrade.

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 setup.exe upgrades.

Hoping for a smooth 1.0.0 transition (after having seen some fail...)

Matthias Andree

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]