JETRING(7)

๐Ÿ’– JETRING(7) โ€” jetring commands ๐Ÿ’–

okay bestie, sit down, we're learning jetring today and honestly? it's giving โœจorganizedโœจ


๐ŸŒธ NAME ๐ŸŒธ

jetring โ€” maintenance of gpg keyrings using changesets ๐Ÿซถ


๐Ÿฆ‹ OVERVIEW ๐Ÿฆ‹

so jetring is a whole collection of tools that let you maintain gpg keyrings using changesets. it was developed with the Debian keyring in mind, and it's here to solve one specific problem: a gpg keyring is a binary blob, and binary blobs are lowkey impossible for multiple people to collaboratively edit ๐Ÿ˜ญ

with jetring, changesets can be:

  1. submitted
  2. reviewed โ€” so you see exactly what they'll do ๐Ÿ‘€
  3. applied
  4. used to build a keyring

and the best part? the origin of every single change made to the keyring is available for auditing. no cap. plus, gpg signatures can be used to further secure things ๐Ÿ”ฅ


๐ŸŽ€ OPERATION ๐ŸŽ€

a jetring directory is the "source" that a keyring gets built from. to convert an existing gpg keyring into such a directory, use the jetring-explode(1) command ๐Ÿ’ฅ

every change to the gpg keyring lives in its own separate changeset file inside that directory. changesets can reflect any set of changes to the keyring, and they can also include arbitrary metadata. the jetring-gen(1) command can compare two keyrings and generate a changeset from one to the other โœจ

changesets are never removed or modified, only new ones added โ€” using the jetring-accept(1) command. periodt. ๐Ÿ’…

there's an ordering of the changesets, and that ordering is stored in an index file. the index file is only ever appended to, to add new changesets. it doesn't get edited, it doesn't get rewritten, it just grows ๐ŸŒฑ

changesets can be fully examined to see what change they make before you apply them. the jetring-review(1) and jetring-diff(1) commands are your girls for that kind of review ๐Ÿ”

and to create a brand new keyring, or to incrementally update an existing one, changesets get applied in order using the jetring-build(1) command ๐Ÿ‘‘


๐Ÿ” GPG SIGNATURES ๐Ÿ”

the index file can optionally be gpg signed โ€” and the signature gets stored in index.gpg ๐Ÿ’œ

if JETRING_SIGN is set to point to a gpg keyring, then jetring commands that operate on the jetring directory will always check that the index file is signed with one of the keys from that keyring. and any command that modifies the index file will update its signature too. so cute, so secure ๐Ÿซถ


๐Ÿ“œ CHANGESET FORMAT ๐Ÿ“œ

a changeset file consists of one or more stanzas, separated by blank lines. the stanzas are in RFC-822-like format ๐Ÿ“ฎ

each stanza must have:

  • an action field โ€” this specifies which action to take on the keyring
  • a data field โ€” typically a multi-line field, containing the data to feed to the action

here are the supported actions, bestie:

  • import โ€” the data field should be an ascii-armored gpg key block, which gets fed into gpg --import ๐Ÿ“ฅ
  • edit-key keyid โ€” gpg --edit-key is run on the specified key id. the data field is a script, and each line in it is passed in to gpg, the same as if gpg were being driven interactively. this can be used to make arbitrary changes to the key โœ๏ธ
  • delete-key keyid โ€” the given key is deleted. the data is fed into gpg --delete-key, and it should be "y", since gpg expects that confirmation for deleting a key ๐Ÿ’€

other fields can be added as desired to hold metadata about the change. typical additional fields include date, changed-by, and comment ๐Ÿท๏ธ

changesets can also optionally have attached signatures โ€” although just so you know, such data is not automatically validated, and it's mostly useful to record who submitted or signed off on a given changeset. iykyk ๐Ÿ™ˆ


๐Ÿ‘‘ AUTHOR ๐Ÿ‘‘

Joey Hess, <joey@kitenet.net>. absolute icon, we love them ๐Ÿ’–


and that's the whole page, bestie!! this was jetring commands from the JETRING(7) manual โ€” go forth and maintain those keyrings like the main character you are ๐ŸŒˆโญ๐Ÿ’