Hacker News Reader

Comment by _pmf_ | Hacker News Reader

What's baffling to me is that there's support for signing,, but no support for an encryption layer. When delivering software updates for embedded devices, I need to do both, so I have to roll my own container format. This seems to also be the case with package formats like ipkg/opkg, which are targeted for the embedded use case.

View on HN

Why not have a password-protected repository per client? If you need public dependencies, build them once and copy them to all repositories.

HTTP supports inline username and passwords, use HTTPS to keep the password encrypted on the wire: http://username:pass@server.tld/...

whats the use-case for an encryption layer?

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.

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

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?

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.

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.

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.

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...

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

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

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.

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

Personally I don't feel like the "hiding from the listener" use case discussed in the other response is very critical. What I think _pmf_ is getting at is an "only authorized devices may install my software, or view the RPMs".

You could accomplish this having a keypair on your field/embedded devices, and then having the RPM distribution system pull each devices public key from the keyserver, build the RPM with encryption specifically for this device, and then push it out. Or maybe you choose to have a generic keypair for a class of devices.

This could be used in cases where you have internal secrets in the RPMs you are building, or in the case of things like proprietary software and software licensing. I don't see how this applies to open source OS updates which is what I think the other sub-thread seems to be fixated on for some reason.

Whether this belongs in the RPM system itself or in a wrapper format, I'm not so sure of.

This is for embedded Linux devices with a set of proprietary applications (small volume commercial/industrial control, no consumer device). Mostly non networked, so we have to distribute application updates via USB (in the networked case, we a use VPNs separated by customer groups to deliver updates, so this layer provides the encryption without requiring the update archive to be encrypted).

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

Reply on news.ycombinator.com