Jeff King venit, vidit, dixit 16.06.2016 11:25: > On Wed, Jun 15, 2016 at 09:17:54AM +0200, Michael J Gruber wrote: > >> 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. > > Does it? I haven't run it in production, but I did some tests with gpgsm > a few months ago and found it to be a drop-in replacement, at least with > respect to git. Though I don't think that matters one way or the other > for the current discussion; it _does_ do --status-fd.
You are right! I solely trusted in the documentation rather than simply trying it out. gpgsm even supports the undocumented short options. Only the resulting header is different (plus the fact that I have to turn of crl checks for whatever reason). >> 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. > > Fair enough. I've generally found its exit code pretty reliable. It's > unclear to me if the problem you saw was because gpg was exiting 0 but > producing no signature, or if your debugging was masking its exit code. > > Either way, I do not mind using --status-fd; it seems like it should be > more robust in general. It's the tip commit in the series I'm about to > post. > >> 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. > > Yeah, you're right that the deadlock thing is also a possibility on the > verification side. I'm not sure whether it's possible to trigger in > practice or not. See the analysis in the series. With great admiration I've looked at your series which solves this problem at the root. Way above my head (the solution, not the root, fortunately). >> 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. > > Yep, I agree. > > -Peff > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
