[gentoo-project] RFC: Removing http:// mirror URLs where https:// is available

[gentoo-project] RFC: Removing http:// mirror URLs where https:// is available

[Joonas Niilola]

[-- Attachment #1.1: Type: text/plain, Size: 334 bytes --]

Hey,

First of all I'm asking because I don't know, but are there any
technical limitations why we should still be showing http:// mirrors
when https:// is available? I've just gone through multiple mirrors
listed in https://www.gentoo.org/downloads/mirrors/ and most of them
even redirect http requests to their https site.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-project] RFC: Removing http:// mirror URLs where https:// is available

[Alec Warner]

On Fri, Feb 12, 2021, 04:37 Joonas Niilola <juippis@gentoo.org> wrote:
>
> Hey,
>
> First of all I'm asking because I don't know, but are there any
> technical limitations why we should still be showing http:// mirrors
> when https:// is available? I've just gone through multiple mirrors
> listed in https://www.gentoo.org/downloads/mirrors/ and most of them
> even redirect http requests to their https site.
>

So my recollection is that on the install media, openssl has
USE=bindist[0] set, which prevents installation of EC TLS support. I
expect this to be resolved ..hopefully this year. The impact is that
on the installation media, you may not be able to talk to servers that
*only* offer EC-based TLS, as the openssl on the installation media
does not support EC-based TLS.

[0] Because patents, which may or may not be expired. See
http://bugs.gentoo.org/531540

Re: [gentoo-project] RFC: Removing http:// mirror URLs where https:// is available

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 2479 bytes --]

On 2021-02-13 18:32, Alec Warner wrote:
> So my recollection is that on the install media, openssl has
> USE=bindist[0] set, which prevents installation of EC TLS support. I
> expect this to be resolved ..hopefully this year. The impact is that
> on the installation media, you may not be able to talk to servers that
> *only* offer EC-based TLS, as the openssl on the installation media
> does not support EC-based TLS.

This was the reason why we added the hobble patch.

I just booted current install and admin CD and had no problems to do

> # wget -O /dev/null https://bouncer.gentoo.org/fetch/root/all/releases/amd64/autobuilds/20210210T214503Z/stage3-amd64-20210210T214503Z.tar.xz
> --2021-02-13 17:58:50--  https://bouncer.gentoo.org/fetch/root/all/releases/amd64/autobuilds/20210210T214503Z/stage3-amd64-20210210T214503Z.tar.xz
> Resolving bouncer.gentoo.org... 2001:470:ea4a:1:a800:ff:fe73:2f93, 140.211.166.176
> Connecting to bouncer.gentoo.org|2001:470:ea4a:1:a800:ff:fe73:2f93|:443... connected.
> HTTP request sent, awaiting response... 302 Found
> Location: https://mirror.init7.net/gentoo//releases/amd64/autobuilds/20210210T214503Z/stage3-amd64-20210210T214503Z.tar.xz [following]

and

> # wget -O /dev/null https://distfiles.gentoo.org/distfiles/2002a.tar.gz
> --2021-02-13 18:00:04--  https://distfiles.gentoo.org/distfiles/2002a.tar.gz
> Resolving distfiles.gentoo.org... 2a02:6ea0:c700::1, 2a02:6ea0:c700::3, 2a02:6ea0:c700::2, ...
> Connecting to distfiles.gentoo.org|2a02:6ea0:c700::1|:443... connected.

Even `curl https://www.gentoo.org/` works ;-)


So I would ask differently: What's the motivation behind removing HTTP 
URLs? From security POV (file integrity) it doesn't matter for Gentoo 
because of Manifests. Regarding privacy improvement we would have to 
require TLS 1.3 mirrors only which will not gonna happen.

Unless there are reasons I am not aware of I would keep status quo. Keep 
in mind: There are still use cases where you need HTTP (broken TLS stack 
for example). Uncommon but they exist.

We maybe should promote HTTPS mirrors, update tooling 
(app-portage/mirrorselect) to prefer HTTPS mirrors at all but I wouldn't 
remove/hide them (maybe we will end up promoting distfiles.gentoo.org 
only in future since it became a CDN mirror like cdn-fastly.deb.debian.org).


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [gentoo-project] RFC: Removing http:// mirror URLs where https:// is available

[Hans de Graaff]

[-- Attachment #1: Type: text/plain, Size: 709 bytes --]

On Fri, 2021-02-12 at 14:37 +0200, Joonas Niilola wrote:
> Hey,
> 
> First of all I'm asking because I don't know, but are there any
> technical limitations why we should still be showing http:// mirrors
> when https:// is available? I've just gone through multiple mirrors
> listed in https://www.gentoo.org/downloads/mirrors/ and most of them
> even redirect http requests to their https site.

It might be useful to keep actual http mirrors for cases where TLS
isn't possible for some reason, but any mirror that just redirects http
to https wouldn't fall in that category and there the http version
could be removed since the only benefit of http (no TLS) is not
actually available.

Hans

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[gentoo-project] Re: RFC: Removing http:// mirror URLs where https:// is available

[Toralf Förster]

[-- Attachment #1.1: Type: text/plain, Size: 535 bytes --]

On 2/12/21 1:37 PM, Joonas Niilola wrote:
> Hey,
> 
> First of all I'm asking because I don't know, but are there any
> technical limitations why we should still be showing http:// mirrors
> when https:// is available? I've just gone through multiple mirrors
> listed in https://www.gentoo.org/downloads/mirrors/ and most of them
> even redirect http requests to their https site.
> 
It would be nice if at least the notification mails from the forums 
would obly present https://.


-- 
Toralf
PGP 23217DA7 9B888F45


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [gentoo-project] RFC: Removing http:// mirror URLs where https:// is available

[Joonas Niilola]

[-- Attachment #1.1: Type: text/plain, Size: 1248 bytes --]



On 2/13/21 8:16 PM, Thomas Deutschmann wrote:
>
> So I would ask differently: What's the motivation behind removing HTTP
> URLs? From security POV (file integrity) it doesn't matter for Gentoo
> because of Manifests. Regarding privacy improvement we would have to
> require TLS 1.3 mirrors only which will not gonna happen.
>
> Unless there are reasons I am not aware of I would keep status quo.
> Keep in mind: There are still use cases where you need HTTP (broken
> TLS stack for example). Uncommon but they exist.

Hey,

I just saw something that made me wonder, and decided to ask from people
wiser than me. I guess my rationale was promoting https where available,
and remove "duplication". The whole web seems to be moving towards
secured connections.

Anyway I'm not pursuing this one way or another, but I would've been
willing to do the cleaning if there was an agreement for it.

>
> We maybe should promote HTTPS mirrors, update tooling
> (app-portage/mirrorselect) to prefer HTTPS mirrors at all but I
> wouldn't remove/hide them (maybe we will end up promoting
> distfiles.gentoo.org only in future since it became a CDN mirror like
> cdn-fastly.deb.debian.org).
>
>
This sounds good.

-- juippis


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-project] RFC: Removing http:// mirror URLs where https:// is available

[Joonas Niilola]

[-- Attachment #1.1: Type: text/plain, Size: 571 bytes --]



On 2/14/21 11:12 AM, Hans de Graaff wrote:
> It might be useful to keep actual http mirrors for cases where TLS
> isn't possible for some reason, but any mirror that just redirects http
> to https wouldn't fall in that category and there the http version
> could be removed since the only benefit of http (no TLS) is not
> actually available.
>
> Hans
Hey,

This was also suggested in IRC and sounds reasonable to me. It would've
been a lot easier and faster to go through "duplicated" http(s) URLs,
but this shouldn't be too bad either.

-- juippis


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]