"Robin H. Johnson" <robbat2@xxxxxxxxxx> writes:
> Format string %G? includes state 'N', which is described as "no
> signature".
>
> If you try to verify a commit or push for which you have no key (and you
> don't automatically fetch from the keyservers [1]), then the format
> string ALSO contains 'N', which is incorrect.
>
> It should be possible to differentiate between a commit/push with NO
> signature, and a commit/push signed with an unknown key.
>
> In the case of verifying signed pushes before accepting them, this is
> critical to providing a useful error message to the user. Presently, if
> %G? evaluates to 'N', then none of the GIT_PUSH_CERT* env vars are set.
Hrm, I think GIT_PUSH_CERT* environment variables are exported
whenever push_cert_sha1[] is not "0"{40}, and push_cert_sha1[] is
cleared only when write_sha1_file() fails. The failure from calling
parse_signature(), verify_signed_buffer() and parse_gpg_output()
does not clear push_cert_sha1[], so I am not sure if we are reading
the same code.
Are you talking about something other than prepare_push_cert_sha1()?
> In the case of the signed push with the unknown key, they should remain
> set.
In any case, I think "should" is relative to the balance between
convenience and safety. If you set up your receiving end to use a
keyring that holds trusted keys and nothing else, it makes it harder
to make mistakes in the script and accept something you shouldn't if
the validation script is fed "No, this is not good" if a push is
signed by unknown key, so showing "known to be bad" and "unsure if
it is good" the same way with 'N' is what "should" happen from that
point of view.
Of course, a set-up that fetches unknown keys lazily when they are
first encountered would need more work to do the verification
themselves, but as long as GIT_PUSH_CERT itself is exported that
should be possible (iow, we are trying to make simple way less error
prone, while allowing more advanced use possible, if harder).
If the blob object name is not exported depending on the validation
status, that certainly sounds like a bug, as that would make "more
advanced use" above impossible. But I am not sure how that happens.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html