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.
