all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: emacs-devel@gnu.org
Subject: Re: NSM certificate prompt
Date: Sun, 14 Dec 2014 05:46:15 +0200	[thread overview]
Message-ID: <83mw6q51x4.fsf@gnu.org> (raw)
In-Reply-To: <87iohfyprn.fsf@lifelogs.com>

> From: Ted Zlatanov <tzz@lifelogs.com>
> 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.

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

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

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

> There's also the case that you may not want to use the host OS's trust
> store for your own reasons.  That should not be a struggle.  Emacs is
> not a all-in-one web browser, it's a platform.  Don't take away the
> users' choice of who they trust.

No other browser I know of allows that.

> Furthermore, GnuTLS until recently didn't have this functionality and
> somehow we survived. So it's not essential.

We survived because we do the equivalent by reading gnutls-trustfiles.

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

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

> we'd have "if you're running GnuTLS 3.x or older, you'll get this
> behavior, but with 3.y or newer, another behavior."

Yes, and why is that a problem?  Differences in behavior in different
versions exist whether we want it or not.

> I think it's pretty unpleasant behavior to dynamically toggle who
> you trust based on system library versions. So unless we *only*
> support GnuTLS versions that have this functionality, I'm strongly
> against making it the only option when it's available.
> 
> Finally, we have to consider backward compatibility.  Users who have
> customized their trustfiles should not be surprised.  We can put
> warnings in NEWS and blame the users when they don't read them, but I
> think it's much nicer to preserve the users' customizations.

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



  reply	other threads:[~2014-12-14  3:46 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-13 14:43 NSM certificate prompt Eli Zaretskii
2014-12-13 15:12 ` Lars Magne Ingebrigtsen
2014-12-13 16:01   ` Eli Zaretskii
2014-12-13 16:04     ` Lars Magne Ingebrigtsen
2014-12-13 16:46       ` Eli Zaretskii
2014-12-13 17:27         ` Lars Magne Ingebrigtsen
2014-12-13 15:27 ` Michael Albinus
2014-12-13 15:35   ` Lars Magne Ingebrigtsen
2014-12-13 16:57     ` Michael Albinus
2014-12-13 17:06       ` Eli Zaretskii
2014-12-13 17:29       ` Lars Magne Ingebrigtsen
2014-12-13 18:03         ` Eli Zaretskii
2014-12-13 18:06           ` Lars Magne Ingebrigtsen
2014-12-13 19:16             ` Michael Albinus
2014-12-13 20:02               ` Ted Zlatanov
2014-12-13 16:03   ` Eli Zaretskii
2014-12-13 16:39   ` Eli Zaretskii
2014-12-13 17:06     ` Michael Albinus
2014-12-13 18:01       ` Eli Zaretskii
2014-12-13 19:09         ` Michael Albinus
2014-12-13 19:13         ` Eli Zaretskii
2014-12-13 19:47           ` Ted Zlatanov
2014-12-13 20:06             ` Eli Zaretskii
2014-12-14  0:23               ` Lars Magne Ingebrigtsen
2014-12-14  1:38               ` Ted Zlatanov
2014-12-14  3:46                 ` Eli Zaretskii [this message]
2014-12-14  8:16                   ` Lars Magne Ingebrigtsen
2014-12-14 16:04                     ` Eli Zaretskii
2014-12-19 12:14                       ` Lars Ingebrigtsen
2014-12-19 14:41                         ` Eli Zaretskii
2014-12-19 16:42                           ` Ivan Shmakov
2014-12-19 16:47                           ` Lars Ingebrigtsen
2014-12-19 19:53                         ` Simon Leinen
2014-12-19 21:37                           ` Eli Zaretskii
2014-12-14 11:34                   ` Ted Zlatanov
2014-12-14 12:52                     ` Michael Albinus
2014-12-14 16:53                     ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83mw6q51x4.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.