I wanted to make people aware of this: https://security.googleblog.com/2020/02/protecting-users-from-insecure_6.html tl;dr Google will soon start blocking insecure downloads from secure webpages, with the goal of eventually deprecating insecure downloads. This affects us, as e.g. the downloads we provide here https://gentoo.org/downloads/ would be blocked, as they provide iso/tar files over http - and also of course well, because it's insecure. (Warnings for tar/iso files would start with Chrome 83, blocks with 84, I expect other browser to implement similar measures going forward.) To avoid conflating this discussion with other things I think we need to separate two things: a) Downloads that we offer that are meant to be manually downloaded by users, like stage tarballs and iso images. b) Downloads that happen in an automated process, particularly distfiles, and that have separate security measures. I think discussing whether distfiles should be https is a separate discussion and also of less urgency. Primarily I think files that we offer for download where we expect that users download them with a browser should be moved to https, and if we don't browsers will start blocking those downloads.
(In reply to Hanno Böck from comment #0) > I wanted to make people aware of this: > https://security.googleblog.com/2020/02/protecting-users-from-insecure_6.html > > tl;dr Google will soon start blocking insecure downloads from secure > webpages, with the goal of eventually deprecating insecure downloads. > > This affects us, as e.g. the downloads we provide here > https://gentoo.org/downloads/ > would be blocked, as they provide iso/tar files over http - and also of > course well, because it's insecure. (Warnings for tar/iso files would start > with Chrome 83, blocks with 84, I expect other browser to implement similar > measures going forward.) > > To avoid conflating this discussion with other things I think we need to > separate two things: > a) Downloads that we offer that are meant to be manually downloaded by > users, like stage tarballs and iso images. > b) Downloads that happen in an automated process, particularly distfiles, > and that have separate security measures. > > I think discussing whether distfiles should be https is a separate > discussion and also of less urgency. Primarily I think files that we offer > for download where we expect that users download them with a browser should > be moved to https, and if we don't browsers will start blocking those > downloads. The real problem is we use a round-robin DNS for distfiles.gentoo.org not a redirector to the closest mirror. Because of this DNS, it CANNOT be https due to name matching. Some other method is required to be in place if any such action is to be done. Mirror policies may need updated as well as not all have https listed
Looks like our bouncer can do it as is. E.g. https://bouncer.gentoo.org/fetch/root/all/releases/amd64/autobuilds/20200205T214502Z/install-amd64-minimal-20200205T214502Z.iso
Created attachment 612594 [details, diff] bouncer-www.patch Proposed patch to use bouncer instead of distfiles for ISO and stage3
(In reply to Brian Evans from comment #3) > Created attachment 612594 [details, diff] [details, diff] > bouncer-www.patch > > Proposed patch to use bouncer instead of distfiles for ISO and stage3 Patch committed.
