{"thread":{"id":"59626","subject":"Re: [PATCH v2] http: document sslcert and sslkey types and extend to proxy","startedAt":"2023-04-20T22:24:19Z","lastAt":"2023-04-20T22:24:19Z","messageCount":1,"participants":["Davidson, Ricky (HII-Mission Technologies)"],"isPatch":true,"patchVersion":2,"patchTotal":null},"messages":[{"id":"475767","messageId":"BN0P110MB11787766D6BB6BF2022DB025DB639@BN0P110MB1178.NAMP110.PROD.OUTLOOK.COM","threadId":"59626","inReplyTo":null,"subject":"Re: [PATCH v2] http: document sslcert and sslkey types and extend to proxy","fromName":"Davidson, Ricky (HII-Mission Technologies)","fromEmail":"ricky.davidson@hii-tsd.com","sentAt":"2023-04-20T20:51:24Z","receivedAt":"2023-04-20T22:24:19Z","isPatch":true,"sender":{"key":"ricky.davidson@hii-tsd.com","avatar":null},"body":"> I think it is the first time we see your patches around here.\n> Welcome to Git developer community.\n\nFirst time, yes thank you. I'm also not able to use a client that \nnormally allows setting headers like in-reply-to (I am hoping mailto: \nworks here), so I am hoping this works, and I will take any advice on \nthat situation if possible.\n\n> I wonder if we can add some tests for the feature, though.\n\nI would love if there was a way to test it. But my historical \nunderstanding of this issue is that it has been repeatedly not merged \nin due to lack of anyone knowing how to test it, given the nature of \na hardware token (what this is especially focused at explicitly \nenabling) generally being hardware. Technically, I am sure pkcs11 can \napply to software tokens, but I have never ventured the topic. I'm \nalso aware KVM+Qemu+Libvirt allows creating virtual smart cards, but \nI also have not ventured that topic. I have been following this issue \nsince May of last year in private support tickets, and I do not feel \nI am able to contribute anything that has not already been pondered \nover this issue. I strongly welcome ideas, though.\n\n0a01d41e (http: add support for different sslcert and sslkey types., \n2023-03-20) does solve our main issues (which is absolutely \nwonderful), and this is only to finish it up with documentation, and \nproxySSLCertType does not personally affect me, so I am not bothered \nwith the wait associated first consulting on proper testing. \nAlthough, it would be a shame to see this fail to get pushed in again.\n\nThanks,\nRicky Davidson\n"}]}