Re: [GNU-linux-libre] Help users to verify their downloads

[Jean Louis]

On Mon, Jun 25, 2018 at 07:46:04PM -0400, Patrick McDermott wrote:
> On 2018-06-25 at 11:33, Jean Louis wrote:
> > If I receive PGP key from the same server, and PGP
> > signature, and package from same server, then
> > verification means just nothing.
> 
> OpenPGP public keys are normally pushed to a pool of key servers.  So
> you can get the key from a different server.
> 
> > PGP security works only if the key have been
> > verified with the trusted party who issued it.
> > 
> > So in order to verify the key, I would need to
> > call developer, or SMS him, or otherwise use
> > communication channel that is trusted (even this
> > is not absolute), and then by exchanging
> > fingerprints, I would know I have his true PGP
> > key.
> > 
> > Only thereafter I can use his public PGP key to
> > verify that package have been signed by his public
> > PGP key.
> 
> This is not very practical, or even sufficient.  It can verify a key,
> but it doesn't authenticate the key's owner.  How secure is the method
> by which you found the phone number?  How do you know that the voice on
> the other end is that of the maintainer?  You can't very easily verify
> someone's identity by phone, especially in a publicly reproducible way
> (ask a question with a secret answer, and the answer is no longer
> secret, because an impersonator could get and repeat the same answer).
> 
> OpenPGP has a more effective and distributed solution to this: the web
> of trust.  Maintainers meet people who verify their identities in person
> and sign their keys (ideally either shared in full or identified by a
> full fingerprint or a sufficiently large ID).  The people who meet the
> maintainers meet other people to have their identities verified and keys
> signed, and so on.  If a user has met some people and verified and
> signed some keys, then there is likely to be at least one trust path
> somewhere, through N degrees of separation, that leads to the maintainer
> of the downloaded software they want to verify.  GnuPG looks for such
> trust paths when using a key to verify a signature.
> 
> In practice, this doesn't always work out, because not all users go
> around to key-signing parties to connect themselves into the web of
> trust.  Such people could instead look up a maintainer on their favorite
> key server and look for a key that has numerous signatures from keys
> that in turn have numerous signatures.  It's far from ideal but better
> than nothing.

I know.

Majority of users will not know.

In regards to number of signatories in the web of
trust, in matter of minutes it is posssible for
anybody to create PGP keys, such as

address@hidden

and sign that key with multiple other keys, and
upload the key which was verified by web of
trust. I can sign such key with multiple other
fake keys. 

We are back at the fact that

> > So when requesting any security feature for
> > packages to be placed for downloading, let us not
> > dwell in some illusions of security.
> > 
> > If users don't know how to verify PGP fingerprints
> > with the issues of the PGP key, and it is anyway
> > unlikely that any serious percentage would be
> > doing so, then we are wasting time by creating
> > apparent security.
> 
> The perfect is the enemy of the good.  Sure, perfect security is
> impossible, but that doesn't mean we should give up on having any
> security at all.  Security is not a binary thing; it's a matter of best
> efforts, defense in depth, and deterring an attacker at least long
> enough that they give up.
> 
> As long as the threat model and weaknesses are considered (i.e. not
> having a false sense of perfect security), any level of security is
> better than none.

It is not.

It is well known that security is only as strong
as its weakest link.

In this case, it is as secure as possibility to
enter some GNU/Linux server and compromise it. To
enter the server is very weak link.

I have been maintaining servers since decades. And
have launched multiple servers. Backdoors,
intruders, spammers, game players, all kinds of
people enter remote servers, and thousands of them
attempt to enter the servers worldwide.

How do we know that:

- maintainers don't have "friends" in their houses
  who have access to their computers, they can
  read passwords, they can implement backdoors,

- how do we know which password policies
  maintainers use in general? Maybe their
  passwords are too simple and can be cracked. I
  don't believe each maintainer of distributions
  is aware of security. We have recently seen Blag
  distribution being removed for not being
  updated. To me that is security issue.

- how do we know that maintainers truly know their
  hosting system? That it is safe from other
  people?

- how do we know the maintainers of distribution?

There are many more such questions.

To rely on hashes which are located on mirror
servers, like for example Digitalocean is doing
so, is simply no security at all. It is just
mechanism to make sure that file that was checked
before downloading is the same file downloaded.

It does not say anything about the genuity of the
file.

To rely on PGP signatures, which we did not check,
well that is by PGP standard incorrect, so if we
do so, that means there is no security at
all.

To rely on "web of trust" by standard requires me
to know those people in the web of trust, that is
why there is trust, if I know them, and who they
are, I can trust that key belongs to one person.

Just to see the list of numerous people who signed
a key is not "web of trust", it is just list of
numerous people who signed a key, nothing
else.

Instead:

In my opinion it would be good enough to trust to
the domain from where packages are taken, for
example:

- trusting Hyperbola.info domain for example, or
  gnu.org
  
- all package databases to be downloaded from
  there
  
- all PGP signatures, hashes to be downloaded from
  there
  
- problem is with mirrors, so the above
  information would be used to verify that
  packages on mirrors are genuine by using hashes,
  and by using GPG

- that the trusted domain keeps system of tracking
  users, and a log, so prove to public that was
  not compromised, or otherwise to show policies
  on how the original domain is maintained and
  controlled, policies for maintainers, who is
  really accessesing and who is really responsible
  for publishing of those packages

And then to implement such security system
centrally.

Security is only as strong as its weakest link.

Jean