[pkg-lynx-maint] Bug#991971: Bug#991971: [CVE-2021-38165] lynx: bug in SSL certificate validation -> leaks password in clear text via SNI (under some circumstances)

[Axel Beckert]

Hi Andreas,

Andreas Metzler wrote:
> > > tags 991971 fixed-upstream
> > Bug #991971 [lynx] lynx: SSL certificate validation fails with URLs containing user name or user name and password, i.e. https://user:password@host/ and https://user@host/; leaks password in clear text via SNI
> > Added tag(s) fixed-upstream.
> 
> Hello,
> 
> I have just uploaded .9 to experimental.

Thanks a lot! Went to bed in the morning last night, so I was really
happy to see at least Experimental already being fixed when I woke up
again.

> The deadline for bulleye unblock requests has passed, so we will
> need to fix this by security/point release.

Hrm, right, thanks for the reminder.

I nevertheless will update Unstable with a fix. It might be helpful
for the Security Team (Cc'ed) or us to prepare a stable-update for
Bullseye.

Security Team: Do you think the fix for CVE-2021-38165 should get a
DSA? Or do you think it's not important enough and we should target a
minor stable update for it?

> @Fellow lynx-maintainers: Do you have a preferred branch name for
> bullseye? I would go for "11_bullseye".

I'd just have said "bullseye" to keep things simple. But "11_bullseye"
isn't really bad either. At least the stable fix branches then would
be properly ordered. (I don't see much other gain from the "11_" in
front, though.)

The other option which came to my mind was "debian/bullseye" which I
thought would be according to DEP14, but then I noticed that it would
have to be "debian/bullseye-security" or "debian/bullseye-updates"
*sigh* according to DEP14.

But I must admit that I'm anything but a fan of DEP14. So I'll use
"11_bullseye".

Then again, this opens the question if I should put that upload to
Unstable into the 11_bullseye branch despite the later stable or
security update will not be a direct successor of that upload, at
least not in the debian/changelog. Meh. But then again, nothing speaks
against making it a predecessor in git only, i.e. just rewriting the
debian/changelog entry with the entry for the stable or security
update as the remainder will be the same anyways. And in the worst
case we can always rename branches or rewrite history in git. :-P

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe at debian.org>, https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-lynx-maint/attachments/20210808/c5435217/attachment-0001.sig>