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