Junio C Hamano venit, vidit, dixit 14.06.2015 23:23: > "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > >> Currently, verify-commit and verify-tag produce human-readable output. >> This is great for humans, and awful for machines. It also lacks a lot >> of the information that GnuPG's --status-fd output provides. >> >> For example, if you wanted to know >> * the hash algorithm; >> * whether the signature was made with a subkey; or >> * the OpenPGP signature version >> none of that information is available in the human-readable output. > > What this series wants to achieve makes a lot of sense to me. One > comment I have after skimming the patfches is that I want the new > "raw" bit added not as a yet another parameter after "verbose", but > by turning the existing "verbose" into an "unsigned flag" flag word > (with "#define GPG_VERIFY_VERBOSE 01") and then defining use of a > new bit in the same flag word "#define GPG_VERIFY_RAW 01" or > something. That way, over time other people add differnt things to > the interface, we would not have to end up with 47 different > parameters each of which signals a single bit. > > Thanks. Back then the idea was to have verify-commit available *yesterday* (before any refactoring) since we needed a way to verify the new commit signatures programmatically. Maybe now would be a good time to do the refactoring between verify-tag and verify-commit that is still missing, and to add new features then (unless they are pressing matters or fixes). BTW: verify-tag and verify-commit should treat untrusted good signatures in exactly the same way. Anything else is an error that needs to be fixed. Michael -- 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