3 ms·

hiding packages you have installed from your ISP/NSA/etc. this discussion comes up time and time again (in rpm, apt et al). the consensus is: if you need that

by ggg2 7y ago

hiding packages you have installed from your ISP/NSA/etc. this discussion comes up time and time again (in rpm, apt et al). the consensus is: if you need that extra feature, manually download sensitive packages via ssl or something. everyone else (with nothing to hide, heh) keeps benefiting from a global cache of unencrypted transport of (mostly) open source data.

pwnna 7y ago
Does that help? I thought the package size is quite revealing.
- isostatic 7y ago
  In some cases (although the server could presumably send some random length data headers if that's a concern), but if you download multiple packages on a single connection can it still be tracked?
  - vetinari 7y ago
    The sizes of all packages are a known information. So if someone is dedicated enough to track your downloaded packages, figuring out which ones were transferred with a single connection is relatively simple integer programming task. If you want to really hide what you are installing, make a local mirror of the entire repo and then pick and choose from that.
    - scheveningen 7y ago
      I thought _pmf_ was describing packages that he authored, and certainly if the contents of them are confidential, they would be in a private repository. I don't think that the RPMs that I have created in my internal repository and deploy to my field systems are a 'known information' to anyone outside of my organization. If they are, I'm in serious trouble. I think a more realistic use case for package-level encryption is deploying RPMs that have secrets in them (either keys/creds in configuration or trade secrets in application logic). Ideally of course we should encapsulate these such that they aren't deployed to field/embedded devices but in embedded there certainly may be some use-cases and requirements that those of us used to working in data center and cloud computing aren't immediately thinking of.
      - deleted 7y ago
        [deleted]
BuildTheRobots 7y ago
Transport security & confidentiality makes sense (though at first I was trying to work out how an encrypted yum package would work). Yum with CentOS 6 and above does support SSL for mirror sites and a handful of global mirrors also support it (HEG being one). I suppose there's a slight race condition (eg how do I update the CA-Certificates bundle when I need the new CA-Certificates bundle to connect to the mirror site to download the update), however I tend to agree there should be some privacy as default.
ses1984 7y ago
You can cache things that are encrypted too, or do you think drm protected Netflix videos are all streamed from the origin? Yeah it's a bit more complicated...
- forgottenpass 7y ago
  If by "origin" you mean "box Netflix has root on"... yes, I do think that?
- rhinoceraptor 7y ago
  Netflix runs a fleet of their own CDN boxes, that they put in ISP data centers.
solatic 7y ago
As pwnna pointed out, package size gives you away. The real way to protect against this, if it's genuinely part of your threat model, is to maintain a complete local mirror: you can't tell what is installed and at what versions if you simply download everything. And if it's actually part of your threat model, then you likely have a large enough install base that you need a local mirror for performance/non-security reasons anyway. So it's really a non-issue.
eeZah7Ux 7y ago
The combination of IP addresses and package sizes is way too revealing. That's why APT supports Tor as a transport protocol.

by ggg2 7y ago

pwnna 7y ago

Does that help? I thought the package size is quite revealing.

isostatic 7y ago
In some cases (although the server could presumably send some random length data headers if that's a concern), but if you download multiple packages on a single connection can it still be tracked?
- vetinari 7y ago
  The sizes of all packages are a known information. So if someone is dedicated enough to track your downloaded packages, figuring out which ones were transferred with a single connection is relatively simple integer programming task. If you want to really hide what you are installing, make a local mirror of the entire repo and then pick and choose from that.
  - scheveningen 7y ago
    I thought _pmf_ was describing packages that he authored, and certainly if the contents of them are confidential, they would be in a private repository. I don't think that the RPMs that I have created in my internal repository and deploy to my field systems are a 'known information' to anyone outside of my organization. If they are, I'm in serious trouble. I think a more realistic use case for package-level encryption is deploying RPMs that have secrets in them (either keys/creds in configuration or trade secrets in application logic). Ideally of course we should encapsulate these such that they aren't deployed to field/embedded devices but in embedded there certainly may be some use-cases and requirements that those of us used to working in data center and cloud computing aren't immediately thinking of.
    - deleted 7y ago
      [deleted]

BuildTheRobots 7y ago

Transport security & confidentiality makes sense (though at first I was trying to work out how an encrypted yum package would work). Yum with CentOS 6 and above does support SSL for mirror sites and a handful of global mirrors also support it (HEG being one). I suppose there's a slight race condition (eg how do I update the CA-Certificates bundle when I need the new CA-Certificates bundle to connect to the mirror site to download the update), however I tend to agree there should be some privacy as default.

ses1984 7y ago

You can cache things that are encrypted too, or do you think drm protected Netflix videos are all streamed from the origin? Yeah it's a bit more complicated...

forgottenpass 7y ago
If by "origin" you mean "box Netflix has root on"... yes, I do think that?
rhinoceraptor 7y ago
Netflix runs a fleet of their own CDN boxes, that they put in ISP data centers.

solatic 7y ago

As pwnna pointed out, package size gives you away. The real way to protect against this, if it's genuinely part of your threat model, is to maintain a complete local mirror: you can't tell what is installed and at what versions if you simply download everything. And if it's actually part of your threat model, then you likely have a large enough install base that you need a local mirror for performance/non-security reasons anyway. So it's really a non-issue.

eeZah7Ux 7y ago

The combination of IP addresses and package sizes is way too revealing. That's why APT supports Tor as a transport protocol.