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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
- This adds a mechanism to add a list of certificates presumably
owned by the user to the recipients using the `--for-self` flag.
This makes sure the encrypted message can be decrypted again.
- Fixes#461.
- User IDs have to be explicitly given, or `--all` has to be used to
select them all (this was previously the default).
- This aligns the retract subcommand with the other link and vouch
management commands.
- Fixes#442.
- Add a new paramter to `sq pki link add`, `sq pki link authorize`,
and `sq pki link retract`, `--cert-special`, which allows addressing
shadow CAs by symbolic names.
- If the shadow CA doesn't exist yet, we create it.
- This means `sq pki link authorize --cert-special keys.openpgp.org
--all --unconstrained` can be used to fully trust the
`keys.openpgp.org` key server, for instance. This is more
convenient, and especially useful for documentation.
- Fixes#337.
* Changes in 0.40.0
** New functionality
- New subcommand `sq download`, which downloads a file and a
signature file, and then authenticates the file.
** Notable changes
- `sq toolbox keyring merge` now supports merging bare revocation
certificates.
- `sq verify` now deletes the output file on failure.
- `sq decrypt` now deletes the output file on failure.
- Add a global option, `--policy-as-of`, that selects the
cryptographic policy as of the specified time.
- `sq key subkey export` takes an additional argument, `--cert`,
which is required. The specified keys must be attached to that
certificate. This ensures that if a key is attached to multiple
certificates, the correct certificate is exported.
- Add a new argument, `--cli-version`, which requests a particular
semver-compatible version of the CLI. This enables breaking
changes to the CLI in the future.
- The `help` subcommand has been removed everywhere except at the
top-level (`--help` still works).
- If designated signers are specified for `sq verify`, `sq
decrypt`, and `sq download`, they are now the only certificates
that are considered when verifying signatures. If no signers are
specified, the certificate store is consulted.
- The argument `sq cert lint --list-keys` has been removed.
- `sq key list` now has a DWIM search parameter.
- The flag `sq sign --detached` is now called `sq sign
--signature-file`.
- The flag `sq sign --clearsign` is now called `sq sign
--cleartext`.
- Both `sq sign` and `sq verify` now require an explicit mode,
one of `--signature-file`, `--message`, or `--cleartext`.
- The flag `sq --no-cert-store` has been replaced with `sq
--cert-store=none`.
- The flag `sq --no-key-store` has been replaced with `sq
--key-store=none`.
- Similarly, `sq --home=none` disables all state, unless explicitly
re-enabled using `--cert-store` or `--key-store`.
- `sq pki link add`, `sq pki link authorize`, `sq pki vouch
certify`, and `sq pki vouch authorize` have a `--userid-or-add`
flag. Replace it with an `--userid-or-add` argument, and an
`--email-or-add` argument.
- The `--email` and `--email-or-add` arguments to `sq pki link add`,
etc. cannot be used to designate a self-signed user ID, if
multiple self-signed user IDs include the specified email
address. Previously, the arguments would designate all
self-signed user IDs with the specified email address.
- The new argument `sq sign --mode` can be used to create text
signatures in addition to binary signatures.
- The argument `sq network wkd publish --create` has been split
into two arguments, `--create` and `--method`, avoiding an
ambiguity when parsing the arguments.
- `sq key userid revoke` no longer accepts the `--userid-or-add` flag
to indicate that a user ID specified using `--userid`, an email
specified using `--email`, or a name specified using `--name`
should be used even if there is no corresponding self-signed user
ID. This functionality is replaced by the `--userid-or-add`,
`--email-or-add` and `--name-or-add` arguments.
- `sq pki path` previously interpreted the last positional argument
as the user ID to authenticate. Make it a named argument
instead, `--userid`.
- Add `sq pki path --email` and `sq pki path --name` as additional
ways to specify the user ID to authenticate.
- The argument `sq encrypt --set-metadata-time` has been removed.
- The argument `sq encrypt --set-metadata-filename` now takes a
string that specifies the file name to be set.
- `sq pki authenticate`'s positional argument for specifying the
certificate to authenticate must now be specified using a named
argument, `--cert`.
- `sq pki identify`'s positional argument for specifying the
certificate to identify must now be specified using a named
argument, `--cert`.
- Drop `sq cert list --email`'s flag, and replace it with the
`--userid` and `--email` positional arguments, which match on
user IDs.
- Drop `sq pki authenticate --email`'s flag, and replace it with
the `--userid` and `--email` positional arguments, which match on
user IDs.
- Drop `sq pki lookup --email`'s flag, and replace it with the
`--userid` and `--email` positional arguments, which match on
user IDs.
- `sq toolbox keyring` is now just `sq keyring`.
- `sq toolbox packet` is now just `sq packet`.
- `sq toolbox armor` is now `sq packet armor`.
- `sq toolbox dearmor` is now `sq packet dearmor`.
- `sq key userid revoke`, `sq pki link add`, `sq pki link
authorize`, `sq pki vouch certify`, and `sq pki vouch authorize`
now check that user IDs that are not self-signed are in canonical
form. Add a flag, `--allow-non-canonical-userids`, to disable
this check.
- `sq key approvals update` now requires an action, like
`--add-authenticated`.
- `sq key approvals --add-authenticated` is now a simple flag, and
we always require full authentication.
- `sq toolbox strip-userid` has been removed.
- All cert designators now use the `--cert-` prefix, e.g. `sq key
export --email` has been changed to `sq key export --cert-email`
for consistency reasons, and to free `--name`, `--email`, and
`--userid` for user ID designators.
- The `--binary` argument has been removed from all commands but
those that emit signed and or encrypted messages.
- The command `sq toolbox extract-cert` has been removed in favor
of `sq key delete` and `sq key subkey delete`.
- The command `sq packet split` now writes to stdout by default.
- The argument `sq packets split --prefix` is now called
`--output-prefix`.
- `sq pki vouch certify` is now called `sq pki vouch add`.
- We now certify newly generated keys with a per-host shadow CA.
- The argument `sq encrypt --signature-notation` has been added.
- All arguments to add signature notations have been renamed from
`--notation` to `--signature-notation`.
- When generating keys, either `--own-key` or `--shared-key` has to
be given. The former marks the key's user IDs as authenticated
and makes it a trusted introducer. The latter marks the key's
user IDs as authenticated, and marks the key as a group key.
- The argument `sq cert lint --export-secret-keys` has been
removed: if a secret key is provided as file input, it will be
emitted.
- The argument `sq key subkey export --cert-file` has been removed.
- `sq` now reads a configuration file that can be used to tweak a
number of defaults, like the cipher suite to generate new keys,
the set of key servers to query, and the cryptographic policy.
- The command `sq keyring filter` is now considered experimental
and may change in the future. To acknowledge this, it has to be
invoked with the `--experimental` flag.
- Invoking it now requires the `--experimental` flag. This is a
template that we may use to introduce features into sq with a bit
of a chance to stabilize it over time.
- Fixes#455.
- Add a configuration file for sq, and sq config get to
programmatically query configuration values, and sq config template
to create a template as a starting point for a custom configuration
file.
- As a first step, the following things have been made configurable:
- The cipher suite for key generation.
- The set of keyservers.
- The cryptographic policy, which can be sourced from an external
file as well as modified inline.
- If there is no configuration file, sq config template can be used to
create a template for the user to modify.
- If a default has been overridden using the configuration file,
sq's --help output is augmented with the configured value.
- Align user ID designators across these four commands. Previously,
`--all` was implied for the authorize commands if no user ID
designator was given.
- However, this is problematic for the following reasons:
- First, it is inconsistent across the commands.
- Second, while CAs can add any name to their cert because they
are CAs, those certifications are subject to constraints, such
as domain constraints, or the amount. But, the link we add
fully authenticates the current user IDs, which may not be what
the user wants, so it should require explicit consent.
- Third, making this implicit again is easier than going from
implicit to explicit, which breaks existing users.
- Fixes#442.
- Change `sq key userid revoke` to require the certificate be valid
under the current policy. If the certificate is not valid under
the current policy, the user should revoke the whole certificate,
or fix it using `sq cert lint` after verifying the certificate's
integrity. If the certificate is valid under the current policy,
but the user ID to revoke isn't, it can still be revoked using
`--userid-or-add`.
- See #375.
- When prompting to unlock a key, show the key's fingerprint, the
key's creation time, and its key flags. Don't show the
certificate's fingerprint. That's constant.
- When we actually change a password, show a message, which can be
silenced with `--quiet`.
- Change `sq key password` to also change the password of keys that
are weakly bound. Users are likely to be more surprised when a
password is not changed.
- `sq key delete` and `sq key password` fail if any of the keys are
missing secret key material.
- Change them to work with the available secret key material. (But
if there is none, still fail.)
- `sq key delete` deletes all secret key material associated with a
certificate. Of course, we don't want to delete secret key
material that we are not confident belongs to the certificate.
- Imagine Alice creates a new certificate. Mallory see this, and
anticipates that she is going to delete the old certificate. He
attaches her new encryption-capable subkey to the old certificate
using some weak cryptography, publishes it, and then Alice gets
the update to her old certificate via parcimonie. When she
deletes the secret key material associated with the old
certificate, she would also delete her new secret key material.
Ouch! Admittedly, this attack is a bit contrived.
- Alternatively, we could skip subkeys whose bindings rely on
weak cryptography. This behavior would probably surprise most
users. It could have serious consequences as well, since the
user thought they deleted the secret key material, but didn't.
- Instead, we are conservative: if a subkey's binding signature
relies on weak cryptography AND we have secret key material for
it, we abort, and suggest using `sq key subkey delete` instead.
- See #375 and #457.
