Taylor R Campbell <riastr...@netbsd.org> writes: > How is using /etc/openssl/certs/.certctl as the token different from > using /etc/openssl/certs.conf as the token?
Because normal updates merge etc in various ways, and if certs.conf comes along with that (because it is in etc.tgz) then that is automatic and not an admin action. > How does this satisfy the two criteria I set down in the previous > message? Repeating here: > > (a) new installations get /etc/openssl/certs populated out of the box, that dir is empty and certctl can write to it and set the sentinel. There is no problem populating an empty dir because that's not removing admin config. > and > > (b) on _future_ updates (like 10.0 to 10.1, where both releases have > certctl(8) and a default certs.conf), /etc/openssl/certs gets > updated too (unless you set `manual' in /etc/openssl/certs.conf). Once there is a sentinel file, certctl works like it does now. So I don't see the concern here. > Please be specific either about what mechanism you mean and how it > meets these criteria, or about scenarios that you think the current > mechanism will inadequately address. The current one fails to address an update where etc is merged (as it should be), causing certs.conf to exist, in the case where the admin has configured trust anchors. I also don't see how the situation of having mozilla-rootcerts-openssl installed is handled, and what happens when it is later de-installed. > The status quo in HEAD (if pulled up to netbsd-10) will be: > > 1. New installations get /etc/openssl/certs populated out of the box. > > 2. Updates to existing installations that follow the long-standing > procedure of > > - update kernel > - unpack non-etc sets > - run etcupdate > - run postinstall > > will interactively prompt during etcupdate to install the new > /etc/openssl/certs.conf. That is one longstanding procedure among many in that there are various flavors of etcupate and private scripts that do the same thing. It is not ok for upgrades to need to be interactive in many situations, and hence etcupdate cannot be the one true path. And, prompting to install a new config file, which happens all the time, is not the same as asking if it's ok to overwrite something. > The file has comments explaining what it does and how to override > it -- here's the current content: Sure, once it's looked at. With pkgdb, there was the idea that people might have to do things. But it was a disaster in practice for many. (I realize this is easier to recover from.) > 3. If: > - you have /etc/openssl/certs.conf from 10.0, > - you haven't set it to manual, > - there are changes to mozilla-certdata from 10.0 to 10.1, and > - you update to 10.1, > then those changes will be reflected in /etc/openssl/certs on > postinstall (but etcupdate won't prompt anything about certs.conf > -- unless something has also changed in that, of course). sure that's fine > If you follow a different procedure for update, like naively unpacking > etc sets or running a bespoke etcupdate replacement, well, you should > expect to have to deal with the fallout yourself. I don't think that is at all reasonable. Yes, unpacking etc.tgz into etc is nuts, but taking a file that exists in the new set and not in /etc and silently putting it in /etc is not dismissible as bespoke; it's the right thing to do and IMHO it's a bug that etcupdate prompts itstead of just doing it. This is based on experience using NetBSD in large scale testbeds where more machines than people can think about get updated to new builds frequuently; this "change file in /etc to match etc.tgz, as long as the file in /etc either doesn't exist and hasn't existed, or has the same bits as it did when it was last put there from an install or automated update" procedure works extremely well. It's been available in pkgsrc since 2006. And, I don't even think "etcupdate asks if it's ok to install some new file you don't necesssarily understand the consequence of" avoids this concern. We do not have a history of adding new config files via this path that then overwrite admin config. Maybe there's some other way for certctl to recognize things that it didn't add, without a sentinel file.
