[OM Cooker] Trusted RPM packages

Jeff Johnson n3npq at mac.com
Sun Jan 17 00:19:00 EST 2016


On Jan 16, 2016, at 7:07 PM, Andreas Schneider wrote:

> ..... the old Way ;)

Your vote is tallied.

The old way leads to reports of "BAD" or "INVALID" bug reports against packages in Cooker,
which is about to be repeated with the next beta because Cooker packages are not signed
with the "official" key.

That was the reason why TPG asking about a blueprint ...

> why to discuss anymore? use it
> 

Um, the discussion happened some weeks ago: I promised to supply a blueprint,
which I have done.

Do what you wish.

> 
> A Warning,
> again Adobe-Flash-Linux latest Version is leaky..... even on Linux risky !
> 

Presumably you mean leaky of security info, an entirely different issue than
cooker rpm package signatures.

File a bug report ... you know the drill.

73 de Jeff

> 
> regards
> 
> 
> 
> 2016-01-16 22:59 GMT+01:00 Jeff Johnson <n3npq at mac.com>:
> 
> 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
> 
> 
> _______________________________________________
> OM-Cooker mailing list
> OM-Cooker at ml.openmandriva.org
> http://ml.openmandriva.org/mailman/listinfo/om-cooker_ml.openmandriva.org
> 
> 
> _______________________________________________
> 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/20160117/f8335da7/attachment-0001.html>


More information about the OM-Cooker mailing list