1. Construe symlinks to current certs in a folder (old or new / file by file)<div>2. Symlink that folder</div><div>3. Rename the current symlink to that new symlink atomically.</div><div><br></div><div>On OpenSSL side statd would have to follow through on symlinks - if it shouldnt do so.</div><div><br></div><div>This is +- how kubernetes atomically provisions config maps and secrets to pods.</div><div><br></div><div>So there is a precedence for applications to follow this pattern.</div><div><br></div><div>I totally agree, that those constraints shall be put on applications in order to have the freedom to focuse on a sound design.</div><div><br></div><div>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 applications.</div><div><br></div><div>Does it look like we are actually getting somewhere here?</div><div><br></div><div>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?</div><div><div><br><br>El lunes, 31 de agosto de 2020, Viktor Dukhovni <<a href="mailto:openssl-users@dukhovni.org">openssl-users@dukhovni.org</a>> escribió:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> On Aug 31, 2020, at 10:57 PM, Jakob Bohm via openssl-users <<a href="mailto:openssl-users@openssl.org">openssl-users@openssl.org</a>> wrote:<br>
> <br>
> Given the practical imposibility of managing atomic changes to a single<br>
> POSIX file of variable-length data, it will often be more practical to<br>
> create a complete replacement file, then replace the filename with the<br>
> "mv -f" command or rename(3) function.  This would obviously only work<br>
> if the directory remains accessible to the application, after it drops<br>
> privileges and/or enters a chroot jail, as will already be the case<br>
> for hashed certificate/crl directories.<br>
<br>
There is no such "impossibility", indeed that's what the rename(2) system<br>
call is for.  It atomically replaces files.  Note that mv(1) can hide<br>
non-atomic copies across file-system boundaries and should be used with<br>
care.<br>
<br>
And this is why I mentioned retaining an open directory handle, openat(2),<br>
...<br>
<br>
There's room here to design a robust process, if one is willing to impose<br>
reasonable constraints on the external agents that orchestrate new cert<br>
chains.<br>
<br>
As for updating two files in a particular order, and reacting only to<br>
changes in the one that's updated second, this behaves poorly when<br>
updates are racing an application cold start.  The single file approach,<br>
by being more restrictive, is in fact more robust in ways that are not<br>
easy to emulate with multiple files.<br>
<br>
If someone implements a robust design with multiple files, great.  I for<br>
one don't know of an in principle decent way to do that without various<br>
races, other than somewhat kludgey retry loops in the application (or<br>
library) when it finds a mismatch between the cert and the key.<br>
<br>
-- <br>
        Viktor.<br>
<br>
</blockquote></div></div>