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.

[enkore]

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.

The project is 100% with meator and he's done great. Thank you @meator

@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.

It's your project and should be your key :)

I did went looking for my old GPG key but I might have lost it. If I do find it I would cross-sign your key for whatever that's worth. I know I promised to be more involved in the transition than "not at all" and apologize for pretty much just ghosting you. I honestly would like to do more open source hacking again aside from some very inconsequential work-related stuff once a year (what you saw in your feed) but it hasn't been working out for a long while.

[ainola]

Thanks for the new release and the signed artifacts! I appreciate you doing this.

[n-peugnet]

@meator: Hi, I just sent you an email but I'll post also here in case it went in the SPAM folder. I tried to obtain the public key used to sign the last release. I managed to do so using keyserver.ubuntu.com or pgp.mit.edu key servers, but this key expired a few days ago. Could you please update the expiration date and re-upload it to these key servers?

[meator]

@n-peugnet Your e-mail has indeed gone to my spam. I have now uploaded my key to keyserver.ubuntu.com. I'm getting time outs on pgp.mit.edu, so I haven't uploaded it there. My public key is also accessible at https://github.com/meator.gpg.

Thank you for taking a look at the Debian package! 2.16 is quite old now. It might be worth waiting a bit, I've been thinking about cutting a new release r3.2 soon-ish. I want to address #181

[n-peugnet]

@meator: thank you, I managed to correctly verify the release with your updated key.

Thank you for taking a look at the Debian package! 2.16 is quite old now. It might be worth waiting a bit, I've been thinking about cutting a new release r3.2 soon-ish.

Don't worry about this, for now I am only in the process of salvaging the package, upgrading it to the latest version will take more time 😄

P.S. if you could move my email out of the spam folder and/or reply to it, it would help my server's reputation 😅

[ottok]

In future releases, could you please create the signatures using command gpg --armor --detach-sig?

Having signatures in ASCII format is the industry standard, and using suffix .asc. The current .sig files are pure binary.

[meator]

@ottok Is the fact that the signatures aren't armored and that they don't end in .asc causing problems in Debian or anywhere else?

When I started signing releases again, I took great care in making sure that I did it in the exact same way enkore did it. I want the verification process to work the same way it did for r2.18 and earlier releases. The only change is that the releases are signed with 7B0F58A5E0F1A2EA11578A731A14CB3464CBE5BF instead of A1774C1B37DC1DCEDB65EE469B8450B91D1362C1 (which is outside my control as described earlier in this thread).

I assume that (some) distributors which validate the release files using the .sig file fetch it like so:

https://github.com/enkore/j4-dmenu-desktop/releases/download/r${version}/r${version}.tar.gz.sig

changing it to .asc would mean that this link would return 404 not found for the upcoming release r3.2 and for future releases. I don't see any benefit in making this change + it would make updating existing packages more difficult (but not by much, a packager updating j4-dmenu-desktop would likely notice this change and fix it swiftly).

Using --armor is less of a breaking change, but I am still hesitant to use it because the current detached signatures work well and I don't see how adding --armor would improve things.

[n-peugnet]

Honestly it is really not a problem for Debian packaging.

@ottok: it seems uscan correctly armors the signature when renaming it from .sig to .asc and gpb correctly imports the signature in the pristine-tar branch. So the process is really streamlined.

I agree with @meator, renaming or changing it would most likely force distributions to update their process, including our debian/watch.

[ottok]

OK, I wasn't aware that uscan converts .sig to .asc automatically, then it isn't an issue for Debian.