bug#66414: GNU ELPA: Require signed tags to release new package versions

bug#66414: GNU ELPA: Require signed tags to release new package versions

[Stefan Kangas]

Severity: wishlist

I propose optionally releasing a new version of packages on
NonGNU/GNU ELPA only if there is a valid PGP signature.  We can't make
it mandatory, at the very least not initially, because it would break
too many existing workflows.

The standard feature to do that in git would be a signed git tag.
However, (Non-)GNU ELPA currently rebuilds package tarballs every time
the "Version" comment header is updated, while git tags are ignored.

Forwarded from

    https://lists.gnu.org/r/emacs-devel/2023-02/msg00120.html

bug#66414: GNU ELPA: Require signed tags to release new package versions

[Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Hi,

Stefan Kangas <stefankangas@gmail.com> writes:

> Severity: wishlist
>
> I propose optionally releasing a new version of packages on
> NonGNU/GNU ELPA only if there is a valid PGP signature.  We can't make
> it mandatory, at the very least not initially, because it would break
> too many existing workflows.
>

Do I understand correctly that under this proposal package
authors/maintainers would need to opt-in to such signature validation?

Another option that might be worth considering is to continue releasing
packages, with or without a valid signature, and instead to indicate the
absence or invalidity of a signature in the packages list and in other
package.el commands.  This has the benefit of requiring nothing from
package maintainers while creating a clear incentive to add those
signatures, and it would also give users the chance to employ their
personal judgment on case-by-case basis.  OTOH There are many cases to
consider, such as what happens when a user wants to upgrade a signed
package but the newer version is unsigned.

> The standard feature to do that in git would be a signed git tag.
> However, (Non-)GNU ELPA currently rebuilds package tarballs every time
> the "Version" comment header is updated, while git tags are ignored.
>
> Forwarded from
>
>     https://lists.gnu.org/r/emacs-devel/2023-02/msg00120.html

bug#66414: GNU ELPA: Require signed tags to release new package versions

[Stefan Kangas]

Eshel Yaron <me@eshelyaron.com> writes:

> Do I understand correctly that under this proposal package
> authors/maintainers would need to opt-in to such signature validation?

Yes.

> Another option that might be worth considering is to continue releasing
> packages, with or without a valid signature, and instead to indicate the
> absence or invalidity of a signature in the packages list and in other
> package.el commands.

Yes, something like that is what I had in mind.

bug#66414: GNU ELPA: Require signed tags to release new package versions

[Philip Kaludercic]

Stefan Kangas <stefankangas@gmail.com> writes:

> Severity: wishlist
>
> I propose optionally releasing a new version of packages on
> NonGNU/GNU ELPA only if there is a valid PGP signature.  We can't make
> it mandatory, at the very least not initially, because it would break
> too many existing workflows.

I am not sure what the context here is, so sorry for the potentially
stupid question, but what PGP signatures are we talking about?  Are you
suggesting that the commit should be signed?

> The standard feature to do that in git would be a signed git tag.
> However, (Non-)GNU ELPA currently rebuilds package tarballs every time
> the "Version" comment header is updated, while git tags are ignored.
>
> Forwarded from
>
>     https://lists.gnu.org/r/emacs-devel/2023-02/msg00120.html

bug#66414: GNU ELPA: Require signed tags to release new package versions

[Stefan Kangas]

Philip Kaludercic <philipk@posteo.net> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> Severity: wishlist
>>
>> I propose optionally releasing a new version of packages on
>> NonGNU/GNU ELPA only if there is a valid PGP signature.  We can't make
>> it mandatory, at the very least not initially, because it would break
>> too many existing workflows.
>
> I am not sure what the context here is, so sorry for the potentially
> stupid question, but what PGP signatures are we talking about?  Are you
> suggesting that the commit should be signed?

Yes, see the very next sentence:

>> The standard feature to do that in git would be a signed git tag.

Sorry for not being more clear.

bug#66414: GNU ELPA: Require signed tags to release new package versions

[Philip Kaludercic]

Stefan Kangas <stefankangas@gmail.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Stefan Kangas <stefankangas@gmail.com> writes:
>>
>>> Severity: wishlist
>>>
>>> I propose optionally releasing a new version of packages on
>>> NonGNU/GNU ELPA only if there is a valid PGP signature.  We can't make
>>> it mandatory, at the very least not initially, because it would break
>>> too many existing workflows.
>>
>> I am not sure what the context here is, so sorry for the potentially
>> stupid question, but what PGP signatures are we talking about?  Are you
>> suggesting that the commit should be signed?
>
> Yes, see the very next sentence:
>
>>> The standard feature to do that in git would be a signed git tag.
>
> Sorry for not being more clear.

No, my bad.  I didn't know that git tags could be signed, so I misread
the sentence.

One issue might be that elpa-admin.el doesn't really do anything with
git tags, though I guess it should be possible to verify a remote git
tag?  An alternative might be to check for signed git commits, at the
very least for the commits that bump the version tag.  That way all the
could be kept in elpa.git.

bug#66414: GNU ELPA: Require signed tags to release new package versions

[Stefan Kangas]

Philip Kaludercic <philipk@posteo.net> writes:

> No, my bad.  I didn't know that git tags could be signed, so I misread
> the sentence.
>
> One issue might be that elpa-admin.el doesn't really do anything with
> git tags, though I guess it should be possible to verify a remote git
> tag?  An alternative might be to check for signed git commits, at the
> very least for the commits that bump the version tag.  That way all the
> could be kept in elpa.git.

Yes, I think a signed commit might work fine for this purpose too.  It
would be a more minimal change, if nothing else.

bug#66414: GNU ELPA: Require signed tags to release new package versions

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> I propose optionally releasing a new version of packages on
> NonGNU/GNU ELPA only if there is a valid PGP signature.  We can't make
> it mandatory, at the very least not initially, because it would break
> too many existing workflows.

No objection on my side.  The first step would presumably be to change
the synchronization scripts (the ones run by `elpasync` on
`elpa.gnu.org`) so as to propagate upstream tags to `elpa.git`.

The (Non)GNU ELPA tarballs are built from `elpa.git` and `nongnu.git`,
not from the upstream repositories, and currently those do not
contain upstream tags.

And since those repos contain many packages, the upstream tags need to
be renamed or moved to a different namespace to avoid conflicts between
tag names in different packages.

After that, we need to add the feature to be able to build releases from
tags rather than from "the commit where `Version:` was changed".

And after that, we can add a feature that checks that the tags are
signed (and that the signature is valid and made by the appropriate
persons/keys).


        Stefan

bug#66414: GNU ELPA: Require signed tags to release new package versions

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> The (Non)GNU ELPA tarballs are built from `elpa.git` and `nongnu.git`,
> not from the upstream repositories, and currently those do not
> contain upstream tags.
>
> And since those repos contain many packages, the upstream tags need to
> be renamed or moved to a different namespace to avoid conflicts between
> tag names in different packages.

I'm starting to wonder if Philip's idea to use signed git commits might
work better for our purposes.

Would signed tags give us something that signed commits wouldn't?

bug#66414: GNU ELPA: Require signed tags to release new package versions

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> I'm starting to wonder if Philip's idea to use signed git commits might
> work better for our purposes.

Why choose?


        Stefan

bug#66414: GNU ELPA: Require signed tags to release new package versions

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I'm starting to wonder if Philip's idea to use signed git commits might
>> work better for our purposes.
>
> Why choose?

I see no fundamental reason why we should need to choose, but my
assumption was that supporting only one or the other would be less work.

bug#66414: GNU ELPA: Require signed tags to release new package versions

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> I see no fundamental reason why we should need to choose, but my
> assumption was that supporting only one or the other would be less work.

True.  But there are regular requests to support releasing versions from
tags rather than from commits (regardless of signing), so I think we
will eventually support both.


        Stefan