> On Sep 2, 2022, at 3:57 PM, Greg Troxel <gdt%lexort.com@localhost> wrote: > > Did I miss discussion on this? I am getting the impression that we now > have defaults: > no trust anchors installed > require verification > > which really doesn't make sense. If I am following correctly this is a > major behavior change in a controversial area, which isn't ok without > discussion/consensus. I did not realize it was controversial, but let's have the discussion. > Plus, this is a negative option, usually frowned upon. grep NO_ /usr/src/usr.bin/ftp/*.c > > So (absent confusion on my part, as always), it sounds like one of the > following should happen: > > 1) just revert this until we have discussion > 2) change the environment variable to CERTIFICATE_VALIDATION to use the term > from the RFC > https://www.rfc-editor.org/rfc/rfc5280#section-6 > and default to FALSE, enabling if set and TRUE. I don't care much about the environment variable name, and yes calling it what the RFC suggests is probably better. > If at some point the system installs trust anchors by default, the > default can change. I think we should be installing the anchors by default. I also think that people think that https gets validated by default. > > Plus, I think it's reasonable to have some config file in /etc/openssl > that signals "user has configured trust anchors and wishes to routinely > validate certificates". The existence of /etc/openssl/VALIDATE might be > a good trigger for validation, or some other color file. That would > mean that the code, running on a system with old config, would not be > surprising. Using this file now in option 2 instead of an environment > variable seems fine. > That is a good idea. christos
Attachment:
signature.asc
Description: Message signed with OpenPGP