[arch-general] pacman-key complaining, but what to do about it?

Magnus Therning magnus at therning.org
Thu Apr 3 16:17:27 EDT 2014


On Wed, Apr 02, 2014 at 01:00:00PM -0400, Daniel Micay wrote:
> On 02/04/14 12:47 PM, Nowaker wrote:
> >> There may be a transparent proxy in your routing chain that strips
> >> compression in order to run a virus scan.
> > 
> > Time for SSL-securing Arch Linux repos to prevent any sort of
> > man-in-the-middle attacks? Even such trivial things like compression
> > stripping, or image optimization often performed by mobile internet
> > providers is a man-in-the-middle. This should be fought by any means.
> 
> Packages are already signed, and pacman has support for signing the
> repositories. Using TLS for repositories is close to useless because the

Well, if there's something on the path from repo to client that
re-writes downloads, then pacman's support for signing repos isn't
worth very much when it comes to achieving my end goal.  Sure, I'm
alerted to the fact that the packages I receive are modified, but it
doesn't help me updating my system.  Something would be needed that
throws a spanner in the works of the entity that modifies my
downloads; SSL would do that.  Maybe there are other ways of achieving
the same goal.

> mirrors are not *really* trusted entities, and the CA system is a broken
> alternative to the solid archlinux-keyring package.

The trust sits in the signing of repos, which means there is no need
for trust in the transport layer in this particular scenario; in other
words, it's irrelevant that mirrors are untrusted and it's equally
irrelevant that the CA system is broken ;)

/M

-- 
Magnus Therning                      OpenPGP: 0xAB4DFBA4 
email: magnus at therning.org   jabber: magnus at therning.org
twitter: magthe               http://therning.org/magnus

Most software today is very much like an Egyptian pyramid with
millions of bricks piled on top of each other, with no structural
integrity, but just done by brute force and thousands of slaves.
     -- Alan Kay
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20140403/8c88314c/attachment.asc>


More information about the arch-general mailing list