GNU bug report logs - #16791
w3m fails to do any SSL certificate checking

Previous Next

Package: guix;

Reported by: Mark H Weaver <mhw <at> netris.org>

Date: Tue, 18 Feb 2014 09:00:03 UTC

Severity: serious

Done: Leo Famulari <leo <at> famulari.name>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16791 in the body.
You can then email your comments to 16791 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guix <at> gnu.org:
bug#16791; Package guix. (Tue, 18 Feb 2014 09:00:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Mark H Weaver <mhw <at> netris.org>:
New bug report received and forwarded. Copy sent to bug-guix <at> gnu.org. (Tue, 18 Feb 2014 09:00:05 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: bug-guix <at> gnu.org
Subject: w3m fails to do any SSL certificate checking
Date: Tue, 18 Feb 2014 03:58:21 -0500
In Guix, neither w3m nor emacs-w3m warn me when I visit an https URL
that uses a server certificate that is both self-signed and expired.
To make matters worse, if I ask for page information (with the '=' key),
it tells me that the certificate is valid.

On Debian, both w3m and emacs-w3m inform me when an SSL certificate is
invalid in some way, e.g. if it's expired or not signed by a certificate
authority in my trust store.

      Mark




Information forwarded to bug-guix <at> gnu.org:
bug#16791; Package guix. (Tue, 18 Feb 2014 19:24:04 GMT) Full text and rfc822 format available.

Message #8 received at 16791 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Enge <andreas <at> enge.fr>
To: Mark H Weaver <mhw <at> netris.org>
Cc: 16791 <at> debbugs.gnu.org
Subject: Re: bug#16791: w3m fails to do any SSL certificate checking
Date: Tue, 18 Feb 2014 20:23:00 +0100
[Message part 1 (text/plain, inline)]
On Tue, Feb 18, 2014 at 03:58:21AM -0500, Mark H Weaver wrote:
> In Guix, neither w3m nor emacs-w3m warn me when I visit an https URL
> that uses a server certificate that is both self-signed and expired.
> To make matters worse, if I ask for page information (with the '=' key),
> it tells me that the certificate is valid.
> 
> On Debian, both w3m and emacs-w3m inform me when an SSL certificate is
> invalid in some way, e.g. if it's expired or not signed by a certificate
> authority in my trust store.

w3m can be configured to not verify ssl certificates; but this is not the
case for us. I checked that if the server presents a certificate for a
different domain, there is a message:
   Bad cert ident xxx from yyy: accept? (y/n)

However, the debian w3m asks whether a self-signed certificate should be
accepted. Among the about 30 patches in debian for w3m, the name of only one
is related to ssl; I am attaching it, but it does not seem related to our
problem.

Andreas

[260_openssl.patch (text/plain, attachment)]

Information forwarded to bug-guix <at> gnu.org:
bug#16791; Package guix. (Tue, 18 Feb 2014 19:34:01 GMT) Full text and rfc822 format available.

Message #11 received at 16791 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Enge <andreas <at> enge.fr>
To: Mark H Weaver <mhw <at> netris.org>
Cc: 16791 <at> debbugs.gnu.org
Subject: Re: bug#16791: w3m fails to do any SSL certificate checking
Date: Tue, 18 Feb 2014 20:32:44 +0100
I wondered whether the problem lied in our openssl. It does not seem so.
"openssl verify cert.pem" on my problematic certificate does print as expected:
  error 18 at 0 depth lookup:self signed certificate
  error 10 at 0 depth lookup:certificate has expired

Andreas





Severity set to 'serious' from 'normal' Request was from Mark H Weaver <mhw <at> netris.org> to control <at> debbugs.gnu.org. (Sun, 16 Mar 2014 19:42:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-guix <at> gnu.org:
bug#16791; Package guix. (Sun, 03 Jan 2016 02:21:02 GMT) Full text and rfc822 format available.

Message #16 received at 16791 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: 16791 <at> debbugs.gnu.org
Subject: Re: w3m fails to do any SSL certificate checking
Date: Sat, 2 Jan 2016 21:20:30 -0500
I looked into how Debian does it. They bundle a configuration file that
sets the correct options.

If you download the "debian" file [0], which includes all of their
packaging for w3m, you can view the file at 'debian/w3mconfig'.

The relevant option is "ssl_verify_server", and it must be set to "1" in
order for w3m to perform verification.

Example with a domain whose certificate is expired:
$ w3m -o ssl_verify_server 1 fmrl.me

Do we ever bundle configuration files in this manner?

Can a wrapper set command-line variables?

I will investigate whether these options can be set at build time.

I don't think we should ship a browser in this state, even if users are
able to configure it properly after installation. w3m is used by other
programs like mutt to render html "under the hood".

[0]
http://http.debian.net/debian/pool/main/w/w3m/w3m_0.5.3-26.debian.tar.xz




Information forwarded to bug-guix <at> gnu.org:
bug#16791; Package guix. (Mon, 04 Jan 2016 06:20:02 GMT) Full text and rfc822 format available.

Message #19 received at 16791 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: 16791 <at> debbugs.gnu.org
Subject: Re: bug#16791: w3m fails to do any SSL certificate checking
Date: Mon, 4 Jan 2016 01:19:32 -0500
On Sat, Jan 02, 2016 at 09:20:30PM -0500, Leo Famulari wrote:
> I looked into how Debian does it. They bundle a configuration file that
> sets the correct options.
> 
> If you download the "debian" file [0], which includes all of their
> packaging for w3m, you can view the file at 'debian/w3mconfig'.
> 
> The relevant option is "ssl_verify_server", and it must be set to "1" in
> order for w3m to perform verification.
> 
> Example with a domain whose certificate is expired:
> $ w3m -o ssl_verify_server 1 fmrl.me
> 
> Do we ever bundle configuration files in this manner?
> 
> Can a wrapper set command-line variables?
> 
> I will investigate whether these options can be set at build time.
> 
> I don't think we should ship a browser in this state, even if users are
> able to configure it properly after installation. w3m is used by other
> programs like mutt to render html "under the hood".
> 
> [0]
> http://http.debian.net/debian/pool/main/w/w3m/w3m_0.5.3-26.debian.tar.xz
> 

This particular issue was resolved in October 2014 in this commit
(tested):
http://anonscm.debian.org/cgit/collab-maint/w3m.git/commit/?id=05503271dfd26b843589dece0da35ba5d7d38654

It looks like there is a lot of development activity happening within
Debian, beyond simple packaging [0]. Even what seems to be the official
SourceForge page seems to be tracking the Debian work [1].

The Debian developers are regularly issuing release tags but not release
tarballs. I built from the latest one and it seems to work.

I think we should use the Debian repo as the source for our w3m package.
What does everyone else think?

[0]
http://anonscm.debian.org/cgit/collab-maint/w3m.git/

[1]
http://sourceforge.net/p/w3m/patches/71/




Information forwarded to bug-guix <at> gnu.org:
bug#16791; Package guix. (Mon, 04 Jan 2016 19:13:02 GMT) Full text and rfc822 format available.

Message #22 received at 16791 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: 16791 <at> debbugs.gnu.org
Subject: Re: bug#16791: w3m fails to do any SSL certificate checking
Date: Mon, 4 Jan 2016 14:12:04 -0500
On Mon, Jan 04, 2016 at 01:19:32AM -0500, Leo Famulari wrote:
> On Sat, Jan 02, 2016 at 09:20:30PM -0500, Leo Famulari wrote:
> > I looked into how Debian does it. They bundle a configuration file that
> > sets the correct options.
> > 
> > If you download the "debian" file [0], which includes all of their
> > packaging for w3m, you can view the file at 'debian/w3mconfig'.
> > 
> > The relevant option is "ssl_verify_server", and it must be set to "1" in
> > order for w3m to perform verification.
> > 
> > Example with a domain whose certificate is expired:
> > $ w3m -o ssl_verify_server 1 fmrl.me
> > 
> > Do we ever bundle configuration files in this manner?
> > 
> > Can a wrapper set command-line variables?
> > 
> > I will investigate whether these options can be set at build time.
> > 
> > I don't think we should ship a browser in this state, even if users are
> > able to configure it properly after installation. w3m is used by other
> > programs like mutt to render html "under the hood".
> > 
> > [0]
> > http://http.debian.net/debian/pool/main/w/w3m/w3m_0.5.3-26.debian.tar.xz
> > 
> 
> This particular issue was resolved in October 2014 in this commit
> (tested):
> http://anonscm.debian.org/cgit/collab-maint/w3m.git/commit/?id=05503271dfd26b843589dece0da35ba5d7d38654
> 
> It looks like there is a lot of development activity happening within
> Debian, beyond simple packaging [0]. Even what seems to be the official
> SourceForge page seems to be tracking the Debian work [1].
> 
> The Debian developers are regularly issuing release tags but not release
> tarballs. I built from the latest one and it seems to work.
> 
> I think we should use the Debian repo as the source for our w3m package.
> What does everyone else think?

I wanted to "tighten" w3m's SSL configuration in general, and found that
the Debian developers have already disabled SSLv2 and SSLv3 [0] and some
insecure ciphers [1].

[0]
http://anonscm.debian.org/cgit/collab-maint/w3m.git/commit/?id=05503271dfd26b843589dece0da35ba5d7d38654
http://anonscm.debian.org/cgit/collab-maint/w3m.git/commit/?id=1aace42d026c7df31c4762ef1095ce83450916fc

[1]
http://anonscm.debian.org/cgit/collab-maint/w3m.git/commit/?id=3335b5e824eecf70055af985b12c60651787fbfc

> 
> [0]
> http://anonscm.debian.org/cgit/collab-maint/w3m.git/
> 
> [1]
> http://sourceforge.net/p/w3m/patches/71/
> 
> 
> 




Information forwarded to bug-guix <at> gnu.org:
bug#16791; Package guix. (Mon, 04 Jan 2016 23:37:01 GMT) Full text and rfc822 format available.

Message #25 received at 16791 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Leo Famulari <leo <at> famulari.name>
Cc: 16791 <at> debbugs.gnu.org
Subject: Re: bug#16791: w3m fails to do any SSL certificate checking
Date: Tue, 05 Jan 2016 00:35:57 +0100
Leo Famulari <leo <at> famulari.name> skribis:

> On Sat, Jan 02, 2016 at 09:20:30PM -0500, Leo Famulari wrote:
>> I looked into how Debian does it. They bundle a configuration file that
>> sets the correct options.
>> 
>> If you download the "debian" file [0], which includes all of their
>> packaging for w3m, you can view the file at 'debian/w3mconfig'.
>> 
>> The relevant option is "ssl_verify_server", and it must be set to "1" in
>> order for w3m to perform verification.
>> 
>> Example with a domain whose certificate is expired:
>> $ w3m -o ssl_verify_server 1 fmrl.me
>> 
>> Do we ever bundle configuration files in this manner?
>> 
>> Can a wrapper set command-line variables?
>> 
>> I will investigate whether these options can be set at build time.
>> 
>> I don't think we should ship a browser in this state, even if users are
>> able to configure it properly after installation. w3m is used by other
>> programs like mutt to render html "under the hood".
>> 
>> [0]
>> http://http.debian.net/debian/pool/main/w/w3m/w3m_0.5.3-26.debian.tar.xz
>> 
>
> This particular issue was resolved in October 2014 in this commit
> (tested):
> http://anonscm.debian.org/cgit/collab-maint/w3m.git/commit/?id=05503271dfd26b843589dece0da35ba5d7d38654

Looks like applying this patch would fix the bug right away, right?

> It looks like there is a lot of development activity happening within
> Debian, beyond simple packaging [0]. Even what seems to be the official
> SourceForge page seems to be tracking the Debian work [1].
>
> The Debian developers are regularly issuing release tags but not release
> tarballs. I built from the latest one and it seems to work.
>
> I think we should use the Debian repo as the source for our w3m package.
> What does everyone else think?

Unless upstream is really dead, we should track it.  I think it’s not
the distro’s job to do non-trivial development.

What about using the latest upstream tarball, along with the patch
above and probably the one that disables SSLv{2,3}?

Thanks,
Ludo’.




Information forwarded to bug-guix <at> gnu.org:
bug#16791; Package guix. (Tue, 05 Jan 2016 16:33:02 GMT) Full text and rfc822 format available.

Message #28 received at 16791 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 16791 <at> debbugs.gnu.org
Subject: Re: bug#16791: w3m fails to do any SSL certificate checking
Date: Tue, 5 Jan 2016 11:32:14 -0500
On Tue, Jan 05, 2016 at 12:35:57AM +0100, Ludovic Courtès wrote:
> Leo Famulari <leo <at> famulari.name> skribis:
> 
> > On Sat, Jan 02, 2016 at 09:20:30PM -0500, Leo Famulari wrote:
> >> I looked into how Debian does it. They bundle a configuration file that
> >> sets the correct options.
> >> 
> >> If you download the "debian" file [0], which includes all of their
> >> packaging for w3m, you can view the file at 'debian/w3mconfig'.
> >> 
> >> The relevant option is "ssl_verify_server", and it must be set to "1" in
> >> order for w3m to perform verification.
> >> 
> >> Example with a domain whose certificate is expired:
> >> $ w3m -o ssl_verify_server 1 fmrl.me
> >> 
> >> Do we ever bundle configuration files in this manner?
> >> 
> >> Can a wrapper set command-line variables?
> >> 
> >> I will investigate whether these options can be set at build time.
> >> 
> >> I don't think we should ship a browser in this state, even if users are
> >> able to configure it properly after installation. w3m is used by other
> >> programs like mutt to render html "under the hood".
> >> 
> >> [0]
> >> http://http.debian.net/debian/pool/main/w/w3m/w3m_0.5.3-26.debian.tar.xz
> >> 
> >
> > This particular issue was resolved in October 2014 in this commit
> > (tested):
> > http://anonscm.debian.org/cgit/collab-maint/w3m.git/commit/?id=05503271dfd26b843589dece0da35ba5d7d38654
> 
> Looks like applying this patch would fix the bug right away, right?
> 
> > It looks like there is a lot of development activity happening within
> > Debian, beyond simple packaging [0]. Even what seems to be the official
> > SourceForge page seems to be tracking the Debian work [1].
> >
> > The Debian developers are regularly issuing release tags but not release
> > tarballs. I built from the latest one and it seems to work.
> >
> > I think we should use the Debian repo as the source for our w3m package.
> > What does everyone else think?
> 
> Unless upstream is really dead, we should track it.  I think it’s not
> the distro’s job to do non-trivial development.

I'm trying to reach the people that used to work on w3m to ask if they
are still active or if they have abandoned it. They haven't been around
in ~4 years from what I have seen.

> 
> What about using the latest upstream tarball, along with the patch
> above and probably the one that disables SSLv{2,3}?

I'll try that.

> 
> Thanks,
> Ludo’.




Information forwarded to bug-guix <at> gnu.org:
bug#16791; Package guix. (Fri, 08 Jan 2016 04:56:01 GMT) Full text and rfc822 format available.

Message #31 received at 16791 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: mhw <at> netris.org, 16791 <at> debbugs.gnu.org
Subject: Re: bug#16791: w3m fails to do any SSL certificate checking
Date: Thu, 7 Jan 2016 23:55:12 -0500
On Tue, Jan 05, 2016 at 11:32:14AM -0500, Leo Famulari wrote:
> On Tue, Jan 05, 2016 at 12:35:57AM +0100, Ludovic Courtès wrote:
> > Leo Famulari <leo <at> famulari.name> skribis:
> > 
> > > On Sat, Jan 02, 2016 at 09:20:30PM -0500, Leo Famulari wrote:
> > >> I looked into how Debian does it. They bundle a configuration file that
> > >> sets the correct options.
> > >> 
> > >> If you download the "debian" file [0], which includes all of their
> > >> packaging for w3m, you can view the file at 'debian/w3mconfig'.
> > >> 
> > >> The relevant option is "ssl_verify_server", and it must be set to "1" in
> > >> order for w3m to perform verification.
> > >> 
> > >> Example with a domain whose certificate is expired:
> > >> $ w3m -o ssl_verify_server 1 fmrl.me
> > >> 
> > >> Do we ever bundle configuration files in this manner?
> > >> 
> > >> Can a wrapper set command-line variables?
> > >> 
> > >> I will investigate whether these options can be set at build time.
> > >> 
> > >> I don't think we should ship a browser in this state, even if users are
> > >> able to configure it properly after installation. w3m is used by other
> > >> programs like mutt to render html "under the hood".
> > >> 
> > >> [0]
> > >> http://http.debian.net/debian/pool/main/w/w3m/w3m_0.5.3-26.debian.tar.xz
> > >> 
> > >
> > > This particular issue was resolved in October 2014 in this commit
> > > (tested):
> > > http://anonscm.debian.org/cgit/collab-maint/w3m.git/commit/?id=05503271dfd26b843589dece0da35ba5d7d38654
> > 
> > Looks like applying this patch would fix the bug right away, right?
> > 
> > > It looks like there is a lot of development activity happening within
> > > Debian, beyond simple packaging [0]. Even what seems to be the official
> > > SourceForge page seems to be tracking the Debian work [1].
> > >
> > > The Debian developers are regularly issuing release tags but not release
> > > tarballs. I built from the latest one and it seems to work.
> > >
> > > I think we should use the Debian repo as the source for our w3m package.
> > > What does everyone else think?
> > 
> > Unless upstream is really dead, we should track it.  I think it’s not
> > the distro’s job to do non-trivial development.
> 
> I'm trying to reach the people that used to work on w3m to ask if they
> are still active or if they have abandoned it. They haven't been around
> in ~4 years from what I have seen.
> 
> > 
> > What about using the latest upstream tarball, along with the patch
> > above and probably the one that disables SSLv{2,3}?
> 
> I'll try that.

Mark, can you check if commit 62339e2d49 fixes this bug for you?

> 
> > 
> > Thanks,
> > Ludo’.
> 
> 
> 




Reply sent to Leo Famulari <leo <at> famulari.name>:
You have taken responsibility. (Wed, 10 Feb 2016 21:17:02 GMT) Full text and rfc822 format available.

Notification sent to Mark H Weaver <mhw <at> netris.org>:
bug acknowledged by developer. (Wed, 10 Feb 2016 21:17:02 GMT) Full text and rfc822 format available.

Message #36 received at 16791-done <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: 16791-done <at> debbugs.gnu.org
Subject: Re: bug#16791: w3m fails to do any SSL certificate checking
Date: Wed, 10 Feb 2016 16:16:41 -0500
On Thu, Jan 07, 2016 at 11:55:12PM -0500, Leo Famulari wrote:
> On Tue, Jan 05, 2016 at 11:32:14AM -0500, Leo Famulari wrote:
> > On Tue, Jan 05, 2016 at 12:35:57AM +0100, Ludovic Courtès wrote:

[...]

> > > What about using the latest upstream tarball, along with the patch
> > > above and probably the one that disables SSLv{2,3}?
> > 
> > I'll try that.
> 
> Mark, can you check if commit 62339e2d49 fixes this bug for you?

I believe this bug is fixed. Please re-open if that is not the case.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 10 Mar 2016 12:24:03 GMT) Full text and rfc822 format available.

This bug report was last modified 8 years and 20 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.