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!):
