On 2015-07-30 23:17, Stuart Henderson wrote: > On 2015-07-30, Vadim Zhukov <[email protected]> wrote: >> 2015-07-30 20:16 GMT+03:00 Stuart Henderson <[email protected]>: > cert.pem is pretty much a required file, we can't just move it to examples/. > For people who don't touch it, it's a simple no-touch sysmerge update. > For people who do, having sysmerge ask about merging it is a lot safer > than just overwriting. > >> I'd ask another question: why can't software use /etc/ssl/myown.pem, >> or /etc/ssl/*.pem, ever, instead of /etc/ssl/cert.pem? This will make >> "trust" and "untrust" operations as simple as possible. Noone in >> healthy mind would place junk in /etc/ssl anyway, right? > > Some software allows you to set a different certificate file; other > software doesn't. Patching everything in ports that verifies SSL certs > to allow the user to specify an alternative file would just be insane. > And of course then there's no single way to tell programs to use the > alternative file; "ftp -S cafile=/path/to/cert.pem", > "env SSL_CERT_FILE=/path/to/cert.pem lynx" > >> Or we may ship /etc/ssl/base.pem in base tgz, and install >> /etc/ssl/cert.pem -> base.pem at installation time. This way things >> will work by default, and if you need to have your own trust path, you >> just change symlink. What do you think? > > That doesn't really help. One common scenario is wanting to add a > single CA to the standard file, but otherwise pick up updates (e.g. with > sysmerge), this method doesn't allow that.
There are for sure use cases (I've got several myself right off the bat) that would benefit from a simpler solution. Of course appending your own certs to the huge /etc/ssl/cert.pem file does work, but even with the assistance of sysmerge it is a clunky, potentially error prone maneuver... So I borrowed an idea from how the Courier MTA/IMAP/POP3 server manages some of its configuration files: The system could check whether /etc/ssl/cert.pem (or whatever path any particular application provides) is a regular file, in which case business as usual. But if it is a *directory* then LibreSSL would internally concatenate all of its contents (or, for example, just all *.pem files) when initializing the certificate chain. That "simple" mechanism would give the system administrator an application agnostic/transparent way to manage additions to the certificate store. I put simple within quotes though, because then I went into the source to see if I could quickly put together a proof of concept diff for discussion purposes... [ insert audience's laughter here ] To probably no ones surprise (including my own) I quickly gave up, realizing what an insanely complex piece of software it is! My head hurt just trying to follow along what was happening and who called what when why... I'm definitely not the right person to fiddle with that piece of code without some serious reading up, and of course any change made without a complete grasp of the entire library is almost certain to have unintended and potentially very serious side effects just about anywhere... So as I would only be doing everybody a disservice by providing code at this stage, I'm just throwing the idea out there for now. Is it a good idea or will it just confuse people and system? Is it even doable without breaking compatibility? If so, is it worth the effort? Regards, /Benny
