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 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.
- 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.
- 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.
- 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
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`.
- Change the behavior of the `sq certify`, `sq key generate` and `sq
link add` subcommands to rely on a single `--expiry` input argument
(same as `sq key subkey generate`), which replaces `--expires` and
`--expires-in`. This allows to directly parse a specific ISO 8601
timestamp, a custom duration or `"never"` and create a verified data
type that can be used further.
- Use `Expiry::as_duration()` in `sq certify` and `sq key`
subcommands to calculate the validity (duration until expiration) of
certifications and keys.
- Add the constants `KEY_VALIDITY_IN_YEARS` and
`THIRD_PARTY_CERTIFICATION_VALIDITY_IN_YEARS` to `sq_cli` to allow
centralized modifications of the default validity duration of keys and
certifications (in years).
- Add the constants `KEY_VALIDITY_DURATION` and
`THIRD_PARTY_CERTIFICATION_VALIDITY_DURATION` to provide
the default `Duration` for keys/subkeys and third party
certifications (based on `KEY_VALIDITY_IN_YEARS` and
`THIRD_PARTY_CERTIFICATION_VALIDITY_IN_YEARS`).
- Add `sq key subkey add` to allow to add a newly generated `SubKey` to
an existing key.
- Add `sq_cli::types::Expiry` to allow providing expiry with a
single `--expiry` input argument, that covers providing an ISO 8601
timestamp, a custom duration and "never".
- Add impl block for `sq_cli:🔑:CipherSuite` to allow returning a
`sequoia_openpgp::cert::CipherSuite`.
