SQ-GIT(1)

✨ NAME ✨

okay so bestie, welcome to sq-git-policy-authorize — it changes the authorizations. that's the whole vibe. that's the job. 💅

this is the sq-git manual page, and we're about to go through it together, no skimming, no skipping, every single flag gets its moment. 🎀

---

🌸 SYNOPSIS 🌸

sq-git policy authorize [OPTIONS] NAME FILE|FINGERPRINT|KEYID

that's it, that's the shape of it: you run the subcommand, you throw some options at it, and you tell it who you're authorizing with a NAME plus a FILE, FINGERPRINT, or KEYID. slay. 🦋

---

💖 DESCRIPTION 💖

Changes the authorizations. yep, that's the whole thing. ✨

here's the actually-important part though: a certificate can delegate any of its capabilities to another certificate without breaking an authentication chain. that's the magic trick. 🪄

and if you wanna fork a project, you create a new policy file. that's the move. periodt. 👑

---

🫶 OPTIONS 🫶

🌈 Subcommand options

• --add-user — Grant the certificate the add-user capability.

this capability lets the certificate add users to the policy file, and also lets it grant them capabilities. but here's the catch, and it's a big one: a certificate that has this capability is only allowed to grant capabilities that it has. so if Alice has the sign-commit and add-user capability, she can grant Bob either of those, but she can't grant him the sign-tag capability, because she does not have that capability. no reaching into the cookie jar you can't open, bestie. 🍪

• --audit — Grants the certificate the audit capability.

this capability allows the certificate to audit commits. imagine: Alice has the audit capability, Bob has the can-sign capability, and then Bob revokes his key because it was compromised — suddenly all commits that Bob signed are considered invalid. 😭 Alice can recover from this situation by auditing Bob's commit. and after auditing each commit, she marks it as good using sq-git policy goodlist. crisis averted, main character energy. 💅

• --cert=FINGERPRINT|KEYID — The fingerprint or Key ID of the certificate to use

this is read from the user's default certificate directory.

see the top-level option --home for more information about the certificate store. 🏠

• --cert-file=FILE — The file containing the certificate to authorize.

the file must contain exactly one certificate. not two. not zero. one. 🎯

• --committer — Grants all capabilities relevant to a committer.

a committer is authorized to commit changes to the code. this option grants the certificate the sign-commit capability. that's it, that's the committer bundle. ✨

• --no-add-user — Rescind the add-user capability from a certificate.

removes the add-user capability for the certificate. Note: this operation is not retroactive; operations that rely on this grant prior to the policy change are still considered authenticated. 🙈

rescinding the add-user capability from a certificate does not rescind any grants that that certificate made. so: if Alice grants Bob the can-sign and add-user capability, Bob grants Carol the can-sign capability, and then Alice rescinds Bob's can-sign and add-user capabilities — Carol still has the can-sign capability. in this way, a grant is a copy of a capability. photocopied, not lent. 🖨️

• --no-audit — Rescind the audit capability from a certificate.

removes the audit capability from a certificate. the specified certificate cannot no longer mark arbitrary commits as good. 💀

• --no-retire-user — Rescind the retire-user capability from a certificate.

removes the retire-user capability from a certificate. the specified certificate cannot no longer rescind capabilities — even those that they granted. 😬

• --no-sign-archive — Rescind the sign-archive capability from a certificate.

removes the sign-archive capability for the certificate. Note: this operation is not retroactive; archives signed with the certificate prior to the policy change are still considered authenticated. 📦

• --no-sign-commit — Rescind the sign-commit capability from a certificate.

removes the sign-commit capability for the certificate. Note: this operation is not retroactive; commits signed with the certificate prior to the policy change are still considered authenticated. 🌟

• --no-sign-tag — Rescind the sign-tag capability from a certificate.

removes the sign-tag capability for the certificate. Note: this operation is not retroactive; tags signed with the certificate prior to the policy change are still considered authenticated. 🏷️

• --policy-file=POLICY — Use an alternate policy.

the default policy is the openpgp-policy.toml file in the root of the repository's working tree. 📁

• --project-maintainer — Grants all capabilities relevant to a project maintainer.

a project maintainer is a person who is responsible for maintaining the project. this option grants the certificate all capabilities. the whole crown. 👑

• --release-manager — Grants all capabilities relevant to a release manager.

a release manager is authorized to commit changes, and make releases. this option grants the certificate the sign-tag, sign-archive, and sign-commit capabilities. 🚀

• --retire-user — Grants the certificate the retire-user capability.

this capability allows the certificate to rescind arbitrary capabilities. so if Alice has the retire-user capability, she can rescind Bob's can-sign capability even if she didn't grant him that capability. scary power, use responsibly. ⚠️

• --sign-archive — Grant the certificate the sign-archive capability.

this capability allows the certificate to sign tarballs or other archives. when authenticating an archive, an archive is considered authenticated if it is signed by a certificate with this capability. 🗜️

• --sign-commit — Grant the certificate the sign-commit capability.

this capability allows the certificate to sign commits. when authenticating a version of the repository, a commit is considered authenticated if it is signed by a certificate with this capability. ✅

• --sign-tag — Grant the certificate the sign-tag capability.

this capability allows the certificate to sign tags. when authenticating a tag, a tag is considered authenticated if it is signed by a certificate with this capability. 🎉

💜 NAME

• FILE|FINGERPRINT|KEYID — The filename, fingerprint or Key ID of the certificate to authenticate

this is first interpreted as a filename. if that file does not exist, then it is interpreted as a fingerprint or Key ID, and read from the certificate store. to avoid ambiguity, use --cert or --cert-file instead. seriously, bestie, if you're confused, just use the explicit flags. 🫠

see the top-level option --home for more information about the certificate store.

⭐ Global options

see sq-git(1) for a description of the global options. go read that one too, i'm not redoing it here. 💅

---

🦋 SEE ALSO 🦋

• sq-git(1)
• sq-git-policy(1)

for the full documentation see <https://sequoia-pgp.gitlab.io/sequoia-git>. 📖

---

🎀 VERSION 🎀

0.6.0

---

and that's the whole page, bestie!! you read every single flag, every capability, every "not retroactive" warning, and i'm so proud of you. 🥹💖

sending you off with the classic sign-off: this gem is brought to you by Sequoia PGP, version 0.6.0, living its best life under the SQ-GIT(1) manual page name. go forth and authorize responsibly. 🌈✨👑