Hyperledger projects require their contributors to sign Git commits to attest to the Developer Certificate Origin (DCO). New developers have provided feedback that this process can be confusing and represents a barrier to contributing to the project.
Hyperledger Indy provides an identity system that can be used by developers to issue verifiable credentials attesting to the DCO. The Sovrin network is a public instance of Indy that would allow third parties to verify Indy credentials that use the network. Using Indy to sign Git commits would not only improve the contributor experience, but would also serve as a great real-world application of the Indy technology.
Successful completion of this project will involve learning skills such as:
Immediately useful for Hyperledger Indy, but could make it easier to contribute to all Hyperledger projects.
Enrolled in an undergraduate program in a technical subject.
Basic programming experience is required. It is also desirable to have familiarity with Git, Rust, and Python.
As a result of this project, the intern will be familiar with Hyperledger Indy SDK and able to contribute in a variety of ways including improved documentation, testing, and feature development. A good follow on feature would be to integrate Indy credentials with GPG and SSH by exposing ed25519 keys to those tools.
Either full time or part time is acceptable.
Richard Esplin, email@example.com, esplinr, Evernym
Dave Huseby, firstname.lastname@example.org, dhuseby, Hyperledger
Ibrahim El Rhezzali
Currently git supports signing / verifying commits and tags using GPG only. The goal of this project is to make the git signing interface compatible with external signing tools and with (Distributed Identities) using programs such as for example.
This project will be the continuation of the work already done by on the subject. His previous work is here:
This project's working fork:
The main sections of the project are updating the user configuration and the command handling when a signing or verifying operation occur. The actions needed in each section can be listed below and will be evolving as the project evolves.
UPDATE: The request for proposal has been sent to the git mailing list and can be tracked here:
The commits that will be submitted as a patch can be found here:
After receiving feedback from the git community, we opted for a config based approch and a tool-agnostic signing interface. Below is the explained approach sent to the mailing list:
The user configuration would define the signing tool and other parameters as keys, identity and keychain. It would look like this:
[signing] format = openpgp [signing "openpgp"] program = /usr/bin/gpg keyring = "--keyring pubring.kbx --no-default-keyring" identity = "--local-user \"Jane Committer <email@example.com>\"" sign = "$program --sign --status-fd=2 --detach-sign --ascii" verify = $program --verify --status-fd=2" [signing "openpgp.signature"] regex = "^-----BEGIN PGP SIGNATURE-----$[^-]*^-----END PGP SIGNATURE-----$" multiline = true
And the same goes for the command line:
git commit \ --sign --signing-format=openpgp \ --signing-openpgp-program="/usr/bin/gpg" \ --signing-openpgp-keyring="--keyring pubring.kbx --no-default-keyring" \ --signing-openpgp-identity="--local-user \"Jane Committer <firstname.lastname@example.org>\"" \ --signing-openpgp-sign="--sign --status-fd=2 --detach-sign --ascii"
As for tool that don't work natively with the signing interface, a support for helper bash or python scripts will be added.
Below in an illustrative model of the expected outcome:
Debug the git_signing_config and the openpgp_config/x509_config functions and verify that all unit tests pass.
Add new unit tests to verify that all deprecated aliases work as expected and produce good warnings.
Add new unit tests to verify that all new configuration keys work.
Add Helper scripts template
These are secondary tasks to do while waiting for feedback or assistance, or finished early: