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 cert list`, `sq pki authenticate`, `sq pki lookup`, `sq
pki identify`, and `sq pki path` to use `stdout`, not `stderr`, for
their main output.
- See #342.
- 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.
- 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.
- 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.
- 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.
- 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.
- Fixes#452.
- Currently, it is not possible to delete secret key material that
is only associated with a certificate that is not valid under the
current policy. The same goes for changing the password protecting
the secret key material.
- Users shouldn't have to first update a key's binding signature to
delete it, or change its password.
- Change `sq key subkey delete` and `sq key subkey password` to use
the null policy. This is not a security concern, because even if
the binding signature is weak, both the certificate and the key
are explicitly named.
- See #375
- Change `sq key approvals list` and `sq key approvals update` to
ignore certifications that are not exportable, and certificates
that are not exportable, or are a shadow CA.
- Fixes#402.
- Rename `--add-userid` to `--userid-or-add`, `--add-email` to
`--email-or-add`, and `--add-name` to `--name-or-add`. The new
names better reflect the semantics: we first try to select a user
ID based on the designator, and then fall back to adding it as it.
- The implementation of `sq cert list` tried to parse the
pattern. To do so, it relied on type inference to determine how
to parse it. The type was inferred from the type of the `cert`
parameter to `authenticate`. In
2e17dec9ad, the type of the `cert`
parameter changed from `KeyHandle` to `Cert`. `Cert` has a
`Parse` implementation so the type system didn't detect anything
wrong. However, we were now trying to parse the pattern as a
`Cert` instead of a `KeyHandle`, which would fail for key handles.
- Fix it, and add some tests for `sq cert list`.
- When a user ID designator designates a user ID that is not
self-signed, and the command would add it to the certificate, check
that it is in canonical form.
- The relevant commands are: `sq key userid revoke`, `sq pki link
add`, `sq pki link authorize`, `sq pki vouch certify`, and `sq pki
vouch authorize`
- Allow the user to disable the check with a new flag,
`--allow-non-canonical-userids`.
- Fixes#437.
- Port `sq cert list`, `sq pki authenticate` and `sq pki lookup` to
the user ID designator framework. See #434.
- This changes the user ID parameter from a positional parameter
to a named parameter, and drops the `--email` flag. See #318.
- Port `sq pki authenticate` and `sq pki identify` to the cert
designator framework. See #207.
- This changes the certificate parameter from a positional parameter
to a named parameter. See #318.
- Port `sq key userid revoke` to the user ID designator framework.
See #434.
- This replaces the `--add-userid` flag with the `--add-userid`,
`--add-email` and `--add-name` arguments. See #318.
- This change also makes a user ID mandatory, which fixes#428.
- Commands like `sq pki vouch certify` allow designating a user ID
by email address. Currently, if multiple self-signed user IDs
include the specified email address, all are used. Change the
semantics of `--email` and --add-email` to only match
unambiguously.
- Fixes#309.
- `sq pki link add`, `sq pki link authorize`, `sq pki vouch
certify`, and `sq pki vouch authorize` have a `--add-userid` flag.
- Replace the `--add-userid` flag with an `--add-userid` argument,
and an `--add-email` argument.
- This change means that a flag does not change how an argument is
interpreted. It also makes it more explicit whether a user ID
should be added, because `--userid` and `--email` could be given
multiple times.
- See #309 and #318.
- When `sq pki authenticate` fails, it is helpful to see as much
details as possible. As such, include `--show-paths` when calling
`sq pki authenticate`. `--show-paths` shows more information, but
doesn't change the command's behavior.
- 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`.
- Fixes#430.
- Previously, the signers cert designators added to the set of certs
in the store, and marked them as trusted.
- Change this so that only the designated certs are used to verify
the signatures, and they are marked as trusted. This allows
useful semantics like requiring a signature from a set of
explicitly provided signers.
- If no signers are designated, the cert store is consulted.
- Fixes#248.
- Add a new argument, `--cli-version`, which the user can use to
request a particular semver-compatible version of the CLI.
- This enables breaking changes to the CLI, and enables `sq` to
support multiple CLI versions.
- Fixes#75.
