Live data from Hacker News

RPM Packages Explained

fedoramagazine.org

1–10 of 57 posts

Re: RPM Packages Explained

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

Re: RPM Packages Explained

#3
post #2

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.

whats the use-case for an encryption layer?

Re: RPM Packages Explained

#5
post #3
post #2

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.

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.

Re: RPM Packages Explained

#6
post #5
post #3

Earlier quoted context omitted.

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.

Re: RPM Packages Explained

#7
post #5
post #3

Earlier quoted context omitted.

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.

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.

Re: RPM Packages Explained

#10
post #6
post #5

Earlier quoted context omitted.

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?
Post reply on HN