is melpa just unsigned?

is melpa just unsigned?

[Samuel Wales]

i can't seem to find out whether melpa is just plain unsigned as part
of its design, or if the archive-contents file is just plain unsigned
and packages might or might not be, or if the archive-contents file is
supposed to be signed but is not.

as a debian user, i am used to all packages AND the package list being
signed [i think].  i do not know all the security implications of not
signing an archive list, but it sounds dodgy.  in any case, the error
should definitely not be there?

if the archive contents file is not signed, what does htis mean in
practice?  what are the attack vectors?

am i going to have to inspect every line of code in all packages?
this isn't practical.

it seems gnu elpa is all signed and sealed and delivered.  so i feel
comfortable inasmuch as that helps.  why not melpa?

but gnu elpa does not have the packages that i need.  i am new to
packages.  i just upgraded to 27.1 and getting lots of bugs and
glitches.  i hope i can get some wisdom from this list on the above
questions.

in particular, why am i getting that error and does melpa sign its
package archive?  thanks.  please cc: me.

On 5/17/23, Samuel Wales <samologist@gmail.com> wrote:
> i tried everything suggested i coud find on the web and i still get:
>
>   Unsigned file ‘archive-contents’ at https://melpa.org/packages/ [2 times]
>
> whenever i try to list-packages.  package-refresh-contents resilts in
>
>   Failed to download ‘melpa’ archive.
>
> i have tried renaming ~/.emacs.d/elpa, the melpa subdir, the gnupg
> subdir.  the gnupg subdir ends up with different contents each time i
> try it, it seems.  any help apprecited.
>
> On 5/16/23, Samuel Wales <samologist@gmail.com> wrote:
>> i am the king of writing help messages to this list that do not get
>> replied to.  i am trying to make them comprehensible and answerable
>> but there are often significant limitations.
>>
>> On 5/15/23, Samuel Wales <samologist@gmail.com> wrote:
>>>   ;; [2023-05-15 Mon]
>>>   ;; i am new to emacs packages, but not new to emacs
>>>   ;; i recently upgraded to emacs 27
>>>   ;; i followed these instructions from melpa:
>>>   (require 'package)
>>>   (add-to-list 'package-archives '("melpa" .
>>> "https://melpa.org/packages/")
>>> t)
>>>   (setq package-check-signature 'all)
>>>   (package-initialize)
>>>   ;; i installed gnu-elpa-keyring-update from elpa
>>>   ;; problems:
>>>   ;; 1.  startup takes 9s instead of 4s
>>>   ;; 2.  when i do m-x list-packages, i get error in echo area.
>>> messages buffer says:
>>>   ;; Importing package-keyring.gpg...done
>>>   ;; Package refresh done
>>>   ;; error in process sentinel: Unsigned file ‘archive-contents’ at
>>> https://melpa.org/packages/ [2 times]
>>>   ;; package list shows up, but it does not seem wise to install
>>> anything.
>>>
>>>
>>> --
>>> The Kafka Pandemic
>>>
>>> A blog about science, health, human rights, and misopathy:
>>> https://thekafkapandemic.blogspot.com
>>>
>>
>>
>> --
>> The Kafka Pandemic
>>
>> A blog about science, health, human rights, and misopathy:
>> https://thekafkapandemic.blogspot.com
>>
>
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: is melpa just unsigned?

[Michael Heerdegen]

Samuel Wales <samologist@gmail.com> writes:

> as a debian user, i am used to all packages AND the package list being
> signed [i think].  i do not know all the security implications of not
> signing an archive list, but it sounds dodgy.  in any case, the error
> should definitely not be there?
>
> if the archive contents file is not signed, what does htis mean in
> practice?  what are the attack vectors?

If you get no answers here... since Melpa is not part of Emacs, maybe you
have more luck if you ask the Melpa people?

Michael.

Re: is melpa just unsigned?

[Emanuel Berg]

>> as a debian user, i am used to all packages AND the package
>> list being signed [i think].

Here are some 733 lines to read how they do it for Debian:

  https://www.debian.org/doc/manuals/securing-debian-manual/deb-pack-sign.en.html

>> what are the attack vectors?

Malicious code inserted into the software supply chain *ka-boom*

> If you get no answers here... since Melpa is not part of
> Emacs, maybe you have more luck if you ask the Melpa people?

You mean they don't read here? :(

-- 
underground experts united
https://dataswamp.org/~incal

Re: is melpa just unsigned?

[Michael Heerdegen]

Emanuel Berg <incal@dataswamp.org> writes:

> > If you get no answers here... since Melpa is not part of
> > Emacs, maybe you have more luck if you ask the Melpa people?
>
> You mean they don't read here? :(

I don't know.  Some days ago I opened an Github issue with an request
for an answer and improvement of the documentation of Melpa so that
users can read about this.  So far nobody responded.  Maybe they are all
on vacation or nobody wants to say something wrong, I don't know.

Michael.

Re: is melpa just unsigned?

[Samuel Wales]

just brainstorming but if by chance melpa is not signed, i wonder if
there are package managers that kind of kludge security a bit.  not
perfection, but try to dtrt.  enhancing melpa or bypassing it.

for example, idk the current status of git's sha-1 [?] crypto
brokenness, but packages that use git could perhaps have their shas
compared via multiple routes, or so.  maybe only google-level actors
could currently break sha-1 for all i know.

at least you could check that the sha you have is the same lots of
other users have?

are guix or nix debian-like in their signing infrastructure?  i am
just thinking out loud here for possible solutions for more security.
comparing multiple routes, using git's history, or a  clever trick i
am not thinking of now.  does el-get do?

of course i am aware signing is only part of ensuring security,
and melpa does curating, and authors or computers could turn evil, but
where there is a chain that reliably goes back to an author from the
code you dled, it's a pretty good feeling.


On 5/21/23, Michael Heerdegen <michael_heerdegen@web.de> wrote:
> Emanuel Berg <incal@dataswamp.org> writes:
>
>> > If you get no answers here... since Melpa is not part of
>> > Emacs, maybe you have more luck if you ask the Melpa people?
>>
>> You mean they don't read here? :(
>
> I don't know.  Some days ago I opened an Github issue with an request
> for an answer and improvement of the documentation of Melpa so that
> users can read about this.  So far nobody responded.  Maybe they are all
> on vacation or nobody wants to say something wrong, I don't know.
>
> Michael.
>
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: is melpa just unsigned?

[Platon Pronko]

On 2023-05-23 09:53, Samuel Wales wrote:
> just brainstorming but if by chance melpa is not signed, i wonder if
> there are package managers that kind of kludge security a bit.  not
> perfection, but try to dtrt.  enhancing melpa or bypassing it.
> 
> for example, idk the current status of git's sha-1 [?] crypto
> brokenness, but packages that use git could perhaps have their shas
> compared via multiple routes, or so.  maybe only google-level actors
> could currently break sha-1 for all i know.
> 
> at least you could check that the sha you have is the same lots of
> other users have?
> 
> are guix or nix debian-like in their signing infrastructure?  i am
> just thinking out loud here for possible solutions for more security.
> comparing multiple routes, using git's history, or a  clever trick i
> am not thinking of now.  does el-get do?
> 
> of course i am aware signing is only part of ensuring security,
> and melpa does curating, and authors or computers could turn evil, but
> where there is a chain that reliably goes back to an author from the
> code you dled, it's a pretty good feeling. 

The whole point of MELPA is to automatically provide up-to date packages built directly from upstream repos - the default MELPA repository builds a new release on each new commit (alternatively there's MELPA Stable, which creates new relases from new tags).

The key idea here is "automatically". So I don't see any way for these packages to be signed, since the package authors obviously won't be giving their keys to MELPA.

I suppose if you are looking for signed packages your best bet is GNU ELPA - some of the packages there are indeed signed.

P.S. As far as I know Emacs mailing lists prefer bottom-posting (as opposed to top-posting).

-- 
Best regards,
Platon Pronko
PGP 2A62D77A7A2CB94E

RE: [External] : Re: is melpa just unsigned?

[Drew Adams]

> of course i am aware signing is only part of ensuring security,

Indeed.

> and melpa does curating,

AFAIK, it does not.  Someone might look over the code
initially, as a sanity check, but I don't believe
anyone (or anything) checks it thereafter.  Someone
will correct me, if this has changed.

Re: is melpa just unsigned?

[Daniel Fleischer]

Samuel Wales [2023-05-22 Mon 19:53] wrote:

> of course i am aware signing is only part of ensuring security,
> and melpa does curating, and authors or computers could turn evil, but
> where there is a chain that reliably goes back to an author from the
> code you dled, it's a pretty good feeling.

Not a security expert but signing helps with downloading files from
questionable hosting (usually you download the signature from the same
website, thus you solve nothing). You can skip the middleman melpa.org
and install packages directly from their respective forges, e.g. github,
gitlab, sourcehut using either something like quelpa or built-in
package-vc-install.

-- 
Daniel Fleischer

Re: is melpa just unsigned?

[Samuel Wales]

thank you to all.

iiuc, these are my quick and tentative impressions/conclusions:

- compared to e.g. debian, security is probably not widely considered
a top priority in most of emacs community atm
- big array of interesting pm options, both inside [pms, paradox] and
outside [guix, nix, debian] of emacs
- repos: i have chosen gnu elpa, non-gnu elpa, and package.el for now.
they are signed.  they are simple.
- i would add elpa devel and nongnu elpa devel, but updating  with U
for some reason updates to those even when repo priorities are set
with those lower priority than elpa and nongnu elpa
- i don't really know much about non-gnu elpa or the devel repos
- for other packages, idk.  git clone from repo or so?  idk.
- i typically update packages every few years
- answer to q is: melpa, not even package list, is probably not signed?
- melpa probably isn't for me as i don't need its recency and would
prefer signing or so.  i like the vetting.
- idk if quelpa, elpaca, etc. are for me; might or might not be; same
with guix and nix.  cannot investigate.
- relying on debian might impede portability
- probably no package / pm uses clever hacks to improve security or
help user vet code or provenance
- emacs wiki anybody can edit as a repo is a bit too radical for my taste
- emacs mirror idk much about but maybe a pm can fetch, keeping the
points of faiure to just one repo or so idk

-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: is melpa just unsigned?

[Björn Bidar]

Daniel Fleischer <danflscr@gmail.com> writes:

> Samuel Wales [2023-05-22 Mon 19:53] wrote:
>
>> of course i am aware signing is only part of ensuring security,
>> and melpa does curating, and authors or computers could turn evil, but
>> where there is a chain that reliably goes back to an author from the
>> code you dled, it's a pretty good feeling.
>
> Not a security expert but signing helps with downloading files from
> questionable hosting (usually you download the signature from the same
> website, thus you solve nothing). You can skip the middleman melpa.org
> and install packages directly from their respective forges, e.g. github,
> gitlab, sourcehut using either something like quelpa or built-in
> package-vc-install.

Another alternative is borg + magit + epkg.

The workflow makes it quite easy to contribute and test changes in
packages.