hm, if there's a guarantee that scdaemon will only ever be launched as a
subprocess from gpg-agent, then maybe we don't need it.
If there's ever any expectation that some other program will launch scdaemon,
then it would be nice to use the unified launch mechanism provided by gpgconf.
fwiw, the documentation says:
--try-all-secrets
Don't look at the key ID as stored in the message but try all
secret keys in turn to find the right decryption key. This
option forces the behaviour as used by anonymous recipients
(created by using --throw-keyids or --hidden-recipient) and
might come handy in case where an encrypted message contains a
bogus key ID.but that behavior is in fact not the default when used with anonymous
recipients, either:
2 dkg@alice:/tmp/cdtemp.hphmpn$ gpg --decrypt test.asc
gpg: encrypted with RSA key, ID 00000000
gpg: decryption failed: No secret key
2 dkg@alice:/tmp/cdtemp.hphmpn$ gpg --no-skip-hidden-recipients --decrypt test.asc
gpg: encrypted with RSA key, ID 00000000
gpg: decryption failed: No secret key
2 dkg@alice:/tmp/cdtemp.hphmpn$
I can confirm that this is still a problem on 2.1.13: --try-all-secrets does not
work as documented:
2 dkg@alice:/tmp/cdtemp.hphmpn$ gpg --try-all-secrets --decrypt test.asc
gpg: encrypted with RSA key, ID 00000000
gpg: decryption failed: No secret key
2 dkg@alice:/tmp/cdtemp.hphmpn$ gpg --try-secret-key test --decrypt test.asc
gpg: anonymous recipient; trying secret key 82A22A9306735B0C ...
gpg: okay, we are the anonymous recipient.
gpg: encrypted with RSA key, ID 00000000
test test
0 dkg@alice:/tmp/cdtemp.hphmpn$
Sorry, this is a duplicate of T2391. apparently i accidentally
double-clicked and roundup doesn't protect against that sort of thing. :/
(that last comment was with 2.1.13)
fwiw, when i'm on a network that doesn't support IPv6, i get this:
0 dkg@alice:~$ gpg --send $KEYID
gpg: sending key REDACTED to hkps://hkps.pool.sks-keyservers.net
gpg: keyserver send failed: Invalid argument
gpg: keyserver send failed: Invalid argument
2 dkg@alice:~$
in dirmngr's logs:
2016-06-17 19:30:17 dirmngr[27999.2] DBG: gnutls:L3: ASSERT: mpi.c:246
2016-06-17 19:30:17 dirmngr[27999.2] DBG: gnutls:L5: REC[0x7f61f400fc10]:
Allocating epoch #0
2016-06-17 19:30:17 dirmngr[27999.2] can't connect to '2001:ba8:1f1:f2d4::2':
Invalid argument
2016-06-17 19:30:17 dirmngr[27999.2] error connecting to
'https://[2001:ba8:1f1:f2d4::2]:443': Invalid argument
2016-06-17 19:30:17 dirmngr[27999.2] DBG: gnutls:L5: REC[0x7f61f400fc10]: Start
of epoch cleanup
2016-06-17 19:30:17 dirmngr[27999.2] DBG: gnutls:L5: REC[0x7f61f400fc10]: End of
epoch cleanup
I think this instance of dirmngr was started on a network that has both IPv4 and
IPv6.
if i do:
gpg-connect-agent --dirmngr killdirmngr /bye
and then try the --send again, it goes through fine.
We could bail early if we see something like this.
But since percent-unescaping is supposed to be able to handle arbitrary
characters (and consumers of this data have to percent-unescape anyway), why not
escape the record separator instead of bailing?
This looks great to me. I've always been frustrated by the c+p difficulty.
Does it make sense to put an "fpr" at the beginning of the fingerprint line, to
match with "pub" and "uid" ?
For example:
pub dsa2048 2007-12-31 [SC] [expires: 2018-12-31]
fpr 80615870F5BAD690333686D0F2AD85AC1E42B367
uid [ full ] Werner Koch <wk@gnupg.org>
Have you started work on this change or would you like patches?
(btw, "fingerprint" should be 40 hex chars, not 32 as if suggested)
For modern gnupg, we no longer support v3 keys, and we're considering making
--with-fingerprint the default (see
https://lists.gnupg.org/pipermail/gnupg-devel/2016-January/030748.html), so i
think this suggestion should actually be reconsidered.
fwiw, i first encountered this by doing a full-keyring refresh from the
keyservers. Dying rather than adjusting or accomodating the malformed header
meant that all keys after this one failed to refresh.
In general, dying outright seems likely to make an observed problem worse than
it needs to be.
I'm not convinced that this policy is effectively implemented in gpg-agent.
The patch series that starts here:
https://lists.gnupg.org/pipermail/gnupg-devel/2016-May/031121.html
resolves the export of secret key material stored as cleartext, and it does so
without modifying gpg-agent at all.
fwiw, I do not agree with T2324 (justus on Apr 18 2016, 05:22 PM / Roundup) that gpg --batch should not use pinentry at
all -- i think it's quite useful to be able to combine --batch with pinentry,
where the key is stored protected, or is otherwise marked by gpg-agent for
limited use.
I don't think this is actually resolved.
As noted in https://lists.gnupg.org/pipermail/gnupg-devel/2016-April/031032.html
, gpgv accepts signatures made from revoked or expired keys.
It should reject signatures made from keys it believes to be revoked or expired.
The attached tarball contains:
pubkey.gpg -- a binary-format 2048-bit RSA OpenPGP certificate
C47D9EDFF117EE2AA11B162D017D715B3D0C4AF2.key -- the corresponding
secret key (for
reference/experimentation
only)
before.txt.asc -- clearsigned message made by the key before
certificate creation time
during.txt.asc -- clearsigned message made by the key between
certificate creation and certificate expiration
after.txt.asc -- clearsigned message made by the key after certificate
expirationof these, gpg approves of during.txt.asc and after.txt.asc, but not before.txt.asc.
Thanks for the explanation, Werner.
This note might also be worth adding to the gpg-preset-passphrase manpage.
Thanks for looking into this, Justus.
While you're working on this, it might make sense to consider restoration of the
--export-options export-reset-subkey-passwd flag, which was dropped in 2.1.
This flag was used by at least one GnuPG downstream (monkeysphere); its absence
causes "monkeysphere subkey-to-ssh-agent" to fail.
In GnuPG 1.4.x and 2.0.x, the option was defined this way:
export-reset-subkey-passwd
When using the --export-secret-subkeys command, this
option resets the passphrases for all exported subkeys to
empty. This is useful when the exported subkey is to be
used on an unattended machine where a passphrase doesn't
necessarily make sense. Defaults to no.furthermore, if the user enters an empty password, gpg-agent says "please
confirm that you do not want to have any protection on your key".
If the user chooses "yes, protection is not needed" in this followup prompt, gpg
*still* refuses to export the secret key, producing this error message:
gpg: key 0CA2C754F8DF3194EC1F1C7EF88AEA8D20BAFB0F: error receiving key from
agent: No passphrase given - skipped
I understand the reason for re-encrypting -- i'm quite happy that the agent is
sensible about improving the security of the key when it adopts it.
my concern is that users don't know what to expect, and that different workflows
result in different sets of keys stored in the agent.
So i'd recommend that when importing without --batch, if the password fails for
any reason, gpg should fall back to the fast migration "kludge" rather than just
skipping that keyblock. That way the imported secret key material will still be
available and can be cleaned up/hardened on first successful use.
I'm not convinced that the +-prefixed lines address clint's concern.
In particular, the parenthetical remark "(domain means the domain part of the
mail address)" is the important bit -- will this be documented somewhere?
I'm changing this from "nobug" to "bug", because it is clearly causing problems
for people with separate per-device signing keys, or with multiple smartcards
(e.g. work and home)
I don't think this is a doc or FAQ issue, i think it's an actual bug that has a
significant effect on usability.
If gpg has an available key that would work, it should use it, rather than
preferring the unavailable key.
If the user explicitly specifies an unavailable subkey then sure, gpg should
fail. But if they've only specified their primary (or their UID) then gpg
should be willing to use any available active (non-revoked, non-expired) subkey
with the right usage flags instead of failing if an unavailable one has a newer
date.
fwiw, i've now got most of GnuPG cross-building for win32 from a debian platform
using win-iconv. win-iconv doesn't seem to be a terrible choice to me.
I'm also interested in this, since i want to make it possible to easily build a
win32 version of gpgv.exe on debian systems. This is possible without iconv at
all in 1.4.x, but i would rather we ship a gpgv from 2.1.x in the future.
I'm happy to see GnuPG moving to an all-agent model, where the passphrase and
the asymmetric secret key material aren't available to the gpg process.
That sai, if gpgme is going to remove the passphrase_cb prompt, or to deprecate
it in all cases other than symmetric data encryption/decryption, then should the
API change?
gpgme_set_passphrase_cb is used in about 40 packages in debian:
https://codesearch.debian.net/results/gpgme_set_passphrase_cb/page_0
this includes bindings for python, ruby, php, and c++ -- and it's possible that
those bindings themselves have some other usage elsewhere.
Do we have guidance for users of this function, whether it's with gpgme
directly, or with any of the bindings?
Hm, this is indeed fixed for pinentry-gtk2 and pinentry-gnome3, but pinentry-qt
is still broken:
0 $ DISPLAY=:3 pinentry-qt
QXcbConnection: Could not connect to display :3
Aborted
134 $
I'm attaching an updated patch that doesn't just ship sks-keyservers.netCA.pem
in the distributed tarball, but installs it during "make install" in pkgdatadir,
and then checks during query time to see if it should be used.
In particular, if the user asks for "hkps://hkps.pool.sks-keyservers.net" and
they haven't specified any hkp-cacert argument in dirmngr, it automatically
tries to load the bundled cert.
pinentry-gtk-2 does currently support the tab-tab-enter use case. Using 0.9.6-4
from debian, i can use tab to cycle between the textentry dialog and cancel and OK.
I see the same behavior from pinentry-gnome3 (0.9.6-4), tab workflow is:
for pinentry-qt (same version as tested above) the tab ordering is:
That said, i agree that i'm the only person who has raised this, and i'm
perfectly willing to be retrained to use more efficient keyboard flows if
they're presented to me. So if you want to go ahead with the current plan,
that's fine with me.
I agree that consistency with common UI patterns on the platform of choice are
worth emulating -- we don't need to invent or maintain our own UI patterns that
are idiosyncratic to GnuPG.
On Thu 2015-10-29 04:34:03 -0400, Bernhard Reiter via BTS wrote:
Some people are used to pinentry and have a common keyboard-based type, tab, hit
enter workflow.
Please make sure that this workflow doesn't accidentally switch their password
to visible when this change is implemented.
Yes, thanks for the quick review and merge! I assume this will be released in
whatever release comes after 2.1.9.
I'm setting the status here to "resolved".
With recent versions of OpenSSH, the default fingerprint shown is uses SHA256.
The fingerprints emitted in sshcontrol are MD5. You can get ssh-keygen -l to
produce comparable MD5 fingerprints with "-E md5".
Perhaps the generated sshcontrol should also include the base64-encoded SHA256
fingerprints as well, though?
That still doesn't explain why ecdsa 384 keys are mis-fingerprinted, though.
This is still a problem with 2.1.8
can you explain why the limit is useful? e.g. does it increase efficiency in
some metric? defend against certain classes of attack? something else? sorry
that i don't understand the tradeoff fully.
a runtime configuration would be better than a hard fail, but in either case it
seems like we're asking the user to fiddle with things that they shouldn't have
to think about or understand. is there a way that we can automatically detect
the reason for the failure and make things Just Work for normal users without
opening up the tooling to more problems?
with 2.1.7, i see no hang, but i do see failure with certain large certificates,
like 0xB27B944E34884E85:
0 dkg@alice:~$ gpg2 --send 0xB27B944E34884E85
gpg: sending key 0xB27B944E34884E85 to hkps server hkps.pool.sks-keyservers.net
gpg: keyserver send failed: Too much data for IPC layer
gpg: keyserver send failed: Too much data for IPC layer
2 dkg@alice:~$
maybe the boundary is 500KiB? I don't have this problem with my own OpenPGP cert:
0 dkg@alice:~$ gpg2 --export 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9 | wc
3126 11384 481051
0 dkg@alice:~$ gpg2 --export 0xB27B944E34884E85 | wc
4310 13779 541937
0 dkg@alice:~$
hm, common/utf8conv.c says this:
/* Note that we silently assume that plain ASCII is actually meant
as Latin-1. This makes sense because many Unix system don't have
their locale set up properly and thus would get annoying error
messages and we have to handle all the "bug" reports. Latin-1 has
always been the character set used for 8 bit characters on Unix
systems. */I wonder if this is still the best choice. In my experience, far more machines
have text in some UTF-8 encoding today than in Latin-1. this is especially true
for systems that deal with OpenPGP User IDs, where UTF-8 is the canonical
representation.
If the user's environment claims that it's plain ASCII and we're seeing 8-bit
characters, gpg does have to make a decision about what to do. i see four options:
a) report an error and fail.
b) pretend that the 8-bit characters are Latin-1 (this is "OK" because any
bytestring is a valid Latin-1 string)
c) pretend that the 8-bit characters are UTF-8
d) do some sort of autodetection on the bytestring (e.g. if it is a valid UTF-8
byte sequence then treat as UTF-8, otherwise treat as Latin-1)
option (a) is annoying and likely a cause of spurious complaints, as the comment
notes. GnuPG is currently going with option (b). Option (c) seems more
reasonable to me because of OpenPGP's relationship with UTF-8, but introduces
some error cases (what do we do where the bytestring is not valid UTF-8?).
Option (d) avoids error cases but might be a bit more delicate to implement.
What do you think?
I think werner means --utf8-strings instead of --utf-strings.