tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: [Christos Zoulas] CVS commit: src/usr.bin/ftp

Christos Zoulas <> writes:

>> On Sep 2, 2022, at 3:57 PM, Greg Troxel <> 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.

There's been a large amount of discussion about having the base system
provide a pre-configured set of trust anchors.  Without that already
agreed on and in place, it seems clear that changing ftp(1)'s behavior
is going to be a breaking change for a lot of people, and thus well over
the the needing-discussion line.

>> Plus, this is a negative option, usually frowned upon.
> grep NO_ /usr/src/usr.bin/ftp/*.c

I guess, and I didn't really say this earlier, but this is not really
about ftp.  pkix more or less says TLS should do certificate validation,
but it's longstanding practice in many client programs not to validate.
For the most part this is about a sysadmin/user either

  configuring a set of trust anchors, and deciding that that all SSL/TLS
  and other uses of pkix (x509) certificates should be subject to

  deciding not to play the configured trust anchor game and not turning
  on the "fail if not validated" switch.

>> 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
>>     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.

Do you think it matters if it's an environment variable?  Do you think
this needs to be a user option, or system?  Why environment vs
comand-line like wget?

>> 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.

That is a separate discussion, which is totally fine to have in a new
thread.  This discussion is about changing the behavior of ftp to fail
without validation while the system does not install trust anchors.

Right now, this change acts like "disable https in ftp" for people that
do not have configured trust anchors.

>> 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.

So are you ok with:

  1) Right now, in ftp(1), enable certificate validation if
  /etc/openssl/VALIDATE exists (and remove the env var).  Tell people
  who want this to touch /etc/openssl/VALIDATE?

  2) Sort of have a plan that if/when we configure trust anchors by
  default and perhaps if a package configures them
  (mozilla-rootcerts-openssl) that this file be created, to turn on
  validation for all pkix users, as the system default?    This would be
  the interface from all trust anchor configuration schemes to all

Attachment: signature.asc
Description: PGP signature

Home | Main Index | Thread Index | Old Index