On Tue, Mar 22, 2016 at 2:45 PM, Björn Persson <Bjorn@rombobjörn.se> wrote: > > Till Maas wrote: > > I guess it might even make the new hotness do scratch builds with > > verified tarballs, since iirc it updates both the tarball and the > > signature and then %prep makes sure that they are verified. > > I suppose so, at least if the key is specified as only a filename. What > will it do if a URL to the key is provided, and the key at that location > has been modified? Will it replace the key with the modified one in the > scratch build, or will it leave the key alone when there is no version > number in the filename? If Werner Koch is willing to make changes to benefit this type of use case, I don't suppose he could be persuaded to define a canonical, reasonably compact fingerprint format? $ gpg --verify-by-fingerprint "gpg-ecdsa-nfakjwejfhasasfewiahcalkweec" filename filename.sig [optional path to keyring or whatever if not embedded in the sig] would be quite handy. 256 bits of fingerprint would be sufficient for the forseeable future against anything except multiple-target quantum attacks. With signature schemes like ECDSA, simply encoding the literal public key would work fine, too. <not-yet-relevant>Off the top of my head, a multiple-target quantum attack involves finding any of 2^t needles in a haystack of size 2^b, for a probability of 2^(t-b) that any given needle wins. Using a practical upper bound of t=128 and requiring that the adversary spend 2^128 effort on an attack gives t-b ~ 256 or b ~ 384 bits for security against Grover-style attacks. Of course, trying to defend against that attack using 384-bit fingerprints over ECDSA keys is totally pointless. The world should seriously consider switching to SPHINCS or similar for software verification. </not-yet-relevant> > > Björn Persson > > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx > -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
