Mark Lodato <lodatom@xxxxxxxxx> writes: > This brings up a good point: Should we (I) try to implement (client > certificate) usability features in git to work around deficiencies in > libcurl, or should we (I) write patches to fix/enhance libcurl > directly? The latter would be much easier (though I could be wrong) > and would benefit other programs using libcurl, but would require > users to upgrade libcurl to get these new features, and of course > would rely on the libcurl developers accepting the patches. I am > willing to do either, but I think the libcurl route would be better. > Any thoughts? I agree that would be a better approach in the longer term. There is no point in many projects that use libcURL reinventing the wheel that could be in the shared library. Perhaps we could do both ;-). That is, (1) give libcURL a way to allow callers ask if the key/cert is encrypted, and then (2) on git side we only add code to ask libcURL using that interface _only if and when available_; otherwise we do not even try to bypass layers but just ask the user to tell us via configuration (or command line). -- 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