4.5 KiB
RFC 0001 A stable and forwards compatible public key storage format
Feature Name: Stable public key storage
Status: Draft (first parts sketched)
Type: Enhancement
Start Date: 2018-06-14
Author: Simon Massey
Related components: Core
GitHub issues:
- #136 GnuPG2 2.2 vs 2.1 conflicts in keybox format
Summary
A new internal public key storage format that avoids forwards compatibility issues between GPG releases. This proposal will keep forwards compatibility with older versions of git-secret.
Motivation
GPG maintains backwards compatibility but not forwards compatibility. Users typically upgrade GPG but do not downgrade. This means that running a new GPG version will typially update the keyring storage files in a way that is not recognised by older versions of GPG. This is normally not a problem of typicaly GPG usage as users typically only upgrade and do not downgrade. It is a problem for git-secret as the keyring storage is committed to git and shared between users. Some uses can be using an older version of GPG that cannot open the upgraded keyring file.
Approach
git-secret will move away from using the keyring format as shared storage of public keys. Instead it will store public keys as seperate files. The export format is stable and forwards compatibile as it is normal for GPG uses to be running different versions and to exchange keys. Any future bugs that effect git-secret's ability to use the files will also effect typical GPG usage. Such bugs are likely to be fixed by the wider GPG community.
git-secret may need to store and process meta-data about keys to make it efficient to work with keys that are individually stored. It will use the matchine readable "colon listings format" for this purpose.
It is anticipated that bash
and gawk
will be suffient to be able to impliment and use the new shared key storage format.
Design
The storage format will be:
- Keys will be stored in
~/.gitsecret/keys
ingpg --armor --export
format. The use of ascii armour rather than binary format is to make debugging of key issues easier. The file name of the key will be the "64 bit keyid" (field 5 of thecolon listings
format) with extension.pub.gpg
- Key meta data will be stored alongside the key file in the
gpg --keyid-format long --with-colons
format. The file name will be the "64 bit keyid" (field 5 of thecolon listings
format) with extension.gpg.colon
- A "keyring cache" will be create at
~/.gitsecret/cache
and this folder will be added to.gitignore
. At this location a public keyring will be maintained on a per user bases and it won't be shared by users. - A tombestone marker file with file name of the "64 bit keyid" with the extension
.killed
will be created by git-secret-killperson to mark a user as killed.
The storage format will be used by git-secret-tell as follows:
- Scan the set of
.gpg.colon
to find all currently told identities. If the told identity is in the current list do nothing. - If the told identity isn't listed run
gpg --armor --export
against the users$HOME
keyring. Run--keyid-format long --with-colons
of the exported key. The result being two new files<key-id>.pub.gpg
and<key-id>.gpg.colon
in~/.gitsecret/keys
The storage format will be used by git-secret-hide as follows:
- The list of "64 bit keyid"s who are told will be computed from the
.gpg.colon
files. This will be checked against the list of "64 bit keyid"s in the "keyring cache" at~/.gitsecret/cache
. Any missing keys are imported into the "keyring cache". It is anticipated thatgrep
andgawk
will be suffient to be perform this calculation. The code then runs as normal using the keyring cache.
The storage format will be used by git-secret-killperson as follows:
TBD
The storage format will be used by git-secret-xxx as follows:
TBD
Forwards compatibility with older versions of git-secret will be mantained as follows:
TBD
Drawbacks
To maintain forward compatibility the approach requires the eixsting logic to kept working for a perod of time... TBD
Alternatives
What other designs have been considered? Unknown.
What is the impact of not doing this? Team members are locked out of their secrets broken when one user upgrades. This can go undetected until the victim needs the secrets in a hurry for production support. Bad things then happen.
Unresolved questions
What parts of the design are still to be done? See TBD points above.