HEADSUP maintainers: Change in openssl package requires change in setup.hint

[Matthias Andree]

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
>> >http://cygwin.com/ml/cygwin-apps/2010-06/msg00101.html
>> >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
>> >0.9.8.
>>
>> 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/fetchmail-FAQ.html#R14> and  
<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.

RECOMMENDATION:

- 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.

HOWEVER:

- 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

Or:

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