Release 1.25.1 missing usual GPG signature
lmartinez-mirror opened this issue · 6 comments
Hi, I maintain pyresample (soon to be python-pyresample) on the AUR. I wanted to let you know that the latest release does not contain a unique GPG signature. Arch packaging guidelines state that if upstream signs their sources, we are advised to use them to verify; we cannot skip verification for any releases, in that case.
Please sign your releases, I'd greatly appreciate it! Thanks for your time!
Hi, thanks for filing the issue. I'm interested in adding this to our packaging, but would it be possible for you to give advice on how to enable it for our existing workflow of using Github Actions and the PyPI upload action we use: https://github.com/pypa/gh-action-pypi-publish
You say that the latest release was not signed, but does that mean previous releases were?
Also, what is AUR?
Hi, thanks for filing the issue. I'm interested in adding this to our packaging, but would it be possible for you to give advice on how to enable it for our existing workflow of using Github Actions and the PyPI upload action we use: https://github.com/pypa/gh-action-pypi-publish
Unfortunately I'm not too experienced with GitHub actions. I imagine it'd be just adding another line that signs the tags before publishing.
You say that the latest release was not signed, but does that mean previous releases were?
Mostly, yes. Your releases up until 1.25.1 were signed using your GPG key. 1.25.1 was only signed with GitHub's web-flow key (though this is a valid GPG key, I'd trust a key from the maintainers themselves more).
Also, what is AUR?
AUR stands for Arch User Repository, a separate repo from Arch Linux's. Users can submit packages of their own for distribution. Someone had packaged this project in the past; I simply took over as maintainer.
Thanks for the report! I have to admit I didn't know about GPG signing in pypi packages before you brought it up here, that's really nice to know.
I can see that the last commit in 1.25.1 is the merge of pr #447, and that the changelog file was not modified as we do usually. It's not a big deal in itself, but I suspect that means the commit on which the tag/release is base has thus been pushed by github (as the merge has been done online) instead of the changelog update by a maintainer as we usually do. Do that sound right? In which case the fix would be simple on our side.
@mraspaud Ah so you're saying since I merged a PR and put the tag on that commit instead of the last commit being the CHANGELOG commit....wait how did I not update the CHANGELOG? I remember doing it. Sorry everyone. This should have been simple. I'll clean things up. I don't think I'll release a 1.25.2 just for this issue though if that's OK with everyone. We probably have an actual 1.25.2 coming up soon with a few bug fixes anyway.
pyresample$ git status
On branch main
Your branch is up to date with 'origin/main'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: CHANGELOG.md
🤦♂️
no worries! next release is good.