FS#41147 - pacman-key -- gpg status parsing not strict enough
Attached to Project:
Pacman
Opened by Mantas Mikulėnas (grawity) - Wednesday, 09 July 2014, 20:22 GMT
Last edited by Allan McRae (Allan) - Thursday, 25 September 2014, 01:06 GMT
Opened by Mantas Mikulėnas (grawity) - Wednesday, 09 July 2014, 20:22 GMT
Last edited by Allan McRae (Allan) - Thursday, 25 September 2014, 01:06 GMT
|
Details
Currently, pacman-key has the following in verify_sig():
if ! "${GPG_PACMAN[@]}" --status-fd 1 --verify "$sig" | grep -qE 'TRUST_(FULLY|ULTIMATE)'; then error "$(gettext "The signature identified by %s could not be verified.")" "$sig" ret=1 fi This check can be very easily spoofed, since it doesn't make sure that TRUST_FULLY is the field name, and not the value. Meaning, there are at least two ways to get any string in gpg's output: a) create a key and enter "TRUST_FULLY" when prompted for the full name; b) attach a notation (gpg --set-notation TRUST_FULLY@example.com=ponies --sign); gpg prints the value hex-encoded, but the name in plain. Instead, pacman-key should check for /^\[GNUPG:\] TRUST_(FULLY|ULTIMATE)$/; that is: 1) only accept --status-fd output ("[GNUPG:]" prefix) and not the human-readable output, 2) require "TRUST_*" to be the 2nd word in the line, immediately after "[GNUPG:]" |
This task depends upon
Closed by Allan McRae (Allan)
Thursday, 25 September 2014, 01:06 GMT
Reason for closing: Fixed
Additional comments about closing: git commit 879e4665c
Thursday, 25 September 2014, 01:06 GMT
Reason for closing: Fixed
Additional comments about closing: git commit 879e4665c
Comment by
Mantas Mikulėnas (grawity) -
Wednesday, 09 July 2014, 20:24 GMT
(The bit about notation values being hex-encoded? I was mistaken,
it's in plain too.)