search

laminas / automatic-releases

Automated release process for `laminas/` projects, usable as github action
Other
141 stars 23 forks source link

Refactor gpg import to use machine readable colon format #256

Open Xerkus opened 9 months ago

Xerkus commented 9 months ago
Q A
Documentation no
Bugfix yes
BC Break no
New Feature no
RFC no
QA yes

Description

Current gpg import uses unstable gpg output to determine if key was imported and to get imported key id.

Unstable format is unreliable, for example gpg 2.4.3 on my machine outputs gpg: key 0x8CA5C026AE941316: secret key imported line that would not match existing regex due to 0x prefix in key id. This is not encountered with gpg used by action but I would call it a bug.

This PR is refactoring gpg key import to use colon delimited machine readable format. Information can be found at https://github.com/gpg/gnupg/blob/master/doc/DETAILS

Additional improvements are to guard against adding keys that do not have secret keys or subkeys with sign capability. Expired keys could cause gpg sign to fail anyway but I do not know how reliable expiry information is in gpg import output.

Xerkus commented 9 months ago

I was wrong. gpg --export-secret-subkeys exports primary as stub gnu-dummy. That means primary secret key is always reported as available.

Combination of public primary plus secret subkeys is not realistic, removing check for that.

Stub can not be distinguished from real secret key when using --with-colons listing. That stub is listed as sec# in human readable output when listing keys but not during import.

Subkeys with no secrets are exported as secret stubs as well.

Stub could be detected via --list-packets but imo not worth it.

Extra guards for key validity I added originally are in effect useless, removed them. If key can be imported but has any issues signing it will fail to sign release couple seconds later anyway. Extra checks here would only provide a bit of verbosity at best.