netdata / netdata

Architected for speed. Automated for easy. Monitoring and troubleshooting, transformed!
https://www.netdata.cloud
GNU General Public License v3.0
71.33k stars 5.89k forks source link

[Bug]: https:// repos breaks on apt-cacher-ng setups #7905

Closed hvisage closed 1 year ago

hvisage commented 4 years ago
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///

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 2 years ago

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

Ferroin commented 1 year ago

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.