Jeff King venit, vidit, dixit 15.06.2016 02:56: > On Tue, Jun 14, 2016 at 04:47:35PM -0700, Junio C Hamano wrote: > >> Jeff King <peff@xxxxxxxx> writes: >> >>> I'm still undecided on whether it is a better approach than making >>> sure the stdout we got looks sane. In particular I'd worry that it >>> would make things harder for somebody trying to plug in something >>> gpg-like (e.g., if you wanted to do something exotic like call a >>> program which fetched the signature from a remote device or >>> something). But it's probably not _that_ hard for such a script >>> to emulate --status-fd. >> >> I share the same thinking, but at the same time, it already is a >> requirement to give --status-fd output that is close enough on the >> signature verification side, isn't it? > > Yeah, though I could see somebody wanting to sit amidst the signing side > but not verification (e.g., if your keys are elsewhere from the machine > running git). Of course such a case could probably ferry --status-fd > from the other side anyway. > > I admit I don't know of such a case in practice, though, and > implementing a rudimentary --status-fd to say "SIG OK" or whatever on > the signing side is not _that_ big a deal. So if we think this approach > is a more robust solution in the normal case, let's not hold it up over > what-ifs. > > -Peff As for the flexibility: We do code specifically for gpg, which happens to work for gpg2 also. The patch doesn't add any gpg ui requirements that we don't require elsewhere already. More flexibility requires a completely pluggable approach - gpgsm already fails to meet the gpg command line ui. In any case, "status-fd" is *the* way to interface with gpg reliably just like plumbing commands are *the* way to interface with git reliably. As for the read locking: I'm sorry I have no idea about that area at all. I thought that I'm doing the same that we do for verify, but apparently not. My strbuf_read-fu is not that strong either (read: copy&paste). I trust your assessment completely, though. As for the original problem: That had a different cause, as we know now (rebase dropping signatures without hint). I still think we should check gpg status codes properly. 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