--- Begin Message ---
|
Subject: |
24.3; Builtin TLS support should enable certificate verification support by default |
|
Date: |
Sat, 02 Nov 2013 16:05:21 +0100 |
Hi!
New builtin TLS support disables certificate verification by
default. This is a very bad practice and the default should be to check
for certificate validity.
Moreover, the end-user of a package using this builtin support has no
easy way to enable the verification of TLS certificates. For example,
Gnus does not provide anything to enable this and as a simple user, it
seems quite difficult to ensure that certificates are verified. And each
package has the responsability to enable this option. This is
cumbersome.
Previously, enabling/disabling certificate verification was easy. You
set `tls-program` variable to something that checks or don't check for
certificates. For gnutls-client, this was a matter of using or not using
the `--insecure` switch.
I didn't find a way to disable the builtin TLS support (other than to
recompile Emacs).
I propose:
1. Verify the certificates by default.
2. Prompt the user if there is a problem.
3. Add the possibility to not check for certificates by default.
I can provide a patch for the first step but I have little Emacs-fu for
the other two parts (all the more that most of the code is in C).
--
Use variable names that mean something.
- The Elements of Programming Style (Kernighan & Plauger)
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#13374: 24.?; open-gnutls-stream insecurity |
|
Date: |
Wed, 18 Dec 2013 17:50:39 -0500 |
|
User-agent: |
Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) |
On Tue, 08 Jan 2013 12:06:08 -0500 Stefan Monnier <address@hidden> wrote:
>>> It should default to nil (in other words, we'll ship 24.3 with the same
>>> insecure behavior it has right now). But we can recommend to the users
>>> to turn it on, and see how well it works in practice, and write the
>>> necessary prompts and customization logic that Lars outlined.
>> I think we should just leave things as is for 24.3, since it's too close
>> to release, and fix this properly for 24.5.
SM> I tend to agree, although, if the patch is sufficiently trivial, it
SM> could be accepted (e.g. define a new custom var, with nil default value
SM> and splice it somewhere in the code where nil makes no difference).
>> Instituting an option like that (which will have to be abandoned
>> later) as a stop-gap I feel isn't all that helpful.
SM> If the option will have to be abandoned, then it's indeed a loser, but
SM> I thought the idea is that this option will stay and the added code in
SM> 24.4 will "simply" be handling errors more cleverly and prompting the
SM> user to update this option on-the-fly.
This is done for the upcoming release. Marking this as done.
Ted
--- End Message ---