Consider signing tags and commits
Feature Request
Is your feature request related to a problem? Please describe. As the package maintainer of this in Arch Linux I would appreciate to maintaining the chain of trust with PGP signatures on commits / tags. This can be handled from the Arch Linux package manager natively and can validate the tag / commit against the PGP public key of the author of the commit.
Describe the solution you'd like
- Sign both commits and tags at least during releases but preferably all.
- Mention the public keys used for signing those releases in README so downstream systems can validate independently.
- Add any new maintainers who can release on the above list.
Describe alternatives you've considered Not validating the release is not optimal from security POV.
Teachability, Documentation, Adoption, Migration Strategy Users are unaffected but benefit from the implied security that the a package provide on their distribution.
Hi @inglor and thanks for opening the issue!
We are super excited to get memray packaged for Arch Linux (I use Arch myself) so let us help with anything we can :)
Regarding signing tags and commits, we currently don't mandate it (many commits are not signed) but I have been signing the releases. For example:

This GPG signature is the same I use as CPython release manager (check out the "PGP public keys" section in here).
We will surely discuss signed commits but for the time being, do these signed releases work for you?
Maybe I am missing something, though.
Hey @pablogsal
It's great news you use Arch Linux :+1:
For the signing I think it would be better to sign both commit and tag as you did on previous release 1.0.2.

I use git config --global commit.gpgsign set to true to sign everything but I understand if this is not feasible (especially if handling PRs from the web interface).
Signing the tag is the minimum for pacman to validate the tag when building the pacakge.
As for the GPG I think something like that (CPython section) on this repo would be great! :)
@inglor I noticed the Arch package is missing some dependencies:
Particularly all the python packages seem to be missing:
https://github.com/bloomberg/memray/blob/7862de45c709ee47ba1708445d93aa60c4b2c48a/setup.py#L83-L87
And indeed this causes the package to not work:
sudo pacman -S memray
resolving dependencies...
looking for conflicting packages...
Packages (1) memray-1.0.3-3
Total Download Size: 0.76 MiB
Total Installed Size: 3.84 MiB
:: Proceed with installation? [Y/n]
:: Retrieving packages...
memray-1.0.3-3-x86_64 783.2 KiB 14.2 MiB/s 00:00 [###############################################] 100%
(1/1) checking keys in keyring [###############################################] 100%
(1/1) checking package integrity [###############################################] 100%
(1/1) loading package files [###############################################] 100%
(1/1) checking for file conflicts [###############################################] 100%
(1/1) checking available disk space [###############################################] 100%
:: Processing package changes...
(1/1) installing memray [###############################################] 100%
:: Running post-transaction hooks...
(1/2) Arming ConditionNeedsUpdate...
(2/2) Refreshing PackageKit...
❯ memray -h
Traceback (most recent call last):
File "/usr/bin/memray", line 5, in <module>
from memray.__main__ import main
File "/usr/lib/python3.10/site-packages/memray/__main__.py", line 3, in <module>
from memray.commands import main
File "/usr/lib/python3.10/site-packages/memray/commands/__init__.py", line 18, in <module>
from . import live
File "/usr/lib/python3.10/site-packages/memray/commands/live.py", line 6, in <module>
from rich.layout import Layout
ModuleNotFoundError: No module named 'rich'
@pablogsal hmm I guess I had all those installed on my system and doesn't seem to be makedepends but rather runtime.
Check for 1.0.3-4 version to hit the repos soon with
depends=('python' 'libunwind' 'python-rich' 'python-jinja')
I'm closing this issue as we are already signing tags. We are unlikely to sign all commits but I personally do with mine.