sign.conf(8)

πŸ“¦
version 2.8.4 Β· 3 versions
, in fedora 43, fedora 44

πŸ’– sign.conf(8) πŸ’–

the system manager's manual page ✨ ok so you found sign.conf(8) in the System Manager's Manual section and bestie, you're about to have a great time. this is the config file for the whole sign situation. let's go πŸŽ€


✨ NAME ✨

sign.conf β€” the sign and signd configuration file, aka the one file running the whole show πŸ’…


πŸ¦‹ SYNOPSIS πŸ¦‹

/etc/sign.conf

like. that's it. that's the path. iconic.


🌸 DESCRIPTION 🌸

This file holds the configuration for both the sign program and the signd daemon. one file, two besties, no drama 🫢

Every single line in the file has this format:

key: value [value...]

Empty lines are ignored. Lines starting with # are ignored too β€” those are your little comment vibes, go off.

Here are all the keys that get recognized, no gatekeeping:

  • server: hostname β€” Forward all requests with unknown signing users to the specified server. like, "idk her, ask this server" πŸ’β€β™€οΈ
  • port: port β€” Use the specified port number instead of the default port 5167. don't be weird about it, 5167 is the default.
  • proto: unprotected|ssl β€” Set the protection protocol to secure the connection to the sign server. The default is to use an unprotected connection. (yes, unprotected is the default. yes, that's a choice. πŸ’€)
  • user: user β€” Set a default user to use for signing.
  • hash: hash β€” Set a default hash to use for signing. The default hash is SHA1 for compatibility reasons. (compatibility reasons. we don't ask questions. πŸ™ˆ)
  • allow: ip
  • allow: subnet
  • allow: hostname β€” Allow only connections from the specified ip addresses, subnets expressed in CIDR notation, and/or hostnames. Note that hostnames are resolved using reverse DNS lookups, so there must be reverse entries in the DNS server, and it should be secured against DNS poisoning attacks. All requests are rejected if the allow list is empty. so if you leave it blank, nobody gets in. not even you. not even your mom. periodt.
  • gpg: path_to_gpg β€” Select the gpg program to use instead of "/usr/bin/gpg".
  • phrases: phrases_directory β€” Set the directory containing gpg phrases for every user. A phrase file is fed into gpg with the "--passphrase-fd=0" option.
  • map: [hash:]from_signuser to_signuser β€” Modify the signuser. This can be used to map hashes and users to unambiguous key ids.
  • allowuser: username|uid β€” Grant the user the right to sign. The sign binary must be installed as suid-root binary for this to work. Multiple users can be specified by using multiple allowuser lines in the configuration.
  • allow-unprivileged-ports: true|false β€” Allow signd to accept connections from source ports > 1024. Defaults to false.
  • use-unprivileged-ports: true|false β€” Use a source port > 1024 when connecting to the signd server. Defaults to false.
  • logfile: filename β€” Log requests to the specified filename instead of stdout.
  • gnupghome: dirname β€” Configures the directory for gpg to use by setting the GNUPGHOME environment variable.
  • use-agent: true|false β€” Make signd directly talk to the gpg-agent for signing instead of calling gpg. If the gpg command does not implement the --files-are-digest parameter, this option always falls back to true. (it said what it said and it meant it 😌)
  • keycache: dirname β€” Cache the result of finding the signing key for a username. This is only done if the gpg-agent is used for signing. The cache is automatically invalidated if there is a change in the gpg keyring. self-cleaning queen πŸ‘‘
  • agentsocket: socketpath [socketpath...] β€” Specify the location of the gpg agent socket. It is possible to specify more than one location, as gpg uses different socket directories depending on if the user is logged in or not. As a fallback, signd will call "gpgconf --list-dirs" to find the current location of the agent socket.
  • ssl_certfile: path
  • ssl_keyfile: path β€” Specify the certificate and the corresponding private key for ssl client certification.
  • ssl_verifyfile: path
  • ssl_verifydir: dirpath β€” Specify the ca locations used to verify the certificate of the server. If neither a verifydir nor a verifyfile is configured, the default ca locations are used.
  • proxyport: port
  • proxyproto: unprotected|ssl
  • proxyssl_certfile: path
  • proxyssl_keyfile: path
  • proxyssl_verifyfile: path
  • proxyssl_verifydir: dirpath β€” Configure the setting for incoming requests. The corresponding value for outgoing requests is used if a key has not been set. The keyfile/certfile specifies the server certificate, the verifydir/verifyfile configures the ca locations to verify the client certificate.
🚨 heads up bestie: incoming requests with no client certificate are rejected. no cert, no entry, sorry not sorry.
  • allow_subject: x509_subject
  • allow_subject: /x509_subject_regex/ β€” Allow only requests that have a verified client certificate with a subject that matches one of the specified values. The X509 subject is converted to a string as specified in RFC-2253 before doing a match. If the allow_subject list is empty, no check is done on the X509 subject but the certificate is still verified. verified either way, so don't get cute 🌈

πŸŽ€ FILES πŸŽ€

  • /etc/sign.conf

πŸ‘‘ SEE ALSO πŸ‘‘

go read those too, they're the whole point iykyk πŸ’œ


and that's the whole page, bestie!! 🌸 this one's from Apr 2007, mwah, ily, go configure something slay βœ¨πŸ’…πŸ¦‹

πŸ“¦ where this page comes from