On using packages from ELPA - was Re: Loaded, but not yet working - Re: Loaded icicles, thanks

[Jean Louis]

I may copy this to emacs-devel so that in Emacs development we learn
from it, if there are points to be learned.

* Drew Adams <drew.adams@oracle.com> [2020-11-14 20:00]:
> I pointed out in the text I pointed you to that pulling from GIT is
> not necessarily safe.  Their point is that you can know that the
> file is from the person who put it on GIT, because there's a
> signature.  I pointed out that nothing prevents someone from
> providing malicious code on GIT.

That is right, I am aware of that. There are already many cases of
security breaches, including that source for Github is also
leaked. Locking EmacsWiki pages by 2 people friendly to Emacs sounds
to me much safer than pulling automatically packages from git
repositories and injecting them semi-automatically into user space of
maybe millions of users.

As when users update packages that is semi-automatical, it is not
fully automatical. And they blindly trust MELPA packages which in turn
are not even signed.

MELPA is a loop that automatically pulls new packages, builds them and
provide to users. There is no human review process once package has
been accepted to MELPA. They accept packages from anonymous authors
without any consideration of their

Even Github and many Git repositories there provide releases.tar.gz
and that in general is classic package release method.

git is for development, it is not for releases. Release packages may
have difference in their structure. Demanding git only to provide
package is kind of coercing programmers to change the common ways of
providing releases. As git is for development and versioning, not for
final releases.

Release does not mean "development version". Not to me. Package
release may be from date 2020-02-01 while development version may be
from 2020-10-01

Demanding the public git repository to be the "package" is
disrespecting the author's opinion on what should be released as
package or not, as author most probably wish to release stable
package and not development version.

In that sense, and I may be wrong, MELPA is decreasing safety for
millions of users as it misses the author's opinion if the package is
ready or not for the release.

Emacs packages are made by convention as described in Emacs Lisp file
and it has been pretty much followed how I researched it for decades
already. It is either .el or .tar package

I hope that we will not adopt automated blind git pulling to GNU ELPA
or new to come non-GNU ELPA.

> My files are locked on the wiki.  But that wasn't deemed safe
> enough.  I think also (and maybe it's only) that they didn't want to
> bother with recipes for wiki libraries.  Whatever the reason, that's
> the way things are.
> 
> > I think many authors like you, should have your own ELPA. You can as
> > well make it on EmacsWiki in your directory if you follow
> > guidelines. Then sign packages with your key, that is it. Packaging is
> > explained in Elisp manual.
> 
> No doubt I should at some point use GIT, but I'm an old
> dog, set in my lazy ways.

When I said: your own ELPA, I reference it to Emacs Lisp manual

41.5 Interfacing to an archive web server
=========================================

A web server providing access to a package archive must support the
following queries:

archive-contents
     Return a lisp form describing the archive contents.  The form is a
     list of ’package-desc’ structures (see ‘package.el’), except the
     first element of the list is the archive version.

<package name>-readme.txt
     Return the long description of the package.

<file name>.sig
     Return the signature for the file.

<file name>
     Return the file.  This will be the tarball for a multi-file
     package, or the single file for a simple package.

So all your packages on EmacsWiki can as well be more conveniently
distributed from Emacs Wiki where they could also ask for dependencies
correctly. All what you need to do to construct above. File names you
already have, README you can construct from pages already written,
signatures ARE necessary and would increase safety feeling to users
and archive-contents would tell about dependencies and all list of
packages.

Then all you tell to users is to update package-archives and include
something like https://www.emacswiki.org/wiki/DrewAdams/elpa and users
would get all list of packages and would download them through Emacs
from EmacsWiki by using M-x package-install

That way author:

- has decided to publish packages, as person thinks packages are good
  for use,
  
- package is thus not development version (nightly or weekly, etc. or
  for developers only) that is not ready for public, package is thus
  ready for public usage

- packages are signed and verified that author or maintainer decided
  to publish them, increasing safety, lessening doubts

Is there a function that automates construction of package-desc
structure?