Thread (7 messages) flat view 7 messages, 3 authors, 2016-06-15

Re: [PATCH 2/2] http.c: add http.sslCertType and http.sslKeyType

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:46:57

Mark Lodato [off-list ref] 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).
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help