[pkg-lynx-maint] [Lynx-dev] ANN: lynx2.8.9dev.7

[Axel Beckert]

Hi Thomas,

On Sat, Dec 19, 2015 at 01:57:19AM +0000, Thomas Dickey wrote:
> * set SSL_MODE_AUTO_RETRY in OpenSSL configuration, completing work needed for
>   Debian #707059 -TD
> * adopt some of the patches from Debian lynx package:
>   + add support for client certificates (patch by Simon Kainz, Debian #797901).
> * fix for gnutls logic to support rehandshake on negotiation for optional
>   client certificate, e.g., for https://contributors.debian.org (patch by
>   Simon Kainz, Debian #797059).
> * use gnutls_set_default_priority() to simplify algorithm priorities in the
>   gnutls configuration as well as track occassional changes in that library
>   (patch by Andreas Metzler, Debian #789189, Debian #784430).

I'm not sure which of the SSL-related changes above actually caused
this, but there seems a regression between lynx2.8.9dev.6 plus all the
original Debian patches above and lynx lynx2.8.9dev.7 with all Debian
patches removed which have been applied (and partially modified)
upstream -- both compiled against GnuTLS as before in Debian:

If I surf any HTTPS site by giving its URL as parameter on the
commandline, it works fine. But if I press enter on any link which
doesn't change to another server, I get this error message:

SSL error:The certificate is NOT trusted. The certificate issuer is unknown. -Continue? (n) 

I also verified that this message comes immediately if I connect to a
site with a self-signed SSL certificate. That still works.

It happened at least with "lynx https://www.phys.ethz.ch/" and then
selecting "Sitemap" and with "lynx https://duckduckgo.com/lite/" and
then searching for anything.

I planned to upload lynx2.8.9dev.7 tonight to Debian Unstable, but I
don't think it makes sense to do so with this regression. The current
state of the packaging in Debian can be seen in the master branch of
https://anonscm.debian.org/cgit/pkg-lynx/lynx-cur.git

P.S.: You seem to have signed Lynx releases with the GPG key
5DDF8FB7688E31A6 in the past, but this release is signed with
702353E0F7E48EDB. While 5DDF8FB7688E31A6 has a signature from
702353E0F7E48EDB, 702353E0F7E48EDB hasn't been signed (publically
known) by 5DDF8FB7688E31A6. It would be nice if the current key used
to sign releases is also signed by the key previously used for that.

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe at deuxchevaux.org  (Mail)
 X   See http://www.nonhtmlmail.org/campaign.html | abe at noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://abe.noone.org/ (Web)