You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@magpie.apache.org by "liwenjie200543 (via GitHub)" <gi...@apache.org> on 2026/10/15 12:49:54 UTC
[PR] fix(keys-sync): require a compliant signing-capable key for the verdict [magpie]
liwenjie200543 opened a new pull request, #1635:
URL: https://github.com/apache/magpie/pull/1635
## What
`keys-sync` Step 1 (`check_key.py`) now requires a usable, strength-compliant **signer**, not just a strong primary key:
- `parse_colons()` records subkeys and the gpg colons capability flags (field 12), and attaches each subkey's fingerprint.
- The verdict additionally requires a signing-capable key: a primary key whose capabilities lack `s` (certify only) no longer counts as a signer on its own, and a signing subkey only counts when it independently meets the existing algorithm/size floor, validity and expiry rules.
- The compliant signers are reported in a new `signers` field; listings without capability fields (older synthetic fixtures) keep the previous behaviour.
## Why
Fixes #1628 (helper layer). Previously a certify-only Ed25519 primary with an RSA-1024 signing subkey got `verdict: proceed` with `strength_check: pass`, because only the primary's strength was assessed — the helper's own floor was bypassed by the actual signer.
## How checked
- `python -m unittest discover -s plugins/magpie-release-management/skills/keys-sync/tests` — 40/40 pass (8 new `SignerAdmissionTest` cases cover the issue's reproduction shape: certify-only primary + weak/missing/expired/compliant signing subkey).
- `ruff check` and `ruff format --check` pass on both files.
- Fixtures use the real gpg colons field layout (capabilities at 0-based index 11, curve at 16) per GnuPG `doc/DETAILS`.
Scope note: this changes only the helper's admission rules; the broader workflow proposal (binding `rc-cut` signing to the validated key via `--local-user`) is left as the separate discussion the issue describes.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@magpie.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix(keys-sync): require a compliant signing-capable key for the verdict [magpie]
Posted by "potiuk (via GitHub)" <gi...@apache.org>.
potiuk commented on PR #1635:
URL: https://github.com/apache/magpie/pull/1635#issuecomment-6206032488
Pushed a fixup (maintainer edit) before merge, after review and a roborev pass:
- Capability letters keep their case. GnuPG reports uppercase aggregate capabilities for the primary key (for example `cSC` for a certify-only primary whose subkey signs), and lowercasing them made such a primary count as a signer. Only a lowercase `s` now admits the primary.
- Admitted signing subkeys now carry the DSA and 90-day expiry advisories in `strength_note`, as the keys-sync skill's Step 1 describes.
- Added regression tests for all three cases; the keys-sync tests pass and CI was green.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@magpie.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix(keys-sync): require a compliant signing-capable key for the verdict [magpie]
Posted by "potiuk (via GitHub)" <gi...@apache.org>.
potiuk merged PR #1635:
URL: https://github.com/apache/magpie/pull/1635
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@magpie.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org