[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Fwd: Fwd: question regarding verification of a debian installation iso



On Mon, Jan 3, 2011 at 7:06 PM, Naja Melan <najamelan@gmail.com> wrote:

> I totally agree, but from my position as an end user I can only start by
> raising the issues I can observe because I am confronted with them. I don't
> know the security policies for debian/fedora developers if those even exist
> or whether they are being executed properly. I can only raise a point and
> draw my conclusions from how serious it is being taken to assess the general
> trust I decide to put in a certain product.

I should note that I am little more than an interested Debian user.  I
can't speak for the Debian project.  Though I do find the subject
interesting enough to pursue discussion.

> I suppose they just choose https, as the basis of their security, which
> obviously only protects the transporting. The key is signed by two other
> keys though but verification suffers from the same limitation as with debian
> of course.

I believe the underlying issue is assuring the integrity of the
software being downloaded from whatever source (keeping in mind how
Debian, as well as many other distros, uses mirrors).  I can see how
HTTPS can be beneficial.  But ultimately, I think too much emphasis /
trust is being put on HTTPS in this conversation.  If you can solve
the issue of trusting a signing key, then you are a lot further along
with the issue of integrity since it can be applied to more than just
MITM attacks.  And again - I think MITM is the lesser risk here.

The web of trust issue is core to a decentralized system like PGP.
The issue, as I see it, is understanding how PGP works and how to make
reasonable judgments on when one trusts a key.  Having to do this has
always been both an advantage and a disadvantage of PGP.  It takes
some effort.  But then, there are times when you can't reasonably get
around that.  Documentation (and good end user judgment) is probably
the way to tackle this.

> That is true and good, but these instructions only speak about md5, which
> means that the other hashes are probably only used by people who know why
> not use md5.

That would probably be the easiest thing to address - update
documentation to no longer use MD5, even if it is still made available
to those who insist on using it.


Reply to: