sigul(1)

📦 version 1.4, in epel 9, fedora 43, fedora 44

💖 sigul 💖

okay bestie, sit down, hydrate, because today we're talking about sigul — a client for accessing a signing server. that's the whole thing. that's the girl. ✨

✨ SYNOPSIS ✨

sigul [OPTIONS] [COMMAND [COMMAND-ARGS...]]

🌸 DESCRIPTION 🌸

sigul connects to a sigul server through a sigul bridge to perform COMMAND. that's the pipeline, bestie — you, the bridge, the server. it's giving relay race. 🏃♀️💨

👑 OPTIONS 👑

real talk first, because this trips people up: the global sigul OPTIONS are a completely different species from the COMMAND-specific options. only the options that come before COMMAND on the command line count as global OPTIONS. everything after belongs to the command. order matters. it's giving "read the fine print, babes". 💅

  • --help-commands — lists all the COMMANDs she recognizes. your little menu of possibilities. 🎀
  • --batch — makes her more suitable for batch processing. instead of reading passwords from /dev/tty, she reads them from standard input. each password on standard input is terminated by a NUL (0) byte. the passwords are expected in the same order as when --batch is not specified — except a new password is expected only once, not twice. 🫶
  • -c, --config-file PATH — use PATH as the per-user configuration file instead of ~/.sigul/client.conf. your config, your rules. 💜
  • -u, --user-name USER — use USER as the user name sent to the server, overriding whatever value is set in the configuration file. main character override energy. 👑
  • -v, --verbose — be more verbose. use it twice and you unlock debugging output. yes, twice. the second -v is the secret door. 🔥

🚦 EXIT STATUS 🚦

sigul returns exit status 0 on success, and non-zero on error. so like, check it. it's not a vibe check, it's a status check. 💀

🛡️ ADMINISTRATIVE COMMANDS 🛡️

these commands are only available to signing server administrators, identified with a personal password. iykyk. 🔐

list-users

List users recognized by the server. 💜

new-user [--admin] [--with-password] USER

Add USER to the server. the user will be a server administrator if --admin is specified, and will have a personal password defined if --with-password is specified. ✨

delete-user USER

Delete USER on the server. this operation is allowed only after all key access rights were revoked from USER. clean up your mess first, bestie. 🧹

user-info USER

Show information about USER. the tea. 🍵

modify-user [--admin {yes|no}] [--new-name NEW_NAME] [--change-password] USER

Modify USER according to the specified options. glow-up, but make it administrative. 💅

key-user-info USER KEY

Show whether USER has access to KEY, and whether the user is an administrator for this key. 👀

modify-key-user [--key-admin {yes|no}] USER KEY

Modify the access of USER to KEY according to the specified options. 🎀

list-keys

List keys stored on the server. 🔑

new-key [--key-admin USER] [--name-real REAL_NAME] [--name-comment COMMENT] [--name-email EMAIL] [--expire-date YYYY-MM-DD] KEY

Create a new key KEY on the server, using the specified name and expiry information, and write the public key to standard output. 🌟

If USER is specified, make him the key administrator and only user instead of the invoking user. this is only this user, plus the users this user grants access, who can use the key. even signing server administrators can not use the key without knowing a key passphrase of one of the authorized key users. that's the whole point of the design, fr fr. 🫶

import-key [--key-admin USER] KEY KEY_FILE

Import a public and private key from KEY_FILE to the server, naming it KEY. 📥

If USER is specified, make him the key administrator and only user instead of the invoking user. this is only this user, plus the users this user grants access, who can use the key. even signing server administrators can not use the key without knowing a key passphrase of one of the authorized key users. same energy as new-key. 💜

KEY_FILE should be created using the following command:

gpg --export-secret-key KEY_ID > KEY_FILE

delete-key KEY

Delete KEY from the server. bye bestie. 👋

modify-key [--new-name NEW_NAME] KEY

Modify KEY according to the specified options. 🎀

🗝️ KEY ADMINISTRATION COMMANDS 🗝️

these commands are available to key administrators, identified with a key passphrase. some of these commands support a --password option — and those commands are also available to signing server administrators, identified by their personal password. two ways in, same door. 🚪✨

list-key-users [--password] KEY

List users that have access to KEY. 📋

grant-key-access KEY USER

Grant access to KEY to USER. slay, sharing is caring. 🤝

revoke-key-access [--password] KEY USER

Revoke access to KEY from USER. this command can not revoke access from the last user of KEY — you must delete KEY instead. no leaving a key with zero friends, that's the rule. 💀

🌈 USER COMMANDS 🌈

these commands are available to key users, identified with a key passphrase. some of these commands support a --password option — and those commands are also available to signing server administrators, identified by their personal password. 💖

get-public-key [--password] KEY

Write the public key for KEY to standard output. 🗝️

change-passphrase KEY

Change the user's passphrase for KEY. each user has a separate passphrase for each KEY they have access to. so many passphrases, so little time. 😭

sign-text [--output OUTPUT] KEY INPUT_FILE

Wrap INPUT_FILE in a clear-text signature, and write it to OUTPUT. if OUTPUT is not defined, write the signed text to standard output. ✍️

sign-data [--output OUTPUT] KEY INPUT_FILE

Create a detached signature for INTPUT_FILE and write it to OUTPUT. if OUTPUT is not defined, write the signed text to standard output, which must not be a terminal. (and yes, INTPUT_FILE is spelled exactly like that in the original — we don't fix her, we love her. 🙈)

sign-rpm [--output OUTPUT] [--store-in-koji] [--koji-only] [--koji-instance INSTANCE] [--v3-signature] KEY RPM_ID

Sign the rpm specified by RPM_ID. RPM_ID can either be a path to a RPM file, or a name-epoch:version-release.arch string that specifies a RPM stored in Koji. 📦

If --store-in-koji is specified, store the generated signature to Koji. unless --koji-only is specified, write a signed RPM file to OUTPUT, and if OUTPUT is not defined, write it to standard output. 🔥

The --koji-instance option can be used to perform the operation using a different Koji instance, if it was set up in the configuration files of both the client and the bridge. 🌉

Use a PGP version 3 format signatue if --v3-signature is specified. (yes, "signatue". the original said it. iconic typo, we keep it. 💅)

sign-rpms [--output DIR] [--store-in-koji] [--koji-only] [--koji-instance INSTANCE] [--v3-signature] KEY RPM_ID...

Sign one or more rpms specified by RPM_ID. each RPM_ID can either be a path to a RPM file, or a name-epoch:version-release.arch string that specifies a RPM stored in Koji. this one's the group chat version of sign-rpm. 🫂

If --store-in-koji is specified, store the generated signature to Koji. if --koji-only is not specified, the --output option is mandatory, and each signed RPM will be stored as a file in the DIR directory. no output dir, no deal. 💀

The --koji-instance option can be used to perform the operation using a different Koji instance, if it was set up in the configuration files of both the client and the bridge. 🌉

Use a PGP version 3 format signatue if --v3-signature is specified. 🎀

📁 FILES 📁

  • /etc/sigul/client.conf — a system-wide configuration file. the communal one. 🏠
  • ~/.sigul/client.conf — a per-user configuration file. values defined in this file override the system-wide configuration file. your room, your rules. 👑

💜 AUTHORS 💜

Miloslav Trmac <mitr@redhat.com> — the legend herself. thank you for your service. 🫶

👀 SEE ALSO 👀

sigul_setup-client(1), sigul_bridge(8), sigul_server(8)

and that's the whole page, bestie!! this was sigul from the General Commands Manual, dated Jan 2011 — go forth and sign things responsibly. mwah. 💋✨🎀🦋

📦 where this page comes from