dar at xoe.solutions
Tue Sep 1 04:00:31 UTC 2020
1. Construe symlinks to current certs in a folder (old or new / file by
2. Symlink that folder
3. Rename the current symlink to that new symlink atomically.
On OpenSSL side statd would have to follow through on symlinks - if it
shouldnt do so.
This is +- how kubernetes atomically provisions config maps and secrets to
So there is a precedence for applications to follow this pattern.
I totally agree, that those constraints shall be put on applications in
order to have the freedom to focuse on a sound design.
If openssl really wanted to make it easy it would provide an independent
helper that would do exactly this operation on behalf of non-complying
Does it look like we are actually getting somewhere here?
I'd still better understand why atomic pointer swaps can be difficult and
how this can be mitigated. I'm sensing a bold move for a sounder
certificate consumption is possible there too (with potential upsides
further down). Do I sense right?
El lunes, 31 de agosto de 2020, Viktor Dukhovni <openssl-users at dukhovni.org>
> > On Aug 31, 2020, at 10:57 PM, Jakob Bohm via openssl-users <
> openssl-users at openssl.org> wrote:
> > Given the practical imposibility of managing atomic changes to a single
> > POSIX file of variable-length data, it will often be more practical to
> > create a complete replacement file, then replace the filename with the
> > "mv -f" command or rename(3) function. This would obviously only work
> > if the directory remains accessible to the application, after it drops
> > privileges and/or enters a chroot jail, as will already be the case
> > for hashed certificate/crl directories.
> There is no such "impossibility", indeed that's what the rename(2) system
> call is for. It atomically replaces files. Note that mv(1) can hide
> non-atomic copies across file-system boundaries and should be used with
> And this is why I mentioned retaining an open directory handle, openat(2),
> There's room here to design a robust process, if one is willing to impose
> reasonable constraints on the external agents that orchestrate new cert
> As for updating two files in a particular order, and reacting only to
> changes in the one that's updated second, this behaves poorly when
> updates are racing an application cold start. The single file approach,
> by being more restrictive, is in fact more robust in ways that are not
> easy to emulate with multiple files.
> If someone implements a robust design with multiple files, great. I for
> one don't know of an in principle decent way to do that without various
> races, other than somewhat kludgey retry loops in the application (or
> library) when it finds a mismatch between the cert and the key.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openssl-users