IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
- Change `sq key revoke`, `sq key subkey revoke`, and `sq key userid
revoke` to support the cert store and key store.
- Add `--cert` to specify a certificate by key ID or fingerprint.
- If `--output` is not specified and `--cert` is, import the
modified certificate into the cert store. If `--output` is not
specified and `--cert-file` is, write the modified certificate to
stdout.
- `sq key revoked`, `sq key userid revoke`, and `sq key subkey
revoke` have two arguments for naming a certificate:
`--certificate-file` and `--cert-file`. The latter is an alias.
Drop `--certificate-file` and promote `--cert-file`. This
harmonizes these subcommands with other subcommands, which only
use `--cert-file`.
- Rename `--revocation-file` to `--revoker-file`, as the file
contains a "revoker" not a "revocation."
- While the commit b5a7d15710 moved the
"sq link" command under "sq pki", there are some left-overs in the
error messages.
Signed-off-by: Daiki Ueno <dueno@redhat.com>
- The output of `sq pki list`, `sq pki authenticate`, `sq pki
identify` and `sq pki lookup` are overwhelming.
- Change the output to only show whether a binding can be
authenticated, not the paths; group the user IDs according
to the certificate; and, show whether the components are expired
or revoked.
- Use the old output format if the user passes `--show-paths`.
- Fixes#240.
- Change `sq key generate` and `sq key userid add` to require
canonical user IDs by default.
- If a user ID is not in canonical form, explain the problem, and
suggest a solution, if possible.
- Allow the user to disable this check by passing the
`--allow-non-canonical-userids` flag.
- Fixes#209.
- Although Sequoia is able to use user ID-less certificates, they
don't have good support in the ecosystem, and are probably not
what most users want.
- Consequently, don't make user ID-less certificates the default.
Instead, require users to opt in by passing the `--no-userids` flag
to `sq key generate`.
- Fixes#223.
- Support using keys managed by `sequoia-keystore`.
- When decrypting a message, have `sq` automatically ask the
key store to decrypt the PKESKs.
- Extend `sq sign` and `sq encrypt` with the `--signer-key`
parameter to use a key managed by the keystore.
- Add two top-level options: `--no-key-store`, which disables the
use of the key store, and `--key-store`, which uses an alternate
key store instance.
- Add `sq key list` to list keys on the key store.
- Add --all to export all certificates.
- Add a query argument that can be a subkey fingerprint or key ID,
an email address, or a user ID fragment.
- Fixes#181.
- The `--help` output for most subcommands includes one or more
examples.
- We should test these, like we test everything else.
- Add a framework to format, and test the examples.
- Fixes#190.
- Also, fix some broken examples.
- Remove the offending argument. Without it, the linter will ask
for passwords on the tty, aligning it with the rest of sq.
Programmatic input of passwords is an open question, see #140.
- Fixes#168.
- When emitting revocation certificates, emit the revocation
signature with enough context so that it is a well-formed TPK,
i.e. include the primary key, the component to be revoked (if
revoking a user ID or subkey), and the revocation signature.
- Having a partial TPK instead of a bare revocation makes handling
it much easier, as it can be stored and transported like any
cert. It also gives the recipient of the certificate more
context, and simplifies merging it into a database of certs.
- Previously, there was a bug in sq where we would emit secret key
material when emitting revocation certificates. The reason for
that was that the certificate was first converted to a packet
stream, and then each packet serialized. In contrast, if a
Cert is serialized, no secrets are emitted unless the
programmer opts in. In a way, this is the more comprehensive fix
for the problem, as it leverages sequoia-openpgp's mechanisms to
protect secret key material.
- See #160.
- When doing a userid, subkey, or third-party certificate
revocation, with the cert given to --certificate-file containing
secret key material, we previously emitted a revocation
certificate containing secret key material.
- This patch changes that in a straight-forward way that is easy to
backport to prior versions. A more comprehensive fix will follow.
- Fixes#160.
- The dot-writer crate is unmaintained, and prevents upgrading sq in
Fedora. As a short-term workaround, we make this dependency
optional so that it can be easily patched out by packagers. The
same has been done for the sq-wot tool.
- https://gitlab.com/sequoia-pgp/sequoia-wot/-/issues/51
- https://gitlab.com/sequoia-pgp/sequoia-wot/-/issues/47
- If the situation improves, either because the crate is maintained
again, or we port to a different crate, we can easily undo this
change.
- Also, remove all the examples that use the dot output format. Not
only is it awkward to make these examples optional, the existing
examples are also very repetetive, as they duplicate an existing
example, and only change the output format.
- Fixes#146.
- Currently, sequoia-openpgp miscomputes notarization
signatures (see
https://gitlab.com/sequoia-pgp/sequoia/-/issues/1041) and fixing
that has proven to be difficult. Disable this functionality until
we sorted out the underlying implementation.
- A module `foo` used to have to be called `foo/mod.rs` if `foo` had
submodules.
- Since Rust 2018, it is possible to have `foo.rs` and the
submodules under `foo`.
- Using `foo.rs` is nicer than `foo/mod.rs` in many editors. Rename
modules called `mod.rs`.
- Note: we can't rename `src/cli/mod.rs` as it is `include!`ed from
`build.rs`, and then it doesn't find the submodules.
- Move the `sq revoke certificate`, `sq revoke subkey` and `sq revoke
userid` subcommands below the `sq key` namespace as `sq key revoke`,
`sq key subkey revoke` and `sq key userid revoke` (respectively). This
consolidates commands relevant to key management below `sq key`, which
is in line with already existing subcommands (e.g. `sq key generate`,
`sq key subkey add` or `sq key userid add`).
- Replace the use of a common `revoke()` with `CertificateRevocation`,
`SubkeyRevocation` and `UserIDRevocation` to reduce complexity and
allow for easier per target (i.e., certificate, subkey or userid)
command modification.
- Allow specifying an output file using `--output`/ `-o` for all
revocation subcommands (i.e., `sq key revoke`, `sq key subkey revoke`,
`sq key userid revoke`). If unspecified, output goes to stdout as
before.
- Add common test facilities to create a default certificate in a
temporary directory.
- Add common test function to compare a set of notations with those in
a `Signature`.
- Replace the integration tests which used to test a combined `sq
revoke` subcommand with integration tests for `sq key subkey revoke`,
`sq key userid revoke` and `sq key revoke` using direct and third
party revocation.
Fixes#93
This commit is mostly a copy over from the keyring-linter repository,
with a few changes included to make it work in the sq codebase. These
changes are:
- replaced calls to atty with calls to is-terminal. This was done due
to is-terminal already being in the dependency tree of sq, and atty
being unmaintained.
- replace ansi_term with termcolor, because ansi_term is unmaintained
- removed a few things from the keyring linter, that were also present
in sq itself, to avoid duplication. This included the reference time
parameter, key decryption and IO handling
- added output file and binary parameters to the linter, so that I
could handle output the same as the other commands do
Instead of using a non-uniform `--export` for `sq key generate` to
indicate the file path to output to, rely on the generic `--output`,
provided by `sq_cli::types::FileOrStdout`.