{"thread":{"id":"57571","subject":"[RFE] Signing using SSL","startedAt":"2022-03-16T14:34:15Z","lastAt":"2022-03-29T17:36:22Z","messageCount":7,"participants":["rsbecker@nexbridge.com","Fabian Stelzer","'Fabian Stelzer'"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"451473","messageId":"036701d83942$e6963ca0$b3c2b5e0$@nexbridge.com","threadId":"57571","inReplyTo":null,"subject":"[RFE] Signing using SSL","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2022-03-16T14:34:05Z","receivedAt":"2022-03-16T14:34:15Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"Following up on our IRC discussion on Monday, I have had a request to\nsupport signing git commits and tags with SSL certificates instead of\nSSH/GPG. The organization is heavily invested in SSL infrastructure, so they\nwant to go down that path.\n\nThe basic technique for doing this is, for example:\n\nopenssl dgst -sha256 -sign key -out content.sha256 signature.txt -passin\npassphrase\n\nThere is a pre-step to compute the sha256, in this example, into a file\nprovided to openssl. We could use openssl to compute the hash also.\n\nVerification is a bit different than what SSH or GPG does:\n\nopenssl dgst -sha256 -verify  <(openssl x509 -in certificate -pubkey -noout)\n-signature sign.txt.sha256 signature.txt\n\nand reports either\n\nVerified OK\nOr\nVerification Failure\n\nIt does not look like completion codes are consistently involved.\n\nThis also does look structurally different than both GPG and SSH and more\nwork to set up. It may be possible to provide wrappers and pretend we are in\nSSH, but I'm not sure that is the right path to take.\n\nAny pointers on how this might be done in existing git infrastructure, or\nshould I look into making this work in code? Sorry to say that the\ndocumentation is not that clear on this.\n\nThanks in advance,\nRandall\n\n--\nBrief whoami: NonStop&UNIX developer since approximately\nUNIX(421664400)\nNonStop(211288444200000000)\n-- In real life, I talk too much.\n\n\n\n"},{"id":"451477","messageId":"036901d83945$0e9c98a0$2bd5c9e0$@nexbridge.com","threadId":"57571","inReplyTo":"036701d83942$e6963ca0$b3c2b5e0$@nexbridge.com","subject":"RE: [RFE] Signing using SSL","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2022-03-16T14:49:31Z","receivedAt":"2022-03-16T14:49:48Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On March 16, 2022 10:34 AM, I forgot to mention:\n>Following up on our IRC discussion on Monday, I have had a request to\nsupport\n>signing git commits and tags with SSL certificates instead of SSH/GPG. The\n>organization is heavily invested in SSL infrastructure, so they want to go\ndown that\n>path.\n>\n>The basic technique for doing this is, for example:\n>\n>openssl dgst -sha256 -sign key -out content.sha256 signature.txt -passin\n>passphrase\n>\n>There is a pre-step to compute the sha256, in this example, into a file\nprovided to\n>openssl. We could use openssl to compute the hash also.\n>\n>Verification is a bit different than what SSH or GPG does:\n>\n>openssl dgst -sha256 -verify  <(openssl x509 -in certificate -pubkey\n-noout) -\n>signature sign.txt.sha256 signature.txt\n>\n>and reports either\n>\n>Verified OK\n>Or\n>Verification Failure\n>\n>It does not look like completion codes are consistently involved.\n>\n>This also does look structurally different than both GPG and SSH and more\nwork to\n>set up. It may be possible to provide wrappers and pretend we are in SSH,\nbut I'm\n>not sure that is the right path to take.\n>\n>Any pointers on how this might be done in existing git infrastructure, or\nshould I\n>look into making this work in code? Sorry to say that the documentation is\nnot that\n>clear on this.\n\nIt looks like there probably needs to be come configuration support\nincluding things like httpVerify=false for self-signed certs, certificate\nstore paths, etc., to support SSL infrastructure.\n\n"},{"id":"451481","messageId":"20220316162711.wfcavqpg2w4u7fat@fs","threadId":"57571","inReplyTo":"036701d83942$e6963ca0$b3c2b5e0$@nexbridge.com","subject":"Re: [RFE] Signing using SSL","fromName":"Fabian Stelzer","fromEmail":"fs@gigacodes.de","sentAt":"2022-03-16T16:27:11Z","receivedAt":"2022-03-16T16:27:19Z","isPatch":false,"sender":{"key":"fs@gigacodes.de","avatar":"https://avatars.githubusercontent.com/u/564858?v=4"},"body":"On 16.03.2022 10:34, rsbecker@nexbridge.com wrote:\n>Following up on our IRC discussion on Monday, I have had a request to\n>support signing git commits and tags with SSL certificates instead of\n>SSH/GPG. The organization is heavily invested in SSL infrastructure, so they\n>want to go down that path.\n>\n>The basic technique for doing this is, for example:\n>\n>openssl dgst -sha256 -sign key -out content.sha256 signature.txt -passin\n>passphrase\n>\n>There is a pre-step to compute the sha256, in this example, into a file\n>provided to openssl. We could use openssl to compute the hash also.\n>\n>Verification is a bit different than what SSH or GPG does:\n>\n>openssl dgst -sha256 -verify  <(openssl x509 -in certificate -pubkey -noout)\n>-signature sign.txt.sha256 signature.txt\n>\n>and reports either\n>\n>Verified OK\n>Or\n>Verification Failure\n>\n>It does not look like completion codes are consistently involved.\n>\n>This also does look structurally different than both GPG and SSH and more\n>work to set up. It may be possible to provide wrappers and pretend we are in\n>SSH, but I'm not sure that is the right path to take.\n>\n>Any pointers on how this might be done in existing git infrastructure, or\n>should I look into making this work in code? Sorry to say that the\n>documentation is not that clear on this.\n\nWhy not gpgsm? It can deal with x509 certs and is already supported. I am \nusing this to do s/mime signing/encryption with an yubikey hardware token \nbut static certs/keys should be even simpler. However I'm not sure how good \nthis works on other platforms.\n\nTake a look into the GPGSM prereq in t/lib-gpg.sh for a few hints on how to \nset this up.\n"},{"id":"451482","messageId":"037c01d83955$29362f90$7ba28eb0$@nexbridge.com","threadId":"57571","inReplyTo":"20220316162711.wfcavqpg2w4u7fat@fs","subject":"RE: [RFE] Signing using SSL","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2022-03-16T16:44:47Z","receivedAt":"2022-03-16T16:45:42Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On March 16, 2022 12:27 PM, Fabian Stelzer wrote:\n>On 16.03.2022 10:34, rsbecker@nexbridge.com wrote:\n>>Following up on our IRC discussion on Monday, I have had a request to\n>>support signing git commits and tags with SSL certificates instead of\n>>SSH/GPG. The organization is heavily invested in SSL infrastructure, so\n>>they want to go down that path.\n>>\n>>The basic technique for doing this is, for example:\n>>\n>>openssl dgst -sha256 -sign key -out content.sha256 signature.txt\n>>-passin passphrase\n>>\n>>There is a pre-step to compute the sha256, in this example, into a file\n>>provided to openssl. We could use openssl to compute the hash also.\n>>\n>>Verification is a bit different than what SSH or GPG does:\n>>\n>>openssl dgst -sha256 -verify  <(openssl x509 -in certificate -pubkey\n>>-noout) -signature sign.txt.sha256 signature.txt\n>>\n>>and reports either\n>>\n>>Verified OK\n>>Or\n>>Verification Failure\n>>\n>>It does not look like completion codes are consistently involved.\n>>\n>>This also does look structurally different than both GPG and SSH and\n>>more work to set up. It may be possible to provide wrappers and pretend\n>>we are in SSH, but I'm not sure that is the right path to take.\n>>\n>>Any pointers on how this might be done in existing git infrastructure,\n>>or should I look into making this work in code? Sorry to say that the\n>>documentation is not that clear on this.\n>\n>Why not gpgsm? It can deal with x509 certs and is already supported. I am using\n>this to do s/mime signing/encryption with an yubikey hardware token but static\n>certs/keys should be even simpler. However I'm not sure how good this works on\n>other platforms.\n>\n>Take a look into the GPGSM prereq in t/lib-gpg.sh for a few hints on how to set\n>this up.\n\nGood 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.\n\n"},{"id":"452574","messageId":"00b801d84383$d85b0490$89110db0$@nexbridge.com","threadId":"57571","inReplyTo":"20220316162711.wfcavqpg2w4u7fat@fs","subject":"RE: [RFE] Signing using SSL","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2022-03-29T15:44:10Z","receivedAt":"2022-03-29T15:44:22Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On March 16, 2022 12:45 PM, I wrote:\n>On March 16, 2022 12:27 PM, Fabian Stelzer wrote:\n>>On 16.03.2022 10:34, rsbecker@nexbridge.com wrote:\n>>>Following up on our IRC discussion on Monday, I have had a request to\n>>>support signing git commits and tags with SSL certificates instead of\n>>>SSH/GPG. The organization is heavily invested in SSL infrastructure,\n>>>so they want to go down that path.\n>>>\n>>>The basic technique for doing this is, for example:\n>>>\n>>>openssl dgst -sha256 -sign key -out content.sha256 signature.txt\n>>>-passin passphrase\n>>>\n>>>There is a pre-step to compute the sha256, in this example, into a\n>>>file provided to openssl. We could use openssl to compute the hash also.\n>>>\n>>>Verification is a bit different than what SSH or GPG does:\n>>>\n>>>openssl dgst -sha256 -verify  <(openssl x509 -in certificate -pubkey\n>>>-noout) -signature sign.txt.sha256 signature.txt\n>>>\n>>>and reports either\n>>>\n>>>Verified OK\n>>>Or\n>>>Verification Failure\n>>>\n>>>It does not look like completion codes are consistently involved.\n>>>\n>>>This also does look structurally different than both GPG and SSH and\n>>>more work to set up. It may be possible to provide wrappers and\n>>>pretend we are in SSH, but I'm not sure that is the right path to take.\n>>>\n>>>Any pointers on how this might be done in existing git infrastructure,\n>>>or should I look into making this work in code? Sorry to say that the\n>>>documentation is not that clear on this.\n>>\n>>Why not gpgsm? It can deal with x509 certs and is already supported. I\n>>am using this to do s/mime signing/encryption with an yubikey hardware\n>>token but static certs/keys should be even simpler. However I'm not\n>>sure how good this works on other platforms.\n>>\n>>Take a look into the GPGSM prereq in t/lib-gpg.sh for a few hints on\n>>how to set this up.\n>\n>Good idea but this is a non-starter. I have a limit of GPG 1.4, which only has the\n>single legacy object. GPG added a dependency to mmap, which is not available on\n>any of my platforms. That was one reason we were so happy to have SSH support.\n\nI 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.\n\nDoes anyone agree/disagree with me on delaying this?\n--Randall\n\n"},{"id":"452590","messageId":"20220329172555.wzmhplni3w2guvo5@fs","threadId":"57571","inReplyTo":"00b801d84383$d85b0490$89110db0$@nexbridge.com","subject":"Re: [RFE] Signing using SSL","fromName":"'Fabian Stelzer'","fromEmail":"fs@gigacodes.de","sentAt":"2022-03-29T17:25:55Z","receivedAt":"2022-03-29T17:26:17Z","isPatch":false,"sender":{"key":"fs@gigacodes.de","avatar":"https://avatars.githubusercontent.com/u/564858?v=4"},"body":"On 29.03.2022 11:44, rsbecker@nexbridge.com wrote:\n>On March 16, 2022 12:45 PM, I wrote:\n>>On March 16, 2022 12:27 PM, Fabian Stelzer wrote:\n>>>On 16.03.2022 10:34, rsbecker@nexbridge.com wrote:\n>>>>Following up on our IRC discussion on Monday, I have had a request to\n>>>>support signing git commits and tags with SSL certificates instead of\n>>>>SSH/GPG. The organization is heavily invested in SSL infrastructure,\n>>>>so they want to go down that path.\n>>>>\n>>>>The basic technique for doing this is, for example:\n>>>>\n>>>>openssl dgst -sha256 -sign key -out content.sha256 signature.txt\n>>>>-passin passphrase\n>>>>\n>>>>There is a pre-step to compute the sha256, in this example, into a\n>>>>file provided to openssl. We could use openssl to compute the hash also.\n>>>>\n>>>>Verification is a bit different than what SSH or GPG does:\n>>>>\n>>>>openssl dgst -sha256 -verify  <(openssl x509 -in certificate -pubkey\n>>>>-noout) -signature sign.txt.sha256 signature.txt\n>>>>\n>>>>and reports either\n>>>>\n>>>>Verified OK\n>>>>Or\n>>>>Verification Failure\n>>>>\n>>>>It does not look like completion codes are consistently involved.\n>>>>\n>>>>This also does look structurally different than both GPG and SSH and\n>>>>more work to set up. It may be possible to provide wrappers and\n>>>>pretend we are in SSH, but I'm not sure that is the right path to take.\n>>>>\n>>>>Any pointers on how this might be done in existing git infrastructure,\n>>>>or should I look into making this work in code? Sorry to say that the\n>>>>documentation is not that clear on this.\n>>>\n>>>Why not gpgsm? It can deal with x509 certs and is already supported. I\n>>>am using this to do s/mime signing/encryption with an yubikey hardware\n>>>token but static certs/keys should be even simpler. However I'm not\n>>>sure how good this works on other platforms.\n>>>\n>>>Take a look into the GPGSM prereq in t/lib-gpg.sh for a few hints on\n>>>how to set this up.\n>>\n>>Good idea but this is a non-starter. I have a limit of GPG 1.4, which only has the\n>>single legacy object. GPG added a dependency to mmap, which is not available on\n>>any of my platforms. That was one reason we were so happy to have SSH support.\n>\n>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.\n>\n>Does anyone agree/disagree with me on delaying this?\n>--Randall\n>\n\nDo you actually need SSL Signing so you can verify commits with a single CA \nkey? Or do you have all the certs public keys anyway?\n\nI know quite a few setups where every employee is issued an x509 cert (often \nPIV Certs, preferably on a smartcard/token) and a central ldap is available \nwith all issued certs. This is usually used for authentication and s/mime.\n\nHowever this can easily be used with ssh signing as well. I do so myself.  I \nuse my own s/mime cert loaded into an ssh-agent (pkcs11 smartcard) to sign \ncommits and generate an allowed signers file with all the pubkeys extracted \nfrom the certs i get from the PKIs ldap server.\n\n"},{"id":"452592","messageId":"00c901d84393$77a67200$66f35600$@nexbridge.com","threadId":"57571","inReplyTo":"20220329172555.wzmhplni3w2guvo5@fs","subject":"RE: [RFE] Signing using SSL","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2022-03-29T17:35:59Z","receivedAt":"2022-03-29T17:36:22Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On March 29, 2022 1:26 PM, Fabian Stelzer wrote:\n>On 29.03.2022 11:44, rsbecker@nexbridge.com wrote:\n>>On March 16, 2022 12:45 PM, I wrote:\n>>>On March 16, 2022 12:27 PM, Fabian Stelzer wrote:\n>>>>On 16.03.2022 10:34, rsbecker@nexbridge.com wrote:\n>>>>>Following up on our IRC discussion on Monday, I have had a request\n>>>>>to support signing git commits and tags with SSL certificates\n>>>>>instead of SSH/GPG. The organization is heavily invested in SSL\n>>>>>infrastructure, so they want to go down that path.\n>>>>>\n>>>>>The basic technique for doing this is, for example:\n>>>>>\n>>>>>openssl dgst -sha256 -sign key -out content.sha256 signature.txt\n>>>>>-passin passphrase\n>>>>>\n>>>>>There is a pre-step to compute the sha256, in this example, into a\n>>>>>file provided to openssl. We could use openssl to compute the hash also.\n>>>>>\n>>>>>Verification is a bit different than what SSH or GPG does:\n>>>>>\n>>>>>openssl dgst -sha256 -verify  <(openssl x509 -in certificate -pubkey\n>>>>>-noout) -signature sign.txt.sha256 signature.txt\n>>>>>\n>>>>>and reports either\n>>>>>\n>>>>>Verified OK\n>>>>>Or\n>>>>>Verification Failure\n>>>>>\n>>>>>It does not look like completion codes are consistently involved.\n>>>>>\n>>>>>This also does look structurally different than both GPG and SSH and\n>>>>>more work to set up. It may be possible to provide wrappers and\n>>>>>pretend we are in SSH, but I'm not sure that is the right path to take.\n>>>>>\n>>>>>Any pointers on how this might be done in existing git\n>>>>>infrastructure, or should I look into making this work in code?\n>>>>>Sorry to say that the documentation is not that clear on this.\n>>>>\n>>>>Why not gpgsm? It can deal with x509 certs and is already supported.\n>>>>I am using this to do s/mime signing/encryption with an yubikey\n>>>>hardware token but static certs/keys should be even simpler. However\n>>>>I'm not sure how good this works on other platforms.\n>>>>\n>>>>Take a look into the GPGSM prereq in t/lib-gpg.sh for a few hints on\n>>>>how to set this up.\n>>>\n>>>Good idea but this is a non-starter. I have a limit of GPG 1.4, which\n>>>only has the single legacy object. GPG added a dependency to mmap,\n>>>which is not available on any of my platforms. That was one reason we were so\n>happy to have SSH support.\n>>\n>>I have been investigating this capability in more depth. After discussing with\n>OpenSSL, explicitly adding SSL signing to git would introduce CVE-2022-0778 into git\n>and allow a hostile upstream repo to introduce a deliberately defective key that\n>could trigger this CVE unless customers have patched OpenSSL. Given the lack of\n>broad-based adoption of the fixes to this point, I am reluctant to pursue this\n>capability at this time. (Actually referencing my own advice in Git Rev News 82).\n>The impact on git would be looping processes when signatures are evaluated. This\n>would break workflows that depend on signed content and have downloaded\n>keys with the CVE attributes.\n>>\n>>Does anyone agree/disagree with me on delaying this?\n>>--Randall\n>>\n>\n>Do you actually need SSL Signing so you can verify commits with a single CA key?\n>Or do you have all the certs public keys anyway?\n>\n>I know quite a few setups where every employee is issued an x509 cert (often PIV\n>Certs, preferably on a smartcard/token) and a central ldap is available with all\n>issued certs. This is usually used for authentication and s/mime.\n>\n>However this can easily be used with ssh signing as well. I do so myself.  I use my\n>own s/mime cert loaded into an ssh-agent (pkcs11 smartcard) to sign commits and\n>generate an allowed signers file with all the pubkeys extracted from the certs i get\n>from the PKIs ldap server.\n\nI 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.\n\nThe 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.\n\n"}]}