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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
- 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.
- 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
- This tracks the origin, like we do when we download certificates
over the network.
- This also has the benefit that newly created keys also show up in
the cert listing.
- Fixes#377.
- Some commands only access the cert or key store after they do a
lot of work. If the cert or key store is disabled, this is
annoying.
- Change `sq key generate`, `sq cert import`, `sq network search`,
`sq network keyserver search`, `sq network wkd search`, and `sq
network dane search` to error out early if they will save
something to the key store or the certificate, and it is disabled.
- Fixes#264.
- When there is no certificate or key store, but the command
requires it, return use a `clap::Error` instead of an
`anyhow::Error` so that the error is formatted better.
this simplifies permissions wrangling when bind mounting to host.
rootless podman is a preferred OCI runtime to docker, wherein superuser
within a container is simulated and not a security concern.
- When updating a WKD in `sq network wkd generate`, if a certificate
is not changed, don't insert it.
- If no certificates changed, and none were inserted, then don't
bother copying the WKD back.
