Where is it documented how the data in a RPM is laid out? What data is signed in a signed RPM?
The reason I ask this question is the following:
In keeping with the original UNIX "many small tools" philosophy, imagine the following 2 utilities:
rpmdetachsig:
Takes a rpm together with the gpg keys and a passphrase from user it goes through the exact same procedure as "rpm --addsign" goes through but instead of creating a signed rpm, creates a DETACHED signature for the rpm's data. The detached signature is output to a separate file.
rpmadddetachedsig: takes an rpm together with the detached signature produced by rpmdetachsig, and creates another rpm but signed, just like it had been signed by "rpm --addsign" in one operation.
Using these utilities, the buildservice could implement the following procedure for developers that want to sign their rpms:
Developers download their rpm and use rpmdetachsig to create a detached signature. They then upload the detached signature back to the build service. The Build service adds the developer's detached signature to the published rpm (with rpmadddetachedsig). The build service also adds its own signature to the rpm to indicate that the rpm was indeed built with the data on the build service.
This procedure (if possible) has the following advantages:
The developers never have to trust the build service with their secret keys, because the signature creation is done on the developer's own computer. This is important because many people are unwilling to trust anyone else with their secret key--properly so.
The Build service knows that the data it publishes was built on the build server! It accepted the detached signature from the developer but the rpm on the build service never left the custody of the build service!
On Wed, Oct 31, 2007 at 06:30:51PM -0500, Paul Elliott wrote:
Where is it documented how the data in a RPM is laid out?
A rpm consists of four parts: 1) rpm lead, i.e. magic and the like (96 bytes) 2) signature header, containing all signatures 3) package header, i.e. name, version, dependencies, ... 4) payload, i.e. compressed cpio archive
What data is signed in a signed RPM?
Depends on the signature, either package header + payload or just the package header. rpm --addsign normally adds two signatures, one for just the package header and one for both the header and the payload.
[...] Using these utilities, the buildservice could implement the following procedure for developers that want to sign their rpms:
Developers download their rpm and use rpmdetachsig to create a detached signature.
You actually just need the header/header+payload hash for signing purposes, there's no need to download the complete rpm.
They then upload the detached signature back to the build service. The Build service adds the developer's detached signature to the published rpm (with rpmadddetachedsig).
Hmm, I'm not sure that the rpms should be published at all if they don't have their right signature.
The build service also adds its own signature to the rpm to indicate that the rpm was indeed built with the data on the build service.
This procedure (if possible) has the following advantages:
The developers never have to trust the build service with their secret keys, because the signature creation is done on the developer's own computer. This is important because many people are unwilling to trust anyone else with their secret key--properly so.
The Build service knows that the data it publishes was built on the build server! It accepted the detached signature from the developer but the rpm on the build service never left the custody of the build service!
Yep, that's more or less what we're planning to do.
(And it's also how the 'sign' tool works that is distributed with the build service code, it calculates the hash and sends it to the sign server. The sign server sends back the signature and the sign utility puts the signature in the rpm.)
Cheers, Michael.
buildservice@lists.opensuse.org
-
Michael Schroeder -
Paul Elliott