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 the semantics of `sq key userid revoke --email` to use a
user ID with just the specified email address, if the email
address is part of a self-signed user ID. That is, use the
`Exact` semantics instead of the `By` semantics. For example, if
a certificate has the self-signed user ID "Alice
<alice@example.org>", then `--email alice@example.org` would have
selected "Alice <alice@example.org>" for revocation, but now it
selects "<alice@example.org>".
- Add `sq key userid revoke --userid-by-email`, which uses the
self-signed user ID with the specified email address. For
example, if a certificate has the self-signed user ID "Alice
<alice@example.org>", then `--userid-by-email alice@example.org`
selects "Alice <alice@example.org>" for revocation.
- Fixes#212.
- Change the semantics of `sq pki vouch add --email` and `sq pki
vouch authorize --email` to use a user ID with just the specified
email address, if the email address is part of a self-signed user
ID. That is, use the `Exact` semantics instead of the `By`
semantics. For example, if a certificate has the self-signed user
ID "Alice <alice@example.org>", then `--email alice@example.org`
would have selected "Alice <alice@example.org>" for certification,
but now it selects "<alice@example.org>".
- Add `sq pki vouch add --userid-by-email`, and `sq pki vouch
authorize --userid-by-email`, which use the self-signed user ID
with the specified email address. For example, if a certificate
has the self-signed user ID "Alice <alice@example.org>", then
`--userid-by-email alice@example.org` selects "Alice
<alice@example.org>" for certification.
- Fixes#212.
- Change the semantics of `sq pki authenticate --email` and `sq pki
lookup --email` to use a user ID with just the specified email
address. That is, use the `Exact` semantics instead of the `By`
semantics. For example, if a certificate has the user ID "Alice
<alice@example.org>", then `--email alice@example.org` does not
select it.
- Add `sq pki authenticate --userid-by-email`, and `sq pki lookup
--userid-by-email`, which match user IDs with the specified email
address. For example, if a certificate has the user ID "Alice
<alice@example.org>", then `--userid-by-email alice@example.org`
selects it.
- Fixes#212.
- Change the semantics of `sq pki link add --email` and `sq pki
link authorize --email` to use a user ID with just the specified
email address, if the email address is part of a self-signed user
ID. That is, use the `Exact` semantics instead of the `By`
semantics. For example, if a certificate has the self-signed user
ID "Alice <alice@example.org>", then `--email alice@example.org`
would have selected "Alice <alice@example.org>" to link, but now
it selects "<alice@example.org>".
- Add `sq pki link add --userid-by-email`, and `sq pki link
authorize --userid-by-email`, which use the self-signed user ID
with the specified email address. For example, if a certificate
has the self-signed user ID "Alice <alice@example.org>", then
`--userid-by-email alice@example.org` selects "Alice
<alice@example.org>" to link.
- Fixes#212.
- Rename `--userid-or-add`, `--email-or-add`, and `--name-or-add`
respectively to `--add-userid`, `--add-email`, and `--add-name`.
- These names more closely match their new semantics: they don't
first try and match a self-signed user ID, but just use a user ID
consisting of the argument's value.
- Rename the `Exact` designator semantics to `By`. By default, the
`By` arguments are called `--userid`, `--userid-by-email`, and
`--userid-by-name`.
- Add a new set of designators called `Exact` for the arguments
`--userid`, `--email`, and `--name`. The semantics of `Exact`
are: the value must match a self-signed user ID, however, the
returned user ID is just the value, not the matching self-signed
user ID. That is, if there is a self-signed user ID `Alice
<alice@example.org>`, `--email alice@example.org` matches and
returns the user ID `<alice@example.org>`, and `--name Alice`
returns the user ID `Alice`.
- Change the semantics of `Add` user ID designators (by default,
`--userid-or-add`, `--email-or-add`, and `--name-or-add`) so that
they just return a user ID with just the specified value. That is
`--email alice@example.org` returns the user ID
`<alice@example.org>`.
- The following commands use user ID designators and their semantics
are unchanged:
- `sq key approvals list`: Unchanged.
- `sq key approvals update`: Unchanged.
- `sq pki authenticate`: Unchanged.
- `sq pki lookup`: Unchanged.
- `sq pki path`: Unchanged.
- The following commands use user ID designators and their semantics
changed as follows:
- `sq pki link add`: `--email-or-add` had the old `Add` semantics
and now has the new `Add` semantics.
- `sq pki link authorize`: `--email-or-add` had the old `Add`
semantics and now has the new `Add` semantics.
- `sq pki link retract`: `--email` had the old `Add` semantics and
now has the new `Add` semantics.
- `sq key userid revoke`: `--email-or-add` had the old `Add` semantics and
now has the new `Add` semantics.
- `sq key vouch add`: `--email-or-add` had the old `Add` semantics and
now has the new `Add` semantics.
- `sq key vouch authorize --email-or-add` had the old `Add`
semantics and now has the new `Add` semantics.
- Change `sq pki link add`, `sq pki link authorize`, `sq pki link
retract`, `sq pki vouch add`, and `sq pki vouch authorize` to
better handle unusable user IDs matched by `--all`. Specifically,
if the user explicitly designates a user ID and we can't use it,
then fail loudly, but if a user ID is selected by `--all` and it
not usable, only emit a warning.
- Remove the `success` parameter from `Sq::try_pki_vouch_add` and
`Sq::pki_vouch_authorize_p` and just propagate any error to the
caller. This is more consistent with the rest of the functions.
- `sq sign --signature-file` now takes a value specifying where the
signature should be written to. It conflicts with `--output`.
This aligns `sq sign` with `sq verify`.
- Fixes#444.
- 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.
