[OM Cooker] Trusted RPM packages
Jeff Johnson
n3npq at mac.com
Sat Jan 16 16:59:00 EST 2016
On Jan 15, 2016, at 5:14 PM, Jeff Johnson wrote:
> I'll write up a plan and post next few hours.
>
> (aside)
> Actually I just write for an hour but sent through a misconfigured mail server accidentally)
>
> 73 de Jeff
>
> On Fri, Jan 15, 2016 at 8:31 AM, Tomasz Gajc <tpgxyz at gmail.com> wrote:
> Hi,
>
> as we know after ABF breakdown, rpm packages signing are disabled in cooker - due to various problems. I'll check if this got magically fixed, but that is not a topic.
>
> Copule of weeks ago JBJ comes with an idea how to implement different trusinting mechanisms for rpm packages.
>
> Do we have a bluepronts for this anything more than idea ? It will have bad impact on release when comes to server to users errors about not verified rpm packages.
>
What was discussed is using the signature produced by every invocation of rpmbuild instead
of automatically signing packages with an "official" key as part of pushing packages to mirrors.
The benefits of using the non-repudiable signature from rpmbuild are these:
0) rpmbuild is already signing every package in every build, has been for years.
1) the "official" private key is not exposed on build systems, and a key compromise affects
one, not every, build.
2) the "official" public key does not need to be distributed and imported, the non-repudiable pubkey
is included in each package.
3) packages do not need be rewritten in order to insert the signature in the package, rpmbuild
adds the signature while writing the package.
4) false "BAD signature" reports from urpmi checking for "official" pubkey id's are eliminated.
Note that signing the final release with an "official" key is still recommended. The recommendation
to use the non-repudiable signature during cooker simplifies daily mirroring by replacing the fragile
complicated procedure of signing as part of daily mirroring.
The remaining concern/task switching to using the non-repudiable rpmbuild signature was/is in
identifying what content should be on mirrors. Currently any package not signed with the "official"
key should not be in mirrors. Using the existence of an "official" signature to detect whether mirror
content has been augmented with a trojan package can be handled in other ways, including
detecting missing packages.
The details of the non-repudiable signature are described online here:
http://cacr.uwaterloo.ca/hac/about/chap13.pdf
See section 13.8.2 "Non-repudiation and notarization of digital signatures" on page 587.
The two page description of a non-repudiable signature describes three compromise threats on p 588.
What was discussed a couple weeks back was mitigating the threats by "3. use of a trusted notary agent"
through the service available at
http://virtual-notary.org
One simple way to use the notary is to produce a flat file manifest listing package file names with
additional identification like file size, non-repudiable pubkey id, file digest/crc, etc. The manifest
can be signed to provide an additional level of protection. What a digital notary provides is
that the manifest existed in its current form at a known time/date/location.
The flat file manifest is published and registered with http://virtual-notary.org, which retrieves the document
and issues a certificate with the time/date and location (i.e. an ipaddr or FQDN) from which retrieved.
All of the packages/manifest are then published to mirrors. A careful end user can then ascertain
whether the mirror contains only "official" packages by downloading the manifest/certificate/packages,
verifying the certificate on the manifest and then verifying the additional package identification is
as described in the document. Finally the package signature can be verified, but rpm always does
that verification during install unless disabled.
What remains to be done (in some order) is this:
1) confirm the non-repudiable signature exists by building a package and verifying
the signature (using "rpm -qvvp *.rpm" should be sufficient), and that the pubkey is
contained within every package.
2) remove the check for "official" pubkey in urpmi.
3) create the manifest format to taste including additional identification like the non-repudiable pubkey id
4) register the manifest with http://virtual-notary.org and get the certificate. confirm that the certificate
is consistent with the document.
5) decide how to add the above steps to the mirroring process, and how to document the procedure.
Apologies for wordiness. Poke me on the irc meeting if you have questions.
hth
73 de Jeff
> Cheers.
>
> _______________________________________________
> OM-Cooker mailing list
> OM-Cooker at ml.openmandriva.org
> http://ml.openmandriva.org/mailman/listinfo/om-cooker_ml.openmandriva.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.openmandriva.org/pipermail/om-cooker_ml.openmandriva.org/attachments/20160116/68c31953/attachment-0001.html>
More information about the OM-Cooker
mailing list