11–20 of 57 posts
it doesn't explain anything! this is a indepth user guide, at most.
I know rpm is a cpio archive, with the files and some scripts, but the capabilities, when the scripts are run, etc I'm not sure of (I don't encounter rpms much - I'm a deb person, and I'm happy with my "ar -x" to explode my deb and look at the dependencies, conffiles, install/remove scripts, etc to install our custom packages on any rare centos servers we may need)
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.
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.
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.
it doesn't explain anything! this is a indepth user guide, at most.
Thanks, I won't bother I know rpm is a cpio archive, with the files and some scripts, but the capabilities, when the scripts are run, etc I'm not sure of (I don't encounter rpms much - I'm a deb person, and I'm happy with my "ar -x" to explode my deb and look at the dependencies, conffiles, install/remove scripts, etc to install our custom packages on any rare centos servers we may need)
To look at scripts/dependencies/etc you don't need to explode it at all, rpm has switches for querying that.
Earlier quoted context omitted.
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?
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.
Earlier quoted context omitted.
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 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.
RPM files are a compressed CPIO archive with some magic flags and an embedded key-value store.
When installed or uninstalled, rpms execute various arbitrary stages to manage changes to an operating system before, during, and after install or uninstall. So they introduce not only file changes (including changes to the system's RPM database and its index/lock), but also arbitrary system state changes. Fun!
RPM uses a global package database/index/lock to track what is installed and the dependencies. This can sometimes get corrupt, and then you may have to remove the lock and rebuild it.
(edit: this partly applies to yum) Dependency resolution is crap, because dependency resolution is not dependent on a merkle tree or a transaction log. It's more of a lame recursive DAG that cares more about "what does this system currently have and what can I find in the package repo", versus "what was this thing actually built with/for and does this make sense at all to install". Packages are pretty much never built with a "base operating system" kind of dependency resolution, so it's possible to install a package from a completely different distro/version that was based on the one you are using. If you're lucky you won't be able to install the wrong package because of the recursive dependencies, but not everyone is lucky, and not all packages are built properly. It's also possible to create recursive dependencies so an installed package cannot be uninstalled.
A .spec file defines what and how to build packages. A .srpm contains the source code to the application and the .spec file (handy!). A .rpm file is just one of potentially several packages that can result from building a .spec file, and the source can also be spread along multiple files. It's common for patches to be included in the .srpm and used at build time.
A package repository typically contains both compiled binary packages organized by architecture (.rpm) and source packages (.srpm). If you add or remove a package from a repository, you need to re-generate the metadata files that the repo uses to communicate changes to tools like yum, or yum will have no idea about what you added/removed.
RPM is actually fairly portable. A single .srpm file can build packages for Solaris, Windows, HP-UX, Linux, FreeBSD, etc. It can be a very good compliment to whatever the native packaging is, as long as you keep all packaged files in a unique file tree (like /opt/my_pkgs/).
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?
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 article goes into more detail of RPM: https://xyrillian.de/thoughts/posts/argh-pm.html
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.