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 <[email protected]> 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
> [email protected]
> http://ml.openmandriva.org/mailman/listinfo/om-cooker_ml.openmandriva.org
_______________________________________________
OM-Cooker mailing list
[email protected]
http://ml.openmandriva.org/mailman/listinfo/om-cooker_ml.openmandriva.org
