emacs-devel
[Top][All Lists]
Advanced

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

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


From: Stefan Monnier
Subject: Re: Proposal to include obligatory PGP verification of packages from any repository
Date: Fri, 23 Oct 2020 14:25:55 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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

I'm find with it, but it's not up to me and I think it will require more
code changes so that errors are reported in a way that's more friendly
to the user (e.g. so the users can figure out whether the problem is
with the signature, the lack of key, or the lack of GPG, for example).

I suggest you `M-x report-emacs-bug` with this specific request and
accompany it with a patch that improves the error handling.

>> > 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`?
> I understand from that statement that probably not every platform will
> have gnutls or whatever other solution.

I believe it is available on all the platforms we support, but you can
build Emacs without support for it (and under Windows, IIUC, you can
build it with support for gnutls and later run it without libgnutls in
which case it'll behave pretty much as if it had been built without
support for gnutls).

> Let me mention that ...

Yes, you already said so, and I believe it's been common knowledge on
this mailing-list for a while.

>> 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.
> Maybe tar can be signed as such?

It is.  But the installed files are not the tarball, and it's difficult
to reproduce the tarball from the installed files in order to check that
they still "match the signature".

>> 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.
> Yes.  For me is no problem.  I speak for wide user base.  Ability for
> each ELPA to download full set of packages and keep it as local ELPA
> would be convenient for many users who do not have stable Internet.

You can mirror GNU ELPA via rsync.


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]