Re: Security issues in Emacs packages

[Jean Louis]

* Tim Cross <theophilusx@gmail.com> [2020-11-26 01:47]:
> I think you missed my point. There is no benefit in MELPA adopting
> signed packages because there is no formal code review and no vetting of
> the individuals who submit the code.

Do you think it is really their reason? Or maybe you are developer in
MELPA?

There is still difference if package comes from MELPA or from third
party archive, definitely signing would say this package was signed by
MELPA and other package was not signed by trusted key, so who is that?
Is the MD5SUM same as original? It would give some initiative to
investigate.

Packages are not audited that is so. I think audit can be quick by
using grep for some dangerous commands, I have already found rm -rf as
example command in one of packages, not as malicious one. One could
search for (shell-command and verify such and similar functions.

> If you have no controls in place over the contents of what is being
> signed, the value of the signatures as a security measure is
> drastically reduced. Yes, the valid signature may provide some
> assurances as to where the package originated, but that means little
> if the contents could be anything.

What you explain is logical to me, users though need better
information. One big DANGER should be given to users.

> As it stands, the signing of ELPA packages only provides assurance that
> they are packages assembled by GNU. These signatures do not provide any
> real assurance regarding the content of the packages other than they are
> GPL's and do not recommend or encourage the use of non-free
> software.

There is no absolute. Signing says about origins. Mirrors are placed
anywhere in the world, including behind Internet. It is one way for
users to verify origin and if source has been changed.

> The question is what level of trust should you assume. With ELPA, all
> you can really trust is that the package has a GPL license and does not
> recommend/require the use of non-free software. There is little trust
> that the package does not do something malicious or includes code which
> may compromise the user's security. to provide that level of assurance,
> you would need formal code reviews, which is not feasible given
> available resources.

Last month I could see that several packages were here and there
improved by developers so they do look into code and how much they do
I cannot know.

> I think it is important users are aware of this
> limitation. Furthermore, I ask the question "Does having signed
> packages imply a level of expected assurance which is higher than it
> really is?"  In other words, do users expect that a package is
> completely safe just because it was downloaded from an official GNU
> ELPA repository?

Download numbers on MELPA tells me that answer should be rather
positive, any package is safe to be installed. See
numbers. Information is no enough to teach users. More attention is
necessary. 

> Last time I looked, ELPA also supported 'external' packages where the
> data is retrieved from an external git repository. I think org is one
> such package.

Majority of GNU ELPA packages are external how I know about it, but
authors decide WHEN to upload them.

> > The point number (1) is human, not automated. Author decides when is
> > the package ripe for distribution and what is "release".
> >
> > Git repository is never release and not meant to be "release". Git is
> > for collaborative development and users are made blind that it is some
> > kind of release while it is not. One shall always assume that Git
> > repository contains development versions not ready for public.
> >
> 
> Why? This is not normal. Git repositories contain all versions, both
> production and development. What is production and what is development
> is managed through branches and tags. Anyone who wants can clone the
> ELPA git repository.

How I see practically, people hack on git master branches and main
branch need not be considered release ready. Git hosting websites then
have special section for releases. Git branch is not a release
according to what I know, it is revision control system or version
control system. Git often looks pretty different than release as
package. Of course everybody can clone. Point is that software is no
ripe. Maybe somebody else knows if Git can tell that software is ripe,
what I know it is not so. Author has to say when it is ripe for
release. 

> > MELPA pulls those packages, correct me if I am wrong, automatically
> > from Git repositories without regard if the package is actually
> > release. That does not align or respect the established Emacs
> > conventions how packages should be released, if they are multi files
> > they should be in .tar file otherwise .el and there are version
> > numbers that MELPA fiddles with and makes possible conflicts and
> > introduces confusions.
> 
> this is wrong. In melpa you specify either a commit (SHA) or a branch or
> both. The repository owner has control over this. MELPA doesn't just
> pull data from the repository because there has bene an update. You can
> configure things so that whenever data is committed to a release branch,
> it is pulled, but this is under the control of the repository owner. It
> isn't that different to ELPA where the maintainer will either push new
> data to the ELPA repository (or ask someone with write permission to
> pull it from their repository).

OK it is great that it is so. Are you maybe author doing it? Is there
any reference that authors are doing so? I have MELPA downloaded you
could tell me how do I see that author is deciding if package is for
release?

> You imply authors do not have control over when new releases are made.
> This is not the case. They have full control.

Sure they have for themselves. Do they have it for MELPA?

> The situation with ELPA is not much better. Yes, the authors are
> required to sign over copyright, but what does that really tell you
> about the author. How much vetting is done to verify those copyright
> assignments? How much vetting is done to verify the identities of those
> people? More importantly, how much of the code is formally reviewed?

Valid questions!

> The assumption that because a package is from ELPA it is safe is
> wrong.

Safer, not safe.

Assumption by majority is that any packages from anywhere are
safe. Downloads prove it.

> So how big a risk are ELPA packages in reality? This is a difficult
> thing to quantify. Yes, I do think there is lower risk with ELPA than
> MELPA because even informal review is better than no review.

Side note: ELPA is protocol, GNU ELPA is repository. MELPA ELPA should
be rather more correct name.

I can see all those points and I would like there is better code review.

> > For that reason MELPA's automatic pulling of packages and race to
> > offer "large package repository" is rather by its design detrimental
> > for future. I hope it will change, but currently that is unlikely.
> >
> The automatic pulling is not the issue. As long as there is no formal
> review of code in packages, any method used is vulnerable.

So is there automatic pulling?

I compare automatic pulling and building to author's decision on when
a package would be issued.

Jean