[ggg2]

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.

[BuildTheRobots]

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.

[solatic]

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.

[ses1984]

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]

If by "origin" you mean "box Netflix has root on"... yes, I do think that?

[rhinoceraptor]

Netflix runs a fleet of their own CDN boxes, that they put in ISP data centers.

[eeZah7Ux]

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

[pwnna]

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

[isostatic]

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]

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]

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.