https:// repos breaks on apt-cacher-ng setups

[hvisage]

Bug report summary

In my environment, I've setup apt-cacher-ng for all my hosts, and any https:// repos are broken when not changing the urls to https://HTTPS///<repo_address>

OS / Environment

Linux proxws01 5.0.21-2-pve #1 SMP PVE 5.0.21-3 (Thu, 05 Sep 2019 13:56:01 +0200) x86_64 GNU/Linux
/etc/os-release:PRETTY_NAME="Debian GNU/Linux 10 (buster)"
/etc/os-release:NAME="Debian GNU/Linux"
/etc/os-release:VERSION_ID="10"
/etc/os-release:VERSION="10 (buster)"
/etc/os-release:VERSION_CODENAME=buster
/etc/os-release:ID=debian
/etc/os-release:HOME_URL="https://www.debian.org/"
/etc/os-release:SUPPORT_URL="https://www.debian.org/support"
/etc/os-release:BUG_REPORT_URL="https://bugs.debian.org/"

Netdata version

Current online installation script

Component Name

Installation scripts

Steps To Reproduce

1. setup apt-cacher-ng
2. configure apt cache to point to apt-cacher-ng proxy
3. run online instalaltion script: curl -s https://packagecloud.io/install/repositories/netdata/netdata/script.deb.sh | bash

Expected behavior

To install the repos to fetch from HTTP:// as the .deb, being already signed, doesn't need a secure download channel, especially when using apt-cacher-ng for caching packages inside closed/semi-closed environments.

[Ferroin]

This is an upstream issue with PackageCloud and should be taken up them, as we are not the people providing the script that is causing your issue.

Additionally, our packages are not currently signed (we plan to do this eventually, you can track the status of this in #7773), so it is recommended that at least for the upstream connection from your local mirror/apt-cacher instance you use HTTPS (not that PackageCloud appears to provide non-HTTPS access to their repositories).

[Ferroin]

I've sent an upstream report to PackageCloud, and will post here when there are any updates.

I'm also going to update our install documentation to indicate what's required to use PackageCloud with apt-cacher-ng.

[Ferroin]

Still have not heard back from PackageCloud on this. There's been some internal discussion of moving to self-hosting our own repos (though that's kind of stalled at the moment pending upcoming changes to how we handle binary packages) which will likely functionally resolve this.

[prologic]

Still have not heard back from PackageCloud on this. There's been some internal discussion of moving to self-hosting our own repos (though that's kind of stalled at the moment pending upcoming changes to how we handle binary packages) which will likely functionally resolve this.

Actually I don't think its terribly hard to do this even now. I might work on this after we fix all the bugs in our backlog!

[Ferroin]

Indeed, it should theoretically be doable now, it's just not currently top priority. It doesn't matter much for this issue though until we get #7773 dealt with, because we should still be enforcing HTTPS until we have signed packages to prevent trivial MitM attacks.

[prologic]

Yeah I actually built a repo with a really nice tool, HTTPS enabled and GPG signed. So I'll share this with you on Monday and we can implement it and start hosting our packages (behind Cloudflare) say say pkgs.netdata.cloud

[Ferroin]

We’re in the process of (finally) migrating to self-hosted package repositories, which will provide unencrypted HTTP access.

[Ferroin]

This should no longer be an issue, as our new self-hosted repositories are the default and they provide unencrypted HTTP access. Details on manual setup of these new repositories can be found in our documentation.