Last Modified: April 24, 2024
This document details gittuf's ongoing roadmap. As gittuf is under active development, this document is not considered immutable, and some items may be added or changed. The items are divided between those that are currently being worked upon, those that are planned for the future, and those that we have already completed.
Once gittuf achieves sufficient maturity, the gittuf source must be protected using gittuf. This will contribute significantly to the usability and further development of the tool, and will demonstrate its features and viability.
gittuf currently identifies each developer by their signing key or identity. Policies grant permissions to each individual developer. Eventually, gittuf must support declaring teams of developers, with policies granting permissions to those teams as a whole. Further, thresholds on required authorizations for policies must be granular enough to apply across team boundaries. For example, it must be possible to require two members of the development team and one member of the security team to sign off on a change. This is not the same as a total threshold of three across the members of the development and security teams.
Related to the concept of teams, is the concept that a single developer might be on different teams and wish to choose how an action is perceived. Suppose Alice is both a maintainer and also on the security team. She sometimes may be approving something she authored (wearing her maintainer hat) and other times doing a security review of a dependency (wearing her security hat). It is reasonable that she may want to control how a statement of trust by her is used. These could naturally be linked to the teams for which a statement should be trusted.
Git forges like GitHub and GitLab allow repository owners to specify policies such as the developers authorized to push to a branch, the developers who must approve changes to certain files, and more. These repository policies can be specified in gittuf, making conformance with repository policies publicly verifiable. In addition, as gittuf tracks historic policies, auditing repositories hosted on such forges at some older state can be made possible.
Another Git-specific tool that gittuf could integrate with is Gerrit, the code review system. This integration, in combination with support for in-toto attestations would allow for transparent and auditable code review policy enforcement.
gittuf's design implements write permission policies such as who can write to a Git reference or a file. This must be accompanied by support for read permissions. This needs to be developed further as the feature can range from the ability to store secrets all the way to maintaining encrypted objects for certain Git references so only specific users can read that reference.
The hash algorithm agility extension describes how gittuf can be used to maintain a record of object hashes using stronger hash algorithms like SHA-256 while continuing to use SHA-1. While Git is working on SHA-256 support, it is currently not backwards compatible with existing repositories and unsupported by major Git hosts and forges. This feature needs to be fleshed out as the current document merely records some early ideas.
The gittuf implementation is built based on the specification defined in the design document. Therefore, as features are fleshed out and built, the two are updated together.
Currently, gittuf is in a pre-alpha stage. Its core features are still being developed, and therefore the primary item on the roadmap is building gittuf to reach the alpha milestone. The gittuf alpha version must include support for the main design document with features like policies for Git namespaces, file namespaces, key distribution, the Reference State Log, and the ability to sync gittuf metadata with remote repositories.
in-toto is a framework for comprehensive software supply chain security. Of specific interest to gittuf is in-toto's Attestation Framework that provides a standard way to express software supply chain claims. By integrating support for source control specific in-toto attestations, gittuf can also support verification against requirements specified by projects like SLSA.
As of April 2024, in-toto attestations can be used in gittuf for actions such as approving a change in the repository. We are actively working upstream with the SLSA project to enable using other predicate types that may be defined as part of the source track.