Re: passing CURLOPT_CERTTYPE to libcurl

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Junio & Florian,

On Fri, 17 Dec 2021, Junio C Hamano wrote:

> Florian Mickler <florian@xxxxxxxxxxx> writes:
>
> > Is there a specific reason, that patch wasn't merged? It would allow
> > for non-pem ssl certificates to be loaded also (without pkcs11 at all).
> >
> > I realize, that the underlying systems could and should set up
> > everything automagically as soon as i point them to the certificate that
> > i want to use. But not opening up these CURL Settings from git seems
> > kind of silly given that today's systems still seem kinda borked and do
> > not do that.  What harm comes from these two tuning knobs being exposed?
> >
> > Best regards,
> > Flo
> >
> >
> > [1] https://marc.info/?l=git&m=136675822032549&w=2

This corresponds to
https://lore.kernel.org/git/1366758207-7724-1-git-send-email-jqassar@xxxxxxxxx/
(for those who prefer lore.kernel.org over marc.info, and for those who
want to look for the Message-ID directly).

My summary of that thread:

- The patch implements something Git wants to support.

- A couple of improvements need to be made, such as:

  * Error-checking needed to be improved

  * Adding a hint to the documentation of `http.sslKeyType` being set to
    `ENG` causing `http.sslKey` being interpreted differently.

  * Adding regression tests, if possible

  * Maybe a more complete commit message?

- Testing the smart card support was considered hard, especially given
  that the contributor still wanted to contribute patches to cURL without
  which it wouldn't work.

  The patch seems to have been contributed via
  https://curl.se/mail/lib-2013-04/0340.html, been reviewed and changes
  were requested, but there was no other patch submission that I could
  find.

  However, over five years later, what looks like an equivalent fix to me
  was applied:
  https://github.com/curl/curl/commit/4939f3652473c1519d2b604068efb87ef7531874

- The contributor, Jerry Qassar, gave all the signs of working on a
  next iteration ("reroll", as Junio likes to call it). But that never
  materialized, either:

  https://lore.kernel.org/git/?q=f%3Ajqassar

  Based on this, the lack of a cURL contribution, and a quick web search
  for the name "Jerry Qassar" I somehow doubt that Cc:ing them might
  raise their attention.

> Almost always, when some patch aims to achieve a worthy goal, and in
> the initial discussion on the thread more experienced project
> members agree it is a worthwhile thing to do, the only reason why
> the feature proposed does not materialize in later versions of Git
> is because the developer with the original itch did not follow it
> through after getting review comments and saying something that
> makes reviewers to expect an updated version of the patch.
>
> I didn't follow your marc.info URL, but I am reasonably sure, if I
> were involved in the discussion, that would be the likely reason.

Yes, you were involved in the discussion, and indeed, there was no
follow-up.

After more than 8 years, I do believe that the patch is fair game to be
picked up by any other interested contributor who might want to contribute
v2 (hint, hint, Florian... all it would take is to study the mail thread
from way back when and adapt the patch accordingly, of course after
rebasing it to a recent Git revision).

Ciao,
Dscho




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux