hyperledger / identus

Identus provides components to develop decentralized identity solutions that adhere to widely recognized self-sovereign identity (SSI) standards.
https://hyperledger.github.io/identus-docs/
Apache License 2.0
42 stars 6 forks source link

docs: DCO mentions nothing of cryptographic singing #34

Closed mixmix closed 2 months ago

mixmix commented 2 months ago

I recently expressed confusion / tension in this issue https://github.com/hyperledger/identus-edge-agent-sdk-ts/issues/251 TL;DR why are we adding "signed by: " to commit messages - that adds zero security

Problem: https://github.com/hyperledger/identus/blob/main/DCO.md completely fails to mention cryptographic signatures on commits. I have not used these before so as a learning I was like "this makes no sense". Turns out I was naive!

Further, the current docs show you how to set up "signed by" but then fail to mention anything about how to set up GPG signing!

Solution: Add some mention of cryptographic signatures to this document, and some links out to resources about how to set that up.

Here's a useful reference I used https://docs.github.com/en/authentication/managing-commit-signature-verification/generating-a-new-gpg-key

essbante-io commented 2 months ago

Hi @mixmix,

The DCO (Developer's Certificate of Origin) is a way for contributors to acknowledge that their contributions are made under the project's open-source license terms. The DCO sign-off is mandatory for all contributions to Hyperledger Projects, and it focuses more on intellectual property matters than anything else. GPG is not mentioned in the DCO file, as it is no mandatory, to the best of my knowledge. I will ask around, we may end up adopting it as a requisite for Identus contributions, will see.

FabioPinheiro commented 2 months ago

DCO is a requirement from Hyperledger. I personally don't care about it. I believe there are much better ways to achieve what they want with DCO.

I do care about GPG, and was also a requirement from IOGK. I always sign my comments, even if it's not a requirement. Already had a bad experiences of people changing my commits (*almost always with good intentions).

For example during the migration from Atala to Hyperledger we added DCO retroactive. So all commits were replay and the original GPG signature of the commits were lost.

@essbante-io The GPG as requirement was documented on the Atala handbook:

I'm in favor of moving it to here. By moving, I mean, copy from the Atala handbook to here and deleted from the other side. Please do not duplicate documentation!

mixmix commented 2 months ago

Confirm, that link 404s.

NOTE: I made a PR https://github.com/hyperledger/identus-edge-agent-sdk-ts/pull/259 which documents the existing requirements for that repo

@FabioPinheiro interestingly I feel similar to you about GPG being the signature that really matters. AND I noticed that if I was already commit -S then commit -sS was a costless extension (because I care about secure auditable history)

essbante-io commented 2 months ago

Thank you for your Input, @mixmix, and I apologize for the delay. I got tangled up with other responsibilities. The DCO.MD file was updated to better explain the rationale behind the DCO and GPG so others can learn about it. It now also includes details on the GPG setup. The PR will be merged soon.

@FabioPinheiro, Regarding the DCO, if you have suggestions for alternative and better approaches, please share them with the Hyperledger Technical Oversight Committee as they are always open to feedback for improvement. CC: @davidwboswell

FabioPinheiro commented 2 months ago

Already did give my suggestions at the time. I explained how this is done in several other projects that I had contributed. Ex: Scala, Unreal Engine or many other project in Lightbend

Where open source contributors to acknowledge and waiver the copyright to their work to the project.

On the projects I'm used to this is called a CLA - Contributor License Agreement

Anton explained everything to Hyperledger's contact at the time of the migration. At some point, I was expecting to get the answer that DCO and CLA are not same thing. But the feeling that we got from the answer was that. Is worth it to change the process at this point.

I pushed back again and ask Anton to insist that we don't want to rewrite the history of the repository. So we come up with alternative solution, where we signed the following commits:

a271709a789fd28d9404d5e0660b0d84bce41d1b 2307c7c75d26220578a779bdc11c12ca27e5e5f6 e72d1abc5e11f0b25c42612075095dcd7c91054d 8aaeed08db3dd03576da8b280eb159260c0347b7 c95a6fc0c1948a9cf887192e96d402deae53fc80 a716fee531f99484a553e28394ec3990f6f149a4 3b3b43a43d3990acd8c0f941bd9657ceee2b6aeb cb8cd06e9cef697fc86c133d4bcd7f554c727cf5 3b163f1cb4f75999f9e335d2ceff407f0bfb8891 6e3302e345c6aaa6fb825085dce4aeaeca0055c5 3c38dae89e8852ee181b69aa06910909d654a447


Then many months after we try to migrate all the other repositories. Without applying any of the practice learned from the first time...