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

[Stefan Monnier]

> I meant to make it as a rule to sign packages, and that is should be
> default in Emacs to accept only sign packages, that increases level of
> security rather than leaving it acceptable for users to get unsigned
> packages. It is definitely now everything about security, yet it is
> one level.

IOW, you're just restating in other words your request to change
`package-check-signature` to t?

> My purpose was to tell you that if Emacs developers allow non-SSL by
> default that users are automatically put at certain risks and that is
> better to ask for SSL by default.

And here you're suggesting that the default value of `package-archives`
should always use `https` regardless of the `gnutls-available-p`?

> So GNU Emacs users should maybe trust blindly packages from ELPA, but
> not all packages by default.  To trust other packages they should be
> able transparently to import GPG keys and be able to see the
> fingerprints.

IIUC I basically said the same earlier when I explained that maybe one
reason Melpa still doesn't sign its files is the lack of a clean/good
way for the user to add Melpa's keys to `package.el`s keyring.

Patches welcome in this area.

> Packages are meant to be distributable as well, if they are signed,
> signature should be also fetched, but that is probably not original
> design of Emacs. In my opinion, it should be. Signatures should be
> inside of the package directory,
> ~/emcas.d/elpa/package-0.0/file.el.gpg

This makes way too many assumptions to be worth discussing, IMO.
For the case of "single file ELPA package" (i.e. those files
distributed as a single .el file) maybe that can work without too much
trouble (tho there's still the issue of trusting the accompanying .elc
file), but for the more common packages distributed as tarballs, I think
this is completely impractical.

A saner approach might be to keep a "cache" of the packages in their
original (not-installed) form and make that available as a "local ELPA
archive" from which you can redistribute those packages to
other machines.  My impression is that this would be better served by
a separate package than by trying to add the feature directly to
`package.el`, especially since I suspect it would remain a fairly
unusual scenario.


        Stefan