On March 29, 2022 1:26 PM, Fabian Stelzer wrote: >On 29.03.2022 11:44, rsbecker@xxxxxxxxxxxxx wrote: >>On March 16, 2022 12:45 PM, I wrote: >>>On March 16, 2022 12:27 PM, Fabian Stelzer wrote: >>>>On 16.03.2022 10:34, rsbecker@xxxxxxxxxxxxx wrote: >>>>>Following up on our IRC discussion on Monday, I have had a request >>>>>to support signing git commits and tags with SSL certificates >>>>>instead of SSH/GPG. The organization is heavily invested in SSL >>>>>infrastructure, so they want to go down that path. >>>>> >>>>>The basic technique for doing this is, for example: >>>>> >>>>>openssl dgst -sha256 -sign key -out content.sha256 signature.txt >>>>>-passin passphrase >>>>> >>>>>There is a pre-step to compute the sha256, in this example, into a >>>>>file provided to openssl. We could use openssl to compute the hash also. >>>>> >>>>>Verification is a bit different than what SSH or GPG does: >>>>> >>>>>openssl dgst -sha256 -verify <(openssl x509 -in certificate -pubkey >>>>>-noout) -signature sign.txt.sha256 signature.txt >>>>> >>>>>and reports either >>>>> >>>>>Verified OK >>>>>Or >>>>>Verification Failure >>>>> >>>>>It does not look like completion codes are consistently involved. >>>>> >>>>>This also does look structurally different than both GPG and SSH and >>>>>more work to set up. It may be possible to provide wrappers and >>>>>pretend we are in SSH, but I'm not sure that is the right path to take. >>>>> >>>>>Any pointers on how this might be done in existing git >>>>>infrastructure, or should I look into making this work in code? >>>>>Sorry to say that the documentation is not that clear on this. >>>> >>>>Why not gpgsm? It can deal with x509 certs and is already supported. >>>>I am using this to do s/mime signing/encryption with an yubikey >>>>hardware token but static certs/keys should be even simpler. However >>>>I'm not sure how good this works on other platforms. >>>> >>>>Take a look into the GPGSM prereq in t/lib-gpg.sh for a few hints on >>>>how to set this up. >>> >>>Good idea but this is a non-starter. I have a limit of GPG 1.4, which >>>only has the single legacy object. GPG added a dependency to mmap, >>>which is not available on any of my platforms. That was one reason we were so >happy to have SSH support. >> >>I have been investigating this capability in more depth. After discussing with >OpenSSL, explicitly adding SSL signing to git would introduce CVE-2022-0778 into git >and allow a hostile upstream repo to introduce a deliberately defective key that >could trigger this CVE unless customers have patched OpenSSL. Given the lack of >broad-based adoption of the fixes to this point, I am reluctant to pursue this >capability at this time. (Actually referencing my own advice in Git Rev News 82). >The impact on git would be looping processes when signatures are evaluated. This >would break workflows that depend on signed content and have downloaded >keys with the CVE attributes. >> >>Does anyone agree/disagree with me on delaying this? >>--Randall >> > >Do you actually need SSL Signing so you can verify commits with a single CA key? >Or do you have all the certs public keys anyway? > >I know quite a few setups where every employee is issued an x509 cert (often PIV >Certs, preferably on a smartcard/token) and a central ldap is available with all >issued certs. This is usually used for authentication and s/mime. > >However this can easily be used with ssh signing as well. I do so myself. I use my >own s/mime cert loaded into an ssh-agent (pkcs11 smartcard) to sign commits and >generate an allowed signers file with all the pubkeys extracted from the certs i get >from the PKIs ldap server. I would prefer to use SSH - mostly because I am much more comfortable in that space - but SSH has not been authorized for use at this customer. They are a pure SSL shop with each developer having their own SSL unique cert based on the internal corporate CA (as they explained it). I don't have info at this point on the type of cert they are using. Signing is desired to be done by each developer/operator with their own private cert. The vulnerability is that if SSL certs are used for signatures and a hostile cert gets in via an SSL path. it can trigger the CVE, according to the OpenSSL team.
