SQ(1)
β¨ SQ(1) β User Commands β¨
okay bestie, gather round π this is sq-pki-lookup from the SQ(1) manual, straight out of the User Commands section. it's giving certificate detective energy and honestly? obsessed.
πΈ NAME πΈ
sq-pki-lookup β lookup the certificates associated with a User ID
π¦ SYNOPSIS π¦
sq pki lookup [OPTIONS]
π DESCRIPTION π
Lookup the certificates associated with a User ID. that's the whole vibe, no cap.
It identifies authenticated bindings (User ID and certificate pairs) where the User ID matches the specified User ID.
An error is returned if no binding could be authenticated to the specified level β and by default that level is fully authenticated, i.e., a trust amount of 120. so like, no trust, no dice, periodt.
But!! here's the cute part π₯° if a binding could be partially authenticated (i.e., its trust amount is greater than 0), then the binding is displayed, even if the trust is below the specified threshold. we love a partial credit moment.
β¨ OPTIONS β¨
π Subcommand options π
--amount=AMOUNTβ the required amount of trust.120indicates full authentication; values less than120indicate partial authentication. When--certification-networkis passed, this defaults to1200, i.e., this command tries to find 10 paths. go big or go home fr fr.--certification-networkβ treats the network as a certification network. Normally, the authentication machinery treats the Web of Trust network as an authentication network where a certification only means that the binding is correct, not that the target should be treated as a trusted introducer. In a certification network, the targets of certifications are treated as trusted introducers with infinite depth, and any regular expressions are ignored. Note: the trust amount remains unchanged. This is how most so-called PGP path-finding algorithms work.--email=EMAILβ find certificates that can be authenticated for the specified email address. A certificate is returned if a user ID with the specified email address can be authenticated for that certificate. To search for a certificate with a user ID containing just the specified email address, use--userid <EMAIL>instead. (iykyk, they are not the same thing π)--gossipβ treats all certificates as unreliable trust roots. This option is useful for figuring out what others think about a certificate (i.e., gossip or hearsay). In other words, this finds arbitrary paths to a particular certificate.
Gossip is useful in helping to identify alternative ways to authenticate a certificate. For instance, imagine Ed wants to authenticate Laura's certificate, but asking her directly is inconvenient. Ed discovers that Micah has certified Laura's certificate, but Ed hasn't yet authenticated Micah's certificate. If Ed is willing to rely on Micah as a trusted introducer, and authenticating Micah's certificate is easier than authenticating Laura's certificate, then Ed has learned about an easier way to authenticate Laura's certificate. π«Ά bestie behaviour tbh.
Stable since 1.1.0.
--show-pathsβ show why a binding is authenticated. By default, only a user ID and certificate binding's degree of authentication (a value between0and120) is shown. This changes the output to also show how that value was computed by showing the paths from the trust roots to the bindings. it's giving receipts π--unusableβ show bindings that are unusable. Normally, unusable certificates and bindings are not shown. This option considers bindings, even if they are not unusable, because they (or the certificates) are not valid according to the policy, are revoked, or are not live.
This option only makes sense with --gossip, because unusable bindings are still considered unauthenticated.
Stable since 1.1.0.
--userid=USERIDβ find certificates that can be authenticated for the specified user ID. The specified user ID does not need to be self signed.
π Global options π
See sq(1) for a description of the global options. (they live over there, not here π)
π EXAMPLES π
Lookup certificates that can be authenticated for the given user ID.
sq pki lookup --userid "Alice <alice@example.org>"
Lookup certificates that have a user ID with the specified email address, and that user ID can be authenticated.
sq pki lookup --email alice@example.org
π SEE ALSO π
For the full documentation see https://book.sequoia-pgp.org/.
β VERSION β
1.5.0
okay that's the whole page, you ate that π go authenticate something iconic π β¨
and that's a wrap from Sequoia PGP, version 1.5.0 β mwah, bye bestie π¦π
π¦ where this page comes from
- fedora 43: sequoia-sq 1.5.0-1.fc43 Β· LGPL-2.0-or-later AND Apache-2.0 AND BSL-1.0 AND BSD-3-Clause AND MIT AND MPL-2.0 AND Unicode-3.0 AND Unicode-DFS-2016 AND Zlib AND bzip2-1.0.6 AND (0BSD OR MIT OR Apache-2.0) AND (Apache-2.0 OR BSL-1.0) AND (Apache-2.0 OR MIT) AND (Apache-2.0 WITH LLVM-exception OR Apache-2.0 OR MIT) AND (BSD-2-Clause OR Apache-2.0 OR MIT) AND (MIT OR Apache-2.0 OR Zlib) AND (Unlicense OR MIT)
- fedora 44: sequoia-sq 1.5.0-1.fc44 Β· LGPL-2.0-or-later AND Apache-2.0 AND BSL-1.0 AND BSD-3-Clause AND MIT AND MPL-2.0 AND Unicode-3.0 AND Unicode-DFS-2016 AND Zlib AND bzip2-1.0.6 AND (0BSD OR MIT OR Apache-2.0) AND (Apache-2.0 OR BSL-1.0) AND (Apache-2.0 OR MIT) AND (Apache-2.0 WITH LLVM-exception OR Apache-2.0 OR MIT) AND (BSD-2-Clause OR Apache-2.0 OR MIT) AND (MIT OR Apache-2.0 OR Zlib) AND (Unlicense OR MIT)
- nixpkgs unstable: sequoia-sq 1.5.0
- opensuse-leap 16.0: sequoia-sq 1.5.0-bp160.1.1 Β· LGPL-2.0-or-later
- opensuse-leap 16.0: sequoia-sq 1.5.0-bp160.1.1 Β· LGPL-2.0-or-later
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms