Re: NSM certificate prompt

[Ted Zlatanov]

On Sun, 14 Dec 2014 05:46:15 +0200 Eli Zaretskii <address@hidden> wrote: 

>> From: Ted Zlatanov <address@hidden>
>> Date: Sat, 13 Dec 2014 20:38:20 -0500
>> 
EZ> What would be the reason for the user to remove 'system from the list?
EZ> If a user is somehow not happy about system trust data, she should
EZ> customize her system (if she is authorized), not Emacs.  E.g., add a
EZ> list of blacklisted certificates, remove certificates from the bundle,
EZ> etc.
>> 
>> I don't see how it's OK to exclude users who are not authorized to
>> customize their systems.  This is a common case.

EZ> If she's not authorized, she doesn't necessarily know what she is
EZ> doing.  This is security, right?

The authentication and authorization structure of the host system
targets different risks. I've often had the need to build and install
binaries or dynamically updated external package systems like oh-my-zsh
for instance. Even when I was the host system's manager, it didn't
always make sense to make system-level changes to accommodate one user's
preferences and needs.

>> Another case is where the system is out of date and you don't have the
>> option of updating it, because it's too old or the update server is
>> down.

EZ> This case means the user should want to _add_ certificates, not remove
EZ> the system ones.

There have been several cases where users wanted to remove certificates
signed by a compromised certificate authority before updated CA
certificate OS packages were available. Sometimes a few hours can be
critical in these situations.

While CRL support is a good way to deal with this in general, I still
think giving the user the option to manage their trustfiles is valuable.
But we should definitely try to support CRLs or DANE more urgently,
rather than expecting the user to manage trustfiles and certificate
revocations.

>> But even if we decide to make 'system the only option

EZ> That's not my suggestion.  My suggestion is always to use system trust
EZ> (when it's available), and in addition allow the user to customize
EZ> gnutls-trustfiles.  The only issue is whether to have 'system' in
EZ> gnutls-trustfiles and allow its removal.

OK, sorry, I was arguing with a straw man. I think there's a better
approach, below...

EZ> Fine.  I'm going to make this a Windows-only code, and we can then
EZ> stop arguing.

Please add the code unconditionally as you planned. I think it will be
an improvement that way. I will then add code to make the transition
easier after your patch:

* add a featurep or a function to GnuTLS that tells us if that system
  function is available

* when it's available, default the trustfiles to nil

* when it's not available, use the old trustfiles default

* add a specific boolean option to disable that system function, off by default

* improve messaging to tell the user what trustfiles we're loading

* update NEWS, docs, etc.

I hope that's more agreeable.

Ted