While reviewing v5.0.4 before upgrading, I traced the full trust chain and noticed one consistent gap:
- ✅ The security-fix commit 025fe21 is signed (via the GitHub Security Advisory UI).
- ❌ The release-bump commit 9ea459d (lib/devise/version.rb -> 5.0.4) is unsigned.
- ❌ The annotated tag v5.0.4 is unsigned.
Same pattern on v5.0.3, v5.0.2, v5.0.1: code commits that go through the GitHub UI land signed, but the locally-pushed release bump and tag are not. So GitHub-side artifacts are covered; the gap is purely at the localhost step.
Given Devise's reach into security-sensitive Rails apps, signing the release commit and tag would meaningfully defend against GitHub-account compromise, and it gives reviewers and incident responders a maintainer-signed record of the source tree corresponding to each release, independent of GitHub or RubyGems infrastructure.
The asks:
- Sign maintainer commits and annotated tags going forward.
- Enable the "Require signed commits" ruleset on main to make the policy self-enforcing. (Doesn't cover tags -- GitHub has no equivalent enforcement for annotated tags)
Thanks for everything you do on Devise -- we've used it for many years and it has been an amazing tool for us!
While reviewing v5.0.4 before upgrading, I traced the full trust chain and noticed one consistent gap:
Same pattern on v5.0.3, v5.0.2, v5.0.1: code commits that go through the GitHub UI land signed, but the locally-pushed release bump and tag are not. So GitHub-side artifacts are covered; the gap is purely at the localhost step.
Given Devise's reach into security-sensitive Rails apps, signing the release commit and tag would meaningfully defend against GitHub-account compromise, and it gives reviewers and incident responders a maintainer-signed record of the source tree corresponding to each release, independent of GitHub or RubyGems infrastructure.
The asks:
Thanks for everything you do on Devise -- we've used it for many years and it has been an amazing tool for us!