Signed releases

[meator]

Hi @enkore. I have done some work since you gave me write permissions to this repo. I am considering making a new release. There is still a lot of work to be done but I would like to make a new release when the time comes. I have noticed that https://github.com/enkore/j4-dmenu-desktop/blob/develop/HOW-TO-RELEASE#L5 mentions signing the new release. I don't have a private key for A1774C1B37DC1DCEDB65EE469B8450B91D1362C1 so I can't make signed releases. Would you be willing to sign it? I'd like to make releases too. I see these solutions:

1. You (@enkore) will sign each release.
2. New releases won't be signed (I won't sign the next release if you don't respond to this before I make v3.0).
3. I could sign releases with my key.
4. We could somehow share the secrets & be both able to make signed releases.

I'm not a GPG expert (but I'm not a GPG beginner either). I don't really know how 4. would work. You could send me the private key and its password but that has obvious disadvantages.

What are your thoughts on this?

[meator]

@enkore I have released r3.0. As I've promised, it is not signed. I will keep this issue open for now because a signature can still be added to the release.

[ainola]

As a packager, that would be most welcome. @enkore, could you please validate/sign the release for us and then figure out how you two would like to do this going forward?

[ainola]

@meator, I also believe that, as you've been involved in this project for some time, it might be time for @enkore to endorse your key as well (and even perhaps move the repository to its own namespace instead of @enkore?)

[meator]

@ainola enkore had very little involvement with the r3.0 release. When the r3.0 release was ready, I chose to postpone it by two and a half weeks to give enkore time to respond, review and sign. I have e-mailed him detailing my thoughts about the release and asking about the signing status.

enkore didn't respond in time (which is fair). I didn't want to artificially postpone the release any further, so I chose to release it unsigned as mentioned in this issue.

enkore self-assigned to this issue, but did not comment on it, which kinda confused me. I have asked for clarification in my e-mail.

---

If enkore would have signed the release, it would imply that it's enkore's release, that it has been tested and reviewed by enkore. That did not happen. Because of this, I am not sure whether enkore should sign it. If anybody is worried about the authenticity of the r3.0 release, they should know this:

• r3.0 release doesn't include the .sig file in release artifacts of the release
• the r3.0 annotated tag is not signed
• the commit tied to the tag is signed by me (like all commits I make)

Commit fb52c4c which corresponds to r3.0 tag is signed by my personal signature I use on GitHub.

These are breaking changes that make the r3.0 release different from other releases, which is bad. But I of course don't have enkore's private key, so my options were limited.

[ainola]

Thanks for the reply. The chain of trust is broken when switching trusted keys like this - but I guess @enkore's absence leaves us with no other choice. It'd be nice if you could sign it since @enkore won't.

Thanks!

[ainola]

@meator: Ping!

[meator]

@ainola ?

[ainola]

@meator: It would be nice if you could upload a signature artifact for the current 3.0 release so we can establish signing. :)

[meator]

I believe that the main reason the signing was done was to establish authenticity of the release.

I have outlined the signing status of the r3.0 release above. I believe that there are already enough measures in place to verify that I am in fact the author of the r3.0 release and its code (but that in and of itself doesn't really mean much).

---

@enkore It looks like you made some commits to an unrelated project a few days ago. I know I have been spamming you with notifications lately, but if you have time to spare, it would be great if you could comment on the r3.0 release or on this issue specifically.

[ainola]

Thanks for the reply.

Packagers often rely on the PGP signature to verify the authenticity of the downloaded tarballs.

[ainola]

It looks like @enkore has abandoned the project at this point - @meator it'd be great if you could just sign the release yourself so that we can verify the release artifact with your key during package building.

[meator]

@ainola I have created a second release candidate to test out this change: https://github.com/enkore/j4-dmenu-desktop/releases/tag/r3.1-rc2 Would you mind reviewing/testing it? You don't need to build it, I'd like to know whether the signature of the tag and the detached signature meet the expectations.

I am still unsure whether this change is necessary. If I go along with it, I will not retroactively sign the r3.0 release, I will sign the upcoming r3.1 release instead. I am planning to release r3.1 relatively soon.

[ainola]

Yep, it works!

I am still unsure whether this change is necessary. If I go along with it, I will not retroactively sign the r3.0 release, I will sign the upcoming r3.1 release instead. I am planning to release r3.1 relatively soon.

It's really greatly appreciated to do that for the protection of users and establish the network of trust. As your code flows into our distros for packaging it's important to keep the supply chain protected and trustworthy.