[OM Cooker] Trusted RPM packages

Andreas Schneider dajudge61 at gmail.com
Sat Jan 16 19:07:29 EST 2016


..... the old Way ;)
why to discuss anymore? use it


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


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.openmandriva.org/pipermail/om-cooker_ml.openmandriva.org/attachments/20160117/4d8feeef/attachment.html>


More information about the OM-Cooker mailing list