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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
- `Sq::decrypt_key`, `Sq::get_signer`, `Sq::get_keys`,
`Sq::get_primary_keys`, `Sq::get_primary_key`,
`Sq::get_signing_keys`, `Sq::get_signing_key`,
`Sq::get_certification_keys`, and `Sq::get_certification_key`
return a signer or decryptor, as well as the password used to
unlock the key, if any. No callers actually use the password, and
the returned password is not reliable, because the key may be
managed by the secret key server, and already be unlocked, or the
key may be unlocked externally, and the password is not available.
- Simply the functions and don't return the password.
- When adding a new subkey, we implicitly reuse the password that
was used to unlock the primary key.
- These semantics are confusing. If the key is managed by the
secret key store, we may not have to prompt the user for the
password, because the key is already unlocked, or because the key
is protected by an external password. In these cases, since we
don't actually unlock the primary key, the new subkey won't be
password protected even though the primary key is!
- Be more predictable, and don't automatically reuse what we think is
the primary key's password.
- `sq key export` can either export all keys associated with a
certificate or individual keys.
- Split the subkey-related functionality out of `sq key export` and
into the new subcommand `sq key subkey export`
- Fixes#294.
- The dot output does not fit into the output framework: it can only
describe graphs, and most of what sq emits are not graphs. Once
sq gains machine-readable output, the current functionality can be
implemented by emitting the graph data as machine-readable data,
then transforming it into dot.
- Fixes#290.
- Fixes#137.
- During development, we added short options, even for arguments
that may not be used often, or those we don't want people to use
often. Remove them now, and judiciously add them before releasing
1.0 for the most important options.
- See #303. Fixes#302.
- A user ID is an OpenPGP concept. Most people think in terms of
names and email addresses.
- Add and promote --name and --email arguments for sq key userid
add.
- Fixes#291.
- A user ID is an OpenPGP concept. Most people think in terms of
names and email addresses.
- Add and promote --name and --email arguments for sq key generate.
- See #291.
- Previously, if a cert was discovered, that in the subsequent
iteration was not found again, this was considered an error, even
though the whole operation should be considered a success because
a cert was indeed found.
- Notably, if a cert was fetched over http which could not otherwise
be found in the local cert store, key server, via WKD or DANE,
an error was returned and the cert was not imported.
- Fix this by considering the operation successful if we found at
least one cert.
- Fixes#300.
- Add a new subcommand, `sq key subkey password`, which changes the
password protecting the secret key material of a primary key or a
subkey.
- Fixes#106.
- Add `Sq::key_password` and `Sq::sign` based on the code in the
`sq key password` test.
- Implement the `sq key password` test in terms of those functions.
- If a key specified using `--recipient-file` does not contain
secret key material, don't panic, just skip it.
- It is perfectly reasonable for only a subset of keys in a
TSK to contain secret key material.
- Extend `Sq::decrypt_key` to take an additional argument,
`may_prompt`, which causes `Sq::decrypt_key` to fail rather than
prompt the user for a password.
- Having multiple positional arguments makes it hard to remember the
order. Just make the domain a long argument.
- Further, format the examples nicer by preventing line breaks
between argument name and value.
- These leak implementation details and support the idea that WKD is
just a http request to some URL, which is not true, and will be
less true in the future. I don't think this is an interface that
we can support going forward.
