icecat or/and firefox?

Kevin Fenzi kevin at scrye.com
Mon Jan 27 22:18:09 UTC 2014


On Mon, 27 Jan 2014 20:41:35 +0100
poma <pomidorabelisima at gmail.com> wrote:

> On 27.01.2014 20:28, Andrew Lutomirski wrote:
> > On Mon, Jan 27, 2014 at 10:59 AM, poma <pomidorabelisima at gmail.com>
> > wrote:

...snip...

> > I'm skeptical about the whole package-signing thing.  

skeptical in what way? 

> > Why don't we
> > sign repository metadata and have that metadata store hashes of the
> > appropriate packages?  Then adding a key for a repository wouldn't
> > magically allow that key to sign packages claiming to come from a
> > different repository.  It would also prevent various
> > replay-old-package attacks.

Sure, but if you install a package not from the repo you have no way to
know it's valid without that repodata being available to check against. 
Also, old packages won't be verifable anymore when repodata changes to
drop them. 

> > Configuration could be simpler, too:
> > 
> > [some-copr-repo]
> > name=Name
> > metalink=whatever
> > metalink_key=[private key, specified right here]
> > gpgcheck=0

Something would need to generate the metalinks then... 

Feel free to file it as a RFE for copr... perhaps it would work out
there. 
 
> > I doubt that GPG's keyring concepts or web-of-trust stuff add any
> > security whatsoever to things like rpm and yum.  They do, however,
> > make configuration unnecessarily arcane.
> 
> We shouldn't change so easily tried and tested methods just because
> you "doubt". :)
> Ouch[2]!

Well, there are advantages to moving to signing repodata. There's also
disadvantages. For Fedora repos, it's not worth it. It might be the
tradeoffs are different in copr and it's a better option there. 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140127/b0b7a625/attachment.sig>


More information about the devel mailing list