Re: Proposal to include obligatory PGP verification of packages from any repository

[Jean Louis]

* Stefan Monnier <monnier@iro.umontreal.ca> [2020-10-19 21:02]:
> > tried installing some from ELPA and did not see any difference.
> 
> What difference did you expect to see?

I really expected to see that it is verified, like some message,
feedback in the Message buffer, but it just goes very silent, thus
user has to rely that package vas checked.

The name of function package-check-signature gives me more impression
that if I am the one who is setting the variable, that I would be in
some kind of control to know that signature of the package is checked.

Without message I see nothing, so Emacs is checking, but user does not
know that package was checked for signature.

I would rather expect message shown, just as it is not shown for
unsigned packages.

> > There are just few well known, ELPA, Org and MELPA.
> 
> Again, there is no ELPA archive named "ELPA".
> Please try and avoid spreading the confusion between ELPA and GNU ELPA.

That is right, I understand, so instead of ELPA which is meant for
general protocol, is better to say GNU ELPA.

Regarding packages in GNU ELPA, can I now assume they are all signed?

Is there a policy that GNU ELPA packages should be signed? That policy
would be good to have.

What I expect is a method for user to easily verify and know by which
key was which package signed, such function should exist.

I also expect that such verification should be by default, but default
was to accept unsigned, which is security issue in Emacs. Today is
common from package managers to expect at least automatic verification
of signatures.

It would be better if Emacs is delivered with the variable:
package-check-signature to be by default at least T or ALL to verify
all signatures.

Right now default is to accept unsigned. I am very surprised.

What I would like to see is:

  If the package-check-signature variable is for all types from
  packages, those downloaded any how, or from file system, and for
  those from archives, that ne wvariable is implemented so that
  packages downloaded from various centralized archives shall be
  checked for signature by DEFAULT.

- new variable: package-from-archive-check-signature to be by default
  T to check signature, with the warning in the description of the
  variable. 

- current variable: package-check-signature, for this one, I still
  study if it is valid for any packages, I can see I could install
  package from file without being checked for signature. So that is
  not my expectation, it probably works only for packages from
  archive, but not for any packages. My expectation is when this
  variable is set that it verifies all packages that user is
  installing.

  If there is only intended use of this variable for archive packages,
  then it is fine, but then documentation should not just say: Non-nil
  means to check package signatures when installing, but it should
  refer to package installing from archives

  I am installing often packages from file system by using
  package-install-file

- in that case that variable does not affect other sources but
  archives, users shall be warned in documentation strings or info
  that installing packages is risky activity.

What I wish to say, which may not be liked by many, I would like that
variable ensures that packages delivered through any current or future
onlinen archives are by default verified to be signed. This would
increase general security for Emacs users.

This would make necessity for MELPA to secure the packages by signing
them, thus giving little more safety to users.

As the situation how we have it now, those users of MELPA who value
the number of 4700+ packages being offered are more and more exposed
to potential risks.

There will be other repositories, anybody can then duplicate the
packages, but they cannot change signatures, they would need to make
new signatures, at least there would be some trace which key signed
which package.

Is making archive packages checkable by default for signatures
difficult for some practical reasons other than forcing MELPA to offer
new security level?