[PATCH] Re: OpenSSL 0.9.8 - 1.0.0 CApath (in)compatibility
[third resend to fill in Victor's reference - removed him from Cc: to avoid the dupe; all in the hopes it finally makes it or I get at least an NDN] Am 17.05.2010, 19:19 Uhr, schrieb Victor Duchovni: On Mon, May 17, 2010 at 10:23:16AM +0300, Eray Aslan wrote: On 17.05.2010 03:02, Victor Duchovni wrote: If you want to be really clever, you may be able to hash two copies of the root CA directories with 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. If you decide to take this approach, test carefully! No warranty! There is a patch for openssl for the above c_rehash problem (not tested): http://rt.openssl.org/Ticket/Display.html?id=2234 guest/guest for username and password works for loging in to rt. The patch addresses a different issue: incorrect PATH handling in c_rehash(1). I don't run into this, because when I want to use a particular OpenSSL version, I put the right directory first in the PATH, I don't rely solely on correct internal handling of the PATH by the command-line tools. The issue I am reporting is that neither the 0.9.8 nor the 1.0.0 c_rehash generates a set of symlinks that the other can use. It is possible, with care, to merge the symlinks built by each release (in separate copies of the CApath directory) into a single set of symlinks (with suitable adjustment of sequence numbers on hash collisions). I have a Perl script that does this, but I am not prepared to support it. If someone else wants to document and support such a tool, I can make it available to the volunteer. It is ~100 lines of Perl that merges symlinks from a set of working directories to a target CApath directory, which is modified only to the extent necessary, existing correct symlinks are always left in-place. This can be used on live CApath directories with no little of transient verification errors. The only race condition is when a trusted root is deleted which has the same hash as a trusted root that stays, and the hash.0 link needs to go while the hash.1 link stays. The script does this via rename(hash.1, hash.0), but this cannot be made race-free, the verifier may have just read the old hash.0 link, and may be about to use the hash.1 link. Both hash collisions and deletion of trusted roots are rare. The race window is very narrow. This is substantially safer than the crude delete all links, then make new links approach of c_rehash. Even if, let's extend the c_rehash tool because that's much less of a hassle and can later be included upstream if desired. *IMPORTANT:* Please CC: me on your feedback! I read the list only sporadically for lack of time. I offer an *UNSUPPORTED, NO WARRANTIES* patch (aka. use at your own risk) against OpenSSL's OpenSSL_1_0_0-stable branch at http://homepages.uni-paderborn.de/mandree/openssl-c_rehash-both.patch. I reserve the right to remove it any time, without prior notice. I'm not attaching it because I know the list driver is picky, but I don't know how picky. I include an inline version for your perusal, but it will likely not apply due to spacing differences, word wrapping and thereabouts. If it fails, download it. The patch adds -old_compat and -help options to c_rehash. -help does the obvious (if given as first argument). -old_compat (if given as first argument) will make c_rehash add -subject_hash (as usual) and *also* -subject_hash_old hashes. Be sure to keep OpenSSL 1.0.0's openssl application first in the path or point the environment variable OPENSSL to it. CRL hashing hasn't been tested, let me know how it goes. If it works, I'll submit it for OpenSSL 1.0.0a. -- Matthias Andree openssl-c_rehash-both.patch Description: Binary data Patch *for perusal* (if it fails to apply, download from URL above!):
Re: [PATCH] Re: OpenSSL 0.9.8 - 1.0.0 CApath (in)compatibility
On Thu, May 20, 2010 at 09:45:41AM +0200, Matthias Andree wrote: The only race condition is when a trusted root is deleted which has the same hash as a trusted root that stays, and the hash.0 link needs to go while the hash.1 link stays. [...] This is substantially safer than the crude delete all links, then make new links approach of c_rehash. Even if, let's extend the c_rehash tool because that's much less of a hassle and can later be included upstream if desired. The patch you posted looks reasonable. In my case, the backwards-compatible CApath, is only needed briefly, while I am installing the new Postfix that links with 1.0.0. After that, I don't need the old links, since the CApath in question is used by exactly one application. I also wanted non-disruptive CApath updates... -- Viktor. P.S. Morgan Stanley is looking for a New York City based, Senior Unix system/email administrator to architect and sustain our perimeter email environment. If you are interested, please drop me a note.
Re: OpenSSL 0.9.8 - 1.0.0 CApath (in)compatibility
On 17.05.2010 03:02, Victor Duchovni wrote: If you want to be really clever, you may be able to hash two copies of the root CA directories with 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. If you decide to take this approach, test carefully! No warranty! There is a patch for openssl for the above c_rehash problem (not tested): http://rt.openssl.org/Ticket/Display.html?id=2234 guest/guest for username and password works for loging in to rt. FYI -- Eray
Re: OpenSSL 0.9.8 - 1.0.0 CApath (in)compatibility
On Mon, May 17, 2010 at 10:23:16AM +0300, Eray Aslan wrote: On 17.05.2010 03:02, Victor Duchovni wrote: If you want to be really clever, you may be able to hash two copies of the root CA directories with 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. If you decide to take this approach, test carefully! No warranty! There is a patch for openssl for the above c_rehash problem (not tested): http://rt.openssl.org/Ticket/Display.html?id=2234 guest/guest for username and password works for loging in to rt. The patch addresses a different issue: incorrect PATH handling in c_rehash(1). I don't run into this, because when I want to use a particular OpenSSL version, I put the right directory first in the PATH, I don't rely solely on correct internal handling of the PATH by the command-line tools. The issue I am reporting is that neither the 0.9.8 nor the 1.0.0 c_rehash generates a set of symlinks that the other can use. It is possible, with care, to merge the symlinks built by each release (in separate copies of the CApath directory) into a single set of symlinks (with suitable adjustment of sequence numbers on hash collisions). I have a Perl script that does this, but I am not prepared to support it. If someone else wants to document and support such a tool, I can make it available to the volunteer. It is ~100 lines of Perl that merges symlinks from a set of working directories to a target CApath directory, which is modified only to the extent necessary, existing correct symlinks are always left in-place. This can be used on live CApath directories with no little of transient verification errors. The only race condition is when a trusted root is deleted which has the same hash as a trusted root that stays, and the hash.0 link needs to go while the hash.1 link stays. The script does this via rename(hash.1, hash.0), but this cannot be made race-free, the verifier may have just read the old hash.0 link, and may be about to use the hash.1 link. Both hash collisions and deletion of trusted roots are rare. The race window is very narrow. This is substantially safer than the crude delete all links, then make new links approach of c_rehash. -- Viktor. P.S. Morgan Stanley is looking for a New York City based, Senior Unix system/email administrator to architect and sustain our perimeter email environment. If you are interested, please drop me a note.
