Re: Security issues in Emacs packages

[Tim Cross <theophilusx@gmail.com>]

Jean Louis <bugs@gnu.support> writes:

> * Tim Cross <theophilusx@gmail.com> [2020-11-26 02:40]:
>> > 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 can clone the melpa repository and see the recipes for each
>> package.
>
> I did before some time.
>
>> It depends on how the author specifies their MELPA recipe. They can
>> define their recipe based on a specific commit (SHA). If they do this,
>> it doesn't matter how often or when MELPA pulls from the repository as
>> they will always get the same commit.
>
> I have not seen that, and I have assumed you would know better and
> wanted to see how authors are reporting that package is ready for
> release and I do not see that.
>
> Recipes are like this:
>
> (0blayout :repo "etu/0blayout-mode" :fetcher github)
>
> (0x0 :url "https://git.sr.ht/~zge/nullpointer-emacs" :fetcher git)
>
> (0xc :fetcher github :repo "AdamNiederer/0xc")
>
> So that recipe alone does not tell me that author reports that new
> package is ready, it is fetched from git, but there are parts of code
> that I did not see that is why I am assuming you know it better.
>
>> Your model is flawed. You can have both automatic pulling AND author
>> control over when a new package is issued.
>
> To make it practical tell me where is that author's control?
>
> I have quick view of files and any recipe files in directory
> melpa/recipes do not give me any pointers, it is all automated and
> fetched from git.
>
>> If author defines their MELPA recipe to use a SHA a new package will not
>> be issued until they update their recipe with a new SHA.
>
> You seem to be very confident and for this reason I assume you know it
> better, but due to contradictions please show one practical recipe or
> package where author has control on when is package ready to be
> released.
>
> $ grep sha *
>
> on recipes does not give any reference.
>
> $ grep commit *
>
> eval-in-repl:              :commit  "origin/master")
> git-auto-commit-mode:(git-auto-commit-mode :fetcher github :repo "ryuslash/git-auto-commit-mode")
> git-commit:(git-commit :fetcher github
> git-commit:            :files ("lisp/git-commit.el")
> git-commit:            :old-names (git-commit-mode))
> git-commit-insert-issue:(git-commit-insert-issue :fetcher gitlab :repo "emacs-stuff/git-commit-insert-issue")
> vc-auto-commit:(vc-auto-commit :fetcher github :repo "thisirs/vc-auto-commit")
> what-the-commit:(what-the-commit :fetcher github
> what-the-commit:         :repo "danielbarbarito/what-the-commit.el")
>
> So there is nothing I can find that points or references to what you
> say.
>
>> If author defines their MELPA recipe to pull from a release branch, a
>> new package will not be issued until they update the release branch and
>> version tag.
>
> I am sorry I do not see reference to it. You are convincing but I do
> not see reference.
>
> Recipe for bar-cursor:
> (bar-cursor :repo "ajsquared/bar-cursor"
> :fetcher github)
>
> Recipe for magit:
>
> (magit :fetcher github
>        :repo "magit/magit"
>        :files ("lisp/magit"
>                "lisp/magit*.el"
>                "lisp/git-rebase.el"
>                "Documentation/magit.texi"
>                "Documentation/AUTHORS.md"
>                "LICENSE"
>          (:exclude "lisp/magit-libgit.el"
>        ;; Cannot remove this yet because it would
>        ;; also be removed from the stable version.
>        ;; "lisp/magit-section.el"
>        )))
>
> Repo magit/magit:
> https://github.com/magit/magit
>
> I have given you references, maybe I cannot read that well, so you can
> give me references to show if authors have participation in decision.
>

The available recipe options are all clearly documented in the README
for the melpa repository. Most maintainers don't use the :commit option
because it is extremely inconvenient, but it is there if they want it.
It is inconvenient because it means the recipe has to be updated, which
means a pull request has to be accepted before the package can be released.

Most maintainers will maintain a specific branch for releases. This is
normal practice in version control. Often, this is the master branch,
but 'release' and 'melpa' are also commonly used. Code is not pushed
onto these branches until it is ready for release. The package
maintainer has full control of this branch and therefore has full
control over when new code is released. This is also the model used by
GNU ELPA for external packages.

This is not the model you imply, where MELPA just grabs the data
whenever it wants and releases new version without management by the
package maintainer, resulting in the release of code that is not ready
for release.

--
Tim Cross