* bug#18600: 24.3.94; EWW fails to check https certificates
@ 2014-10-02 5:48 Mark H Weaver
2014-10-03 23:01 ` Glenn Morris
2014-11-23 17:10 ` Lars Magne Ingebrigtsen
0 siblings, 2 replies; 18+ messages in thread
From: Mark H Weaver @ 2014-10-02 5:48 UTC (permalink / raw
To: 18600
I used EWW to visit an https website that uses a self-signed and
long-expired https certificate. It failed to notify me of any problem.
In GNU Emacs 24.3.94.1 (i686-pc-linux-gnu, GTK+ Version 3.10.1)
of 2014-10-02 on localhost
Windowing system distributor `The X.Org Foundation', version 11.0.11202000
Configured using:
`configure
CONFIG_SHELL=/gnu/store/wgvrj5q40prd4d1fb0j81n6gxdpqwz79-bash-4.3.27/bin/bash
SHELL=/gnu/store/wgvrj5q40prd4d1fb0j81n6gxdpqwz79-bash-4.3.27/bin/bash
--prefix=/gnu/store/6x3z5nwya75jgfs76qkpj25va9iwsqd4-emacs-24.3.94
--enable-fast-install
--with-crt-dir=/gnu/store/1zxdnj48g45pwram0s8nprvkkwxzp62b-glibc-2.20/lib'
Important settings:
value of $LC_ALL: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Summary
Minor modes in effect:
shell-dirtrack-mode: t
diff-auto-refine-mode: t
tooltip-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
buffer-read-only: t
line-number-mode: t
Recent input:
[removed; irrelevant]
Recent messages:
[removed; irrelevant]
Load-path shadows:
None found.
Features:
(shadow term ehelp emacsbug sendmail sort gnus-cite mail-extr gnus-async
gnus-bcklg qp gnus-ml disp-table nndraft nnmh nnfolder netrc gnus-agent
gnus-srvr gnus-score score-mode nnvirtual gnus-msg gnus-art mm-uu
mml2015 epg-config mm-view mml-smime smime dig nntp gnus-cache gnus-sum
nnoo gnus-group gnus-undo nnmail mail-source gnus-start gnus-spec
gnus-int gnus-range gnus-win misearch multi-isearch gnutls shr-color
color timezone parse-time help-mode mule-util url-queue network-stream
starttls url-http tls url-gw url-cache url-auth eww mm-url gnus gnus-ems
nnheader wid-edit url url-proxy url-privacy url-expand url-methods
url-history url-cookie url-domsuf url-util url-parse auth-source eieio
byte-opt bytecomp byte-compile cconv eieio-core gnus-util password-cache
url-vars mailcap shr browse-url shell pcomplete comint ansi-color
paredit edmacro kmacro cl-loaddefs cl-lib server w3m-wget w3m-load
magit-bisect magit-key-mode magit diff-mode log-edit easy-mmode message
format-spec rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode
mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mm-util help-fns
mail-prsvr mailabbrev mail-utils gmm-utils mailheader ring pcvs-util
add-log geiser-install geiser scheme time-date tooltip electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list newcomment lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)
Memory information:
((conses 8 389222 31229)
(symbols 24 32379 0)
(miscs 20 195 588)
(strings 16 51077 6316)
(string-bytes 1 1780492)
(vectors 8 25575)
(vector-slots 4 590009 18268)
(floats 8 413 443)
(intervals 28 3719 319)
(buffers 512 28)
(heap 1024 44807 14554))
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#18600: 24.3.94; EWW fails to check https certificates
2014-10-02 5:48 bug#18600: 24.3.94; EWW fails to check https certificates Mark H Weaver
@ 2014-10-03 23:01 ` Glenn Morris
2014-10-03 23:44 ` Glenn Morris
2014-10-04 21:34 ` Ted Zlatanov
2014-11-23 17:10 ` Lars Magne Ingebrigtsen
1 sibling, 2 replies; 18+ messages in thread
From: Glenn Morris @ 2014-10-03 23:01 UTC (permalink / raw
To: Mark H Weaver; +Cc: 18600
Mark H Weaver wrote:
> I used EWW to visit an https website that uses a self-signed and
> long-expired https certificate. It failed to notify me of any problem.
Setting gnutls-verify-error non-nil may help (I don't know what it does
with self-signed certificates).
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#18600: 24.3.94; EWW fails to check https certificates
2014-10-03 23:01 ` Glenn Morris
@ 2014-10-03 23:44 ` Glenn Morris
2014-10-04 21:34 ` Ted Zlatanov
1 sibling, 0 replies; 18+ messages in thread
From: Glenn Morris @ 2014-10-03 23:44 UTC (permalink / raw
To: Mark H Weaver; +Cc: 18600
PS see previous discussion in http://debbugs.gnu.org/16978 .
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#18600: 24.3.94; EWW fails to check https certificates
2014-10-03 23:01 ` Glenn Morris
2014-10-03 23:44 ` Glenn Morris
@ 2014-10-04 21:34 ` Ted Zlatanov
2014-10-04 23:24 ` Mark H Weaver
2014-10-05 2:16 ` Glenn Morris
1 sibling, 2 replies; 18+ messages in thread
From: Ted Zlatanov @ 2014-10-04 21:34 UTC (permalink / raw
To: Glenn Morris; +Cc: 18600, Mark H Weaver
On Fri, 03 Oct 2014 19:01:42 -0400 Glenn Morris <rgm@gnu.org> wrote:
GM> Mark H Weaver wrote:
>> I used EWW to visit an https website that uses a self-signed and
>> long-expired https certificate. It failed to notify me of any problem.
GM> Setting gnutls-verify-error non-nil may help (I don't know what it does
GM> with self-signed certificates).
Emacs will reject such certificates then. I tested that as part of
http://debbugs.gnu.org/16978 and would appreciate Mark's verification.
After 24.4 (now 25.1) is released it will be t by default. Mark, can we
close this bug since http://debbugs.gnu.org/16978 already has all the info?
Thanks
Ted
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#18600: 24.3.94; EWW fails to check https certificates
2014-10-04 21:34 ` Ted Zlatanov
@ 2014-10-04 23:24 ` Mark H Weaver
2014-10-05 2:00 ` Stefan Monnier
2014-10-05 2:16 ` Glenn Morris
1 sibling, 1 reply; 18+ messages in thread
From: Mark H Weaver @ 2014-10-04 23:24 UTC (permalink / raw
To: Glenn Morris; +Cc: 18600
Ted Zlatanov <tzz@lifelogs.com> writes:
> On Fri, 03 Oct 2014 19:01:42 -0400 Glenn Morris <rgm@gnu.org> wrote:
>
> GM> Mark H Weaver wrote:
>>> I used EWW to visit an https website that uses a self-signed and
>>> long-expired https certificate. It failed to notify me of any problem.
>
> GM> Setting gnutls-verify-error non-nil may help (I don't know what it does
> GM> with self-signed certificates).
>
> Emacs will reject such certificates then. I tested that as part of
> http://debbugs.gnu.org/16978 and would appreciate Mark's verification.
Yes, that works, thanks.
> After 24.4 (now 25.1) is released it will be t by default. Mark, can we
> close this bug since http://debbugs.gnu.org/16978 already has all the info?
I almost closed the bug myself, but on second thought I think this case
of eww https warrants special consideration, independent of the more
general question of how 'open-gnutls-stream' should behave by default.
There are a few reasons for this:
1. In the case of imaps, smtps, xmpp, etc, the most common use case is
to connect to a single server only for each of these protocols, and
very often that's one's own server with self-signed certs.
2. In the case of https, the typical use cases are very different, as
are the expectations. When browsing the web, one typically talks to
a very large number of https servers. More often than not, these
servers have certificates signed by a well-known CA. (Ideally it
should be possible to disable checking based on URL).
3. Emacs 24.4 will be the first release that includes eww, so there are
no preexisting users of eww that would be annoyed by suddenly having
their existing functionality stop working.
With these in mind, I have two recommendations:
* I believe that eww https should check certificates by default in 24.4,
even though other tls connections are tolerant by default.
* At minimum, it should be possible to enable certificate checking for
eww https connections while still allowing self-signed certificates
for other uses of 'open-gnutls-stream' such as imaps and smtps. This
is fairly common case.
IMO, anyway. If you disagree, I'll defer to your judgment, but my
feeling is that the current behavior would not be well received.
Thanks,
Mark
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#18600: 24.3.94; EWW fails to check https certificates
2014-10-04 23:24 ` Mark H Weaver
@ 2014-10-05 2:00 ` Stefan Monnier
2014-10-05 2:38 ` Marking changes to be backported Glenn Morris
2014-10-05 17:17 ` bug#18600: 24.3.94; EWW fails to check https certificates Mark H Weaver
0 siblings, 2 replies; 18+ messages in thread
From: Stefan Monnier @ 2014-10-05 2:00 UTC (permalink / raw
To: Mark H Weaver; +Cc: 18600
> With these in mind, I have two recommendations:
> * I believe that eww https should check certificates by default in 24.4,
> even though other tls connections are tolerant by default.
> * At minimum, it should be possible to enable certificate checking for
> eww https connections while still allowing self-signed certificates
> for other uses of 'open-gnutls-stream' such as imaps and smtps. This
> is fairly common case.
I think it's too late to do that for Emacs-24.4. But we should apply
such a change to `emacs-24' after the 24.4 release, so that it will be
included in the next release regardless if the next release is 25.1 or
a 24.5 bugfix.
Stefan
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#18600: 24.3.94; EWW fails to check https certificates
2014-10-04 21:34 ` Ted Zlatanov
2014-10-04 23:24 ` Mark H Weaver
@ 2014-10-05 2:16 ` Glenn Morris
1 sibling, 0 replies; 18+ messages in thread
From: Glenn Morris @ 2014-10-05 2:16 UTC (permalink / raw
To: Mark H Weaver; +Cc: 18600
Ted Zlatanov wrote:
> close this bug since http://debbugs.gnu.org/16978 already has all the info?
They are merged.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Marking changes to be backported
2014-10-05 2:00 ` Stefan Monnier
@ 2014-10-05 2:38 ` Glenn Morris
2014-10-05 16:46 ` Glenn Morris
2014-10-06 1:13 ` Stefan Monnier
2014-10-05 17:17 ` bug#18600: 24.3.94; EWW fails to check https certificates Mark H Weaver
1 sibling, 2 replies; 18+ messages in thread
From: Glenn Morris @ 2014-10-05 2:38 UTC (permalink / raw
To: Emacs developers
Stefan Monnier wrote:
> I think it's too late to do that for Emacs-24.4. But we should apply
> such a change to `emacs-24' after the 24.4 release, so that it will be
> included in the next release regardless if the next release is 25.1 or
> a 24.5 bugfix.
There needs to be an agreed convention to mark trunk changes that should
be backported to the release branch at some later date. "Remember to do
it" doesn't scale.
A note in the commit log would do, but it should have some kind of
standard format. But if we only realize after the commit was made,
some other method is needed. Either a file in admin, or perhaps a git
notes file.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Marking changes to be backported
2014-10-05 2:38 ` Marking changes to be backported Glenn Morris
@ 2014-10-05 16:46 ` Glenn Morris
2014-10-06 1:13 ` Stefan Monnier
1 sibling, 0 replies; 18+ messages in thread
From: Glenn Morris @ 2014-10-05 16:46 UTC (permalink / raw
To: Emacs developers
A simple file in admin would do, one revision per line.
Someone could write a script to backport (labelling the commit with
"Backport...") each revision from trunk and remove it from the input
file.
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#18600: 24.3.94; EWW fails to check https certificates
2014-10-05 2:00 ` Stefan Monnier
2014-10-05 2:38 ` Marking changes to be backported Glenn Morris
@ 2014-10-05 17:17 ` Mark H Weaver
1 sibling, 0 replies; 18+ messages in thread
From: Mark H Weaver @ 2014-10-05 17:17 UTC (permalink / raw
To: Stefan Monnier; +Cc: 18600
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> With these in mind, I have two recommendations:
>> * I believe that eww https should check certificates by default in 24.4,
>> even though other tls connections are tolerant by default.
>> * At minimum, it should be possible to enable certificate checking for
>> eww https connections while still allowing self-signed certificates
>> for other uses of 'open-gnutls-stream' such as imaps and smtps. This
>> is fairly common case.
>
> I think it's too late to do that for Emacs-24.4. But we should apply
> such a change to `emacs-24' after the 24.4 release, so that it will be
> included in the next release regardless if the next release is 25.1 or
> a 24.5 bugfix.
I continue to think this will be ill-received, and could result in more
bad PR for the GNU Project, but having said that, I'll let it go now.
Thanks,
Mark
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Marking changes to be backported
2014-10-05 2:38 ` Marking changes to be backported Glenn Morris
2014-10-05 16:46 ` Glenn Morris
@ 2014-10-06 1:13 ` Stefan Monnier
2014-10-06 6:37 ` Glenn Morris
1 sibling, 1 reply; 18+ messages in thread
From: Stefan Monnier @ 2014-10-06 1:13 UTC (permalink / raw
To: Glenn Morris; +Cc: Emacs developers
> There needs to be an agreed convention to mark trunk changes that should
> be backported to the release branch at some later date. "Remember to do
> it" doesn't scale.
If it's really needed, we can have a "emacs-24-next" branch for that.
Then we merge emacs-24 into emacs-24-next, and then we merge
emacs-24-next into trunk.
But a few notes in an `admin' file sounds fine for now.
Stefan
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Marking changes to be backported
2014-10-06 1:13 ` Stefan Monnier
@ 2014-10-06 6:37 ` Glenn Morris
2014-10-06 13:25 ` Stefan Monnier
2014-10-06 15:09 ` Eli Zaretskii
0 siblings, 2 replies; 18+ messages in thread
From: Glenn Morris @ 2014-10-06 6:37 UTC (permalink / raw
To: Stefan Monnier; +Cc: Emacs developers
Stefan Monnier wrote:
>> There needs to be an agreed convention to mark trunk changes that should
>> be backported to the release branch at some later date. "Remember to do
>> it" doesn't scale.
>
> If it's really needed, we can have a "emacs-24-next" branch for that.
I think it will be needed if: there are to be pure bug-fix releases, and
pretesting is going to continue to take months, and development is going
to continue at the same time. (There are probably tons of things fixed
in trunk today that should go into version 24.5, if there is one. Who's
going to dig them all out and backport them? No-one.)
> Then we merge emacs-24 into emacs-24-next, and then we merge
> emacs-24-next into trunk.
Yet more branches sounds more complicated to me (doesn't that mean you
need to know when you make a change where it should go?), but I don't
care about the system so long as there is one.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Marking changes to be backported
2014-10-06 6:37 ` Glenn Morris
@ 2014-10-06 13:25 ` Stefan Monnier
2014-10-06 15:16 ` Eli Zaretskii
2014-10-06 18:49 ` Glenn Morris
2014-10-06 15:09 ` Eli Zaretskii
1 sibling, 2 replies; 18+ messages in thread
From: Stefan Monnier @ 2014-10-06 13:25 UTC (permalink / raw
To: Glenn Morris; +Cc: Emacs developers
> Yet more branches sounds more complicated to me (doesn't that mean you
> need to know when you make a change where it should go?),
One way or another, someone will have to decide which change goes "in
the current pretest" (let's call it 24.4), "in the next bug-fix" (let's
call it 24.5), or "longer term" (let's call it 25.1).
If the committer knows before committing where that change should go,
then having 3 branches and committing to the proper branch is the
best solution.
If that's not the case, then having 3 branches doesn't help, indeed,
since the commit will have to be backported to the proper branch, if
applicable. Note that this "backporting" will take place regardless of
whether we have 3 branches active at a time or not. Having 3 branches
active at a time, does allow the backporting to be done any time you
want, whereas sticking to the "trunk vs emacs-24" scheme we have simply
means that some of the backporting will only take place once the
"emacs-24" branch is changed from "branch for 24.4" to "branch for
24.5".
Stefan
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Marking changes to be backported
2014-10-06 6:37 ` Glenn Morris
2014-10-06 13:25 ` Stefan Monnier
@ 2014-10-06 15:09 ` Eli Zaretskii
1 sibling, 0 replies; 18+ messages in thread
From: Eli Zaretskii @ 2014-10-06 15:09 UTC (permalink / raw
To: Glenn Morris; +Cc: monnier, emacs-devel
> From: Glenn Morris <rgm@gnu.org>
> Date: Mon, 06 Oct 2014 02:37:30 -0400
> Cc: Emacs developers <emacs-devel@gnu.org>
>
> Stefan Monnier wrote:
>
> >> There needs to be an agreed convention to mark trunk changes that should
> >> be backported to the release branch at some later date. "Remember to do
> >> it" doesn't scale.
> >
> > If it's really needed, we can have a "emacs-24-next" branch for that.
>
> I think it will be needed if: there are to be pure bug-fix releases, and
> pretesting is going to continue to take months, and development is going
> to continue at the same time. (There are probably tons of things fixed
> in trunk today that should go into version 24.5, if there is one. Who's
> going to dig them all out and backport them? No-one.)
>
> > Then we merge emacs-24 into emacs-24-next, and then we merge
> > emacs-24-next into trunk.
>
> Yet more branches sounds more complicated to me (doesn't that mean you
> need to know when you make a change where it should go?), but I don't
> care about the system so long as there is one.
I think using another (3rd) branch is on balance the most reliable and
least error prone method. It is also much less effort to merge
between branches than to cherry-pick.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Marking changes to be backported
2014-10-06 13:25 ` Stefan Monnier
@ 2014-10-06 15:16 ` Eli Zaretskii
2014-10-06 18:49 ` Glenn Morris
1 sibling, 0 replies; 18+ messages in thread
From: Eli Zaretskii @ 2014-10-06 15:16 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 06 Oct 2014 09:25:49 -0400
> Cc: Emacs developers <emacs-devel@gnu.org>
>
> > Yet more branches sounds more complicated to me (doesn't that mean you
> > need to know when you make a change where it should go?),
>
> One way or another, someone will have to decide which change goes "in
> the current pretest" (let's call it 24.4), "in the next bug-fix" (let's
> call it 24.5), or "longer term" (let's call it 25.1).
The dilemma is only between the 2 out of 3 branches, those that get
bugfixes. One of them should only get very safe fixes for serious
problems, which should then be merged to the other.
As for trunk vs the other 2 branches, I think the decision is simple:
new features and changes that don't fix bugs go to trunk only.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Marking changes to be backported
2014-10-06 13:25 ` Stefan Monnier
2014-10-06 15:16 ` Eli Zaretskii
@ 2014-10-06 18:49 ` Glenn Morris
2014-10-06 19:12 ` Stefan Monnier
1 sibling, 1 reply; 18+ messages in thread
From: Glenn Morris @ 2014-10-06 18:49 UTC (permalink / raw
To: Stefan Monnier; +Cc: Emacs developers
Stefan Monnier wrote:
> One way or another, someone will have to decide which change goes "in
> the current pretest" (let's call it 24.4), "in the next bug-fix" (let's
> call it 24.5), or "longer term" (let's call it 25.1).
I was hoping that this was something that everyone would think about,
not just a singular someone, and that's why I wanted there to be a
system in place.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Marking changes to be backported
2014-10-06 18:49 ` Glenn Morris
@ 2014-10-06 19:12 ` Stefan Monnier
0 siblings, 0 replies; 18+ messages in thread
From: Stefan Monnier @ 2014-10-06 19:12 UTC (permalink / raw
To: Glenn Morris; +Cc: Emacs developers
>> One way or another, someone will have to decide which change goes "in
>> the current pretest" (let's call it 24.4), "in the next bug-fix" (let's
>> call it 24.5), or "longer term" (let's call it 25.1).
> I was hoping that this was something that everyone would think about,
> not just a singular someone, and that's why I wanted there to be a
> system in place.
I hope so too: I meant "someone" per patch.
Stefan
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#18600: 24.3.94; EWW fails to check https certificates
2014-10-02 5:48 bug#18600: 24.3.94; EWW fails to check https certificates Mark H Weaver
2014-10-03 23:01 ` Glenn Morris
@ 2014-11-23 17:10 ` Lars Magne Ingebrigtsen
1 sibling, 0 replies; 18+ messages in thread
From: Lars Magne Ingebrigtsen @ 2014-11-23 17:10 UTC (permalink / raw
To: Mark H Weaver; +Cc: 18600
This has now been fixed on the trunk with the Network Security Manager
stuff.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2014-11-23 17:10 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-10-02 5:48 bug#18600: 24.3.94; EWW fails to check https certificates Mark H Weaver
2014-10-03 23:01 ` Glenn Morris
2014-10-03 23:44 ` Glenn Morris
2014-10-04 21:34 ` Ted Zlatanov
2014-10-04 23:24 ` Mark H Weaver
2014-10-05 2:00 ` Stefan Monnier
2014-10-05 2:38 ` Marking changes to be backported Glenn Morris
2014-10-05 16:46 ` Glenn Morris
2014-10-06 1:13 ` Stefan Monnier
2014-10-06 6:37 ` Glenn Morris
2014-10-06 13:25 ` Stefan Monnier
2014-10-06 15:16 ` Eli Zaretskii
2014-10-06 18:49 ` Glenn Morris
2014-10-06 19:12 ` Stefan Monnier
2014-10-06 15:09 ` Eli Zaretskii
2014-10-05 17:17 ` bug#18600: 24.3.94; EWW fails to check https certificates Mark H Weaver
2014-10-05 2:16 ` Glenn Morris
2014-11-23 17:10 ` Lars Magne Ingebrigtsen
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.