* #136 GnuPG2 2.2 vs 2.1 conflicts in keybox format
@ -26,36 +26,40 @@ GPG maintains backwards compatibility but not forwards compatibility. Running a
## Approach
git-secret will move away from using the keyring format as shared storage of public keys. Instead it will store public keys as exported keys in ASCII armor format. The public key export format is stable and forwards compatible. GPG users will typically be running different GPG or PGP versions and are able to exchange keys successfully. Any future bugs that effect git-secret's ability to use the exported public keys will affect typical GPG or PGP key exchange usage. Such bugs are likely to be caught and fixed by the wider opensource community.
git-secret will move away from using the keyring format as shared storage of public keys. Instead, it will store public keys as exported keys in ASCII armor format. The public key export format is stable and forwards compatible. GPG users will typically be running different GPG or PGP versions and are able to exchange keys successfully. Bugs that effect git-secret's ability to use exported public keys will likey affect typical GPG key exchange usage. Such bugs are likely to be caught and fixed by the wider opensource community.
git-secret may need to store and process meta-data about keys to make it efficient to work with keys that are stored within individual files. It will use the machine-readable ["colon listings format"](https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob_plain;f=doc/DETAILS) for this purpose.
It is anticipated that `bash` and `gawk` will be sufficient to be able to use the new shared key storage format efficiently.
It is anticipated that `bash` and `gawk` will be sufficient to work efficiently with the new file formats.
## Design
The new storage format will be implimented as follows:
1. Keys will be stored in `~/.gitsecret/keys` in `gpg --armor --export` format. The use of ASCII armour rather than binary format is to make debugging of key issues easier. The filename of the key will be `<keyid>.pub.gpg` (using Field 5 the "64-bit keyid" of the colon listings format)
1. Key meta data will be stored alongside the key file in the `gpg --keyid-format long --with-colons` format. The file name will be `<keyid>.gpg.colon`
1. Keys will be stored in `~/.gitsecret/keys` in `gpg --armor --export` format. The use of ASCII armour rather than binary format is to make debugging of key related issues easier. The filename of the key will be `<keyid>.pub.gpg` (using Field 5 the "64-bit keyid" of the colon listings format)
1. Key meta data will be stored alongside the key file in the `gpg --keyid-format long --with-colons` format. The file name will be `<keyid>.pub.cln`
1. A folder `~/.gitsecret/cache` will be added to `.gitignore`. At this location, a public keyring will be maintained on a per user bases and won't be shared between users. This is simply a "keyring cache" of the keys used to encrypt files.
git-secret-tell will:
1. Scan the set of `*.gpg.colon` files to find all currently told identities. If the given identity is in the list do nothing.
1. If the given identity isn't listed run `gpg --armor --export` against the users `$HOME` keyring. Run `--keyid-format long --with-colons` of the exported key. Then create the two new files `<key-id>.pub.gpg` and `<key-id>.gpg.colon` in `~/.gitsecret/keys`
1. Scan the set of `*.pub.cln` files to find all currently told identities. If the given identity is in the list do nothing.
1. If the given identity isn't listed run `gpg --armor --export` against the users `$HOME` keyring to create the `<key-id>.pub.gpg`.
1. Run `--keyid-format long --with-colons` of the exported key to create the `<key-id>.pub.cln`.
Note that the additional steps to ensure that older versions of git-secret know about the newly told user will be outlined below.
Note that the additional steps to ensure that older versions of git-secret know about the newly told identity will be outlined below.
git-secret-hide will:
1. 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 that `gawk` will be sufficient to perform this calculation. The code then runs as before using the "keyring cache".
1. Extract the list of "64-bit keyid"s who are told from the `*.pub.cln` files. Note that multiple identities can be listed against each key.
1. Checked this against the list of "64-bit keyid"s in the "keyring cache" at `~/.gitsecret/cache`.
1. Import any missing keys into the "keyring cache". It is anticipated that `gawk` will be sufficient to perform this calculation.
1. Run the current logic using the "keyring cache".
Note that the additional steps to ensure that older versions of git-secret know about the newly told user will be outlined below.
git-secret-whoknows will:
1. The list of identities will be loaded by parsing the `.gpg.colon` files. Note that multiple identities can be listed against each key.
1. The list of identities will be loaded by parsing the `.pub.cln` files. Note that multiple identities can be listed against each key.
git-secret-usage will:
@ -75,11 +79,13 @@ git-secret-list will:
git-secret-killperson will:
1. Remove the key from the keyring cache then delete the `<key-id>.pub.gpg` and `<key-id>.gpg.colon` in `~/.gitsecret/keys`.
1. Remove the key from the keyring cache.
1. Delete both `<key-id>.pub.gpg` and `<key-id>.pub.cln` files.
git-secret-init will:
1. Add `~/.gitsecret/cache` into `.gitignore` and do any initialisation work of the public keyring at that location.
1. Add `~/.gitsecret/cache` into `.gitignore`.
1. Run any current logic using the ignored "keyring cache".
git-secret-clean will:
@ -87,7 +93,7 @@ git-secret-clean will:
git-secret-changes will:
1. Show differences the files `<key-id>.pub.gpg` and `<key-id>.gpg.colon` in `~/.gitsecret/keys`
1. Show differences the `<key-id>.pub.gpg` and `<key-id>.pub.cln` files in `~/.gitsecret/keys`.
git-secret-add will:
@ -96,13 +102,13 @@ git-secret-add will:
A new command git-secret-migrate will:
1. Create the folder `~/.gitsecret/cache` and add it to the `.gitignore` file.
1. Extract any keys from the old keyring generating `<key-id>.pub.gpg` and `<key-id>.gpg.colon` files in `~/.gitsecret/keys`
1. Extract all keys from the old keyring generating `<key-id>.pub.gpg` and `<key-id>.pub.cln` files in `~/.gitsecret/keys`
## Version Compatibility
Backwards compatibility will the old keyring storage approach will be maintained as follows:
1. For each changed command a guard will be added that checks for the existence of the .gitsecret/cache
1. For each changed command a guard will be added that checks for the existance of `.gitsecret/cache`.
1. If the folder exists it proceeds as normal.
1. If it does not exist it will report that the repo was initialised by an older version of git-secret and tell the user to run git-secret-migrate
Simon Massey
6 years ago