On Tue, Aug 26, 2014 at 08:25:15PM +0300, Timo Teras wrote:
> > The algorithm should be improved to never delete links which are
> > subsequently recreated.
>
> I almost answered "it's fixed". But it's not. IIRC, the version had it
> fixed, but it did not handle hash collisions nicely. This certainly is
> possibly to do, but needs some extra care when there's collisions and
> the entries need renaming instead of deletion.
>
> The time window is certainly a lot less in C-version, but it still
> exists. I'll look into fixing this too.
The collision case is tricky when a colliding trust-anchor is
deleted whose index suffix is not the largest. I'd be tempted to
symlink it to the remaining colliding certificate with the highest
index:
Before:
X.0 -> retired CA
X.1 -> retained CA
After:
X.0 -> retained CA
X.1 -> retained CA
And leave it that way for some time. On each run, if the highest
numbered index is duplicated by a lower-numbered index whose lstat(2)
age is sufficiently high (5 minutes or more?), that index can be
deleted (garbage collection). That might create a situation in
which we have:
X.0 -> CA1
X.1 -> CA1
X.2 -> CA2
(X.3 -> CA1 deleted)
In that case, update all but the first link to any fixed target to
point to the highest retained index.
X.1 -> CA2.
Leaving the invariant condition that at the end of each run at most
the last CA is duplicated. In steady-state this eliminates redundant
links, but avoids exposing verifiers to race conditions.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
