Jeff thanks for your explanation. I have feeling i've understood it like this way, so please confirm:
1. Before release and repository freeze a list of gpg keys needs to be generated from each rpm file in repository 2. This list must be uploaded to virtual-notary.org 3. List is signed by virtual-notary 4. List is placed on repository with a public certificate from virtual-notary 5. Done BTW: idea is very interesting :) I have a couple of questions/ideas: 1. Would be nice if urpmi could verify a gpg key from a signed list taken from mirror. 2. What about /updates directory on mirror? This directory is not frozen after release, so this means new packages will be arriving there. How to handle these packages with above solution ? IMHO recreating list each rpm got published and then upload it to virtual-notary and generate new certificate is a big effort. I wonder how virtual-notary will react if we will upload couple of lists per day. Maybe update 1 time per day ? You know, user can install update just couple a seconds just after it got published on repository. 3. Is there any API for virtual-notary.org ? 2016-01-18 12:43 GMT+01:00 Jeff Johnson <[email protected]>: > > On Jan 18, 2016, at 5:56 AM, Jeff Johnson wrote: > > >> > >> I do not understand what non-repudiable means :( > >> > > > > Apologies for the techno jargon (but I am reluctant to invent newer! > better! bestest! terms) > > > > A repudiation is a statement denying some claim like this: > > Q: Did you modify anything in the package? > > A: No. > > > > So a non-repudiable signature is a public/global assertion that nothing > whatsoever is changed. > > Here is perhaps a better (i.e. more explicit) example of repudiation(s): > > Claim: My machine was rooted by installing a > *Mandriva rpm package from this mirror. > Repudiation #1: That package wasn't downloaded from this mirror. > Repudiation #2: That is not a *Mandriva package because its not > signed with a Mandriva key. > Repudiation #3: That is not a package produced by rpm because > (various reasons, like the > package might have been altered after being built). > > By including a non-repudiable signature, #3 provides a > stronger/transparent mechanism that a > package was not altered after being built. > > By registering a manifest with virtual-notary, *Mandriva would be > providing some means to resolve > the issues associated with #1 and #2, and avoiding issues related to > "official" key compromises. > > hth > > 73 de Jeff > >
_______________________________________________ OM-Cooker mailing list [email protected] http://ml.openmandriva.org/mailman/listinfo/om-cooker_ml.openmandriva.org
