I don't count win-iconv a small helper.
We can solve this problem more easily by moving the ut8conv.c code to
libgpg-error which alread has some of the conversion code.
I change the category to whis because this is not a bug but a build requirement.
This was implemented for 2.1. We won't backport it to 1.4 or 2.0.
Right, getkey_next had a somewhat surprising semantic. I fixed that with commit
b280aa6.
It also works with ECDSA keys.
Current master b2da3951 segfaults on me.
Btw. I think this is likely because i have a local ID without an Authentication
subkey for aheinecke@gnupg.org
(gdb) run --export-ssh-key aheinecke@gnupg.org
Starting program: /opt/gnupg/bin/gpg2 --export-ssh-key aheinecke@gnupg.org
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: enabled debug flags: memstat
Program received signal SIGSEGV, Segmentation fault.
lookup (ctx=ctx@entry=0x6dd940, ret_keyblock=ret_keyblock@entry=0x0,
ret_found_key=ret_found_key@entry=0x7fffffffd998,
want_secret=<optimized out>) at ../../g10/getkey.c:3116
3116 *ret_keyblock = keyblock; /* Return the keyblock. */
(gdb) bt full
#0 lookup (ctx=ctx@entry=0x6dd940, ret_keyblock=ret_keyblock@entry=0x0,
ret_found_key=ret_found_key@entry=0x7fffffffd998,
want_secret=<optimized out>) at ../../g10/getkey.c:3116
rc = 0
no_suitable_key = 0
keyblock = 0x0
found_key = 0x701980#1 0x0000000000415bb6 in getkey_next (ctx=0x6dd940, pk=0x0, ret_keyblock=0x0)
at ../../g10/getkey.c:1636
rc = <optimized out> found_key = 0x0
#2 0x000000000045713a in export_ssh_key (ctrl=0x6dd810, userid=0x7fffffffe420
"aheinecke@gnupg.org") at ../../g10/export.c:1437
getkeyctx = 0x6dd940
keyblock = 0x6fd160
desc = {mode = KEYDB_SEARCH_MODE_SUBSTR, skipfnc = 0x0, skipfncvalue =0x0, sn = 0x0, snlen = 0, u = {
name = 0x7fffffffe420 "aheinecke@gnupg.org", fpr = "
\344\377\377\377\177", '\000' <repeats 17 times>, kid = {
4294960160, 32767}, grip = " \344\377\377\377\177", '\000'
<repeats 13 times>}, exact = 0}
curtime = 1452288169
pk = 0x0
identifier = 0x6ddb80 ""
mb = {len = 0, size = 4096, buf = 0x6e5d70 "", out_of_core = 0}
fp = 0x6dd810
b64_state = {flags = 7199040, idx = 0, quad_count = -153676256, fp =0x10, stream = 0x6dd800, title = 0x6ddb80 "",
radbuf = "\000\000\000", crc = 0, stop_seen = -1, invalid_encoding =
0, lasterr = 0}
fname = 0x7fffffffe420 "aheinecke@gnupg.org"
#3 0x000000000040dc00 in main (argc=1, argv=0x7fffffffdfe8) at ../../g10/gpg.c:4193
pargs = {argc = 0x7fffffffdb9c, argv = 0x7fffffffdb90, flags = 32769,err = 0, r_opt = 0, r_type = 0, r = {ret_int = 0,
ret_long = 0, ret_ulong = 0, ret_str = 0x0}, internal = {idx = 2,inarg = 0, stopped = 1,
last = 0x7fffffffe420 "aheinecke@gnupg.org", aliases = 0x0,
cur_alias = 0x0, iio_list = 0x0}}
a = 0x6dd800
orig_argc = 0
orig_argv = 0x6ddb80
fname = 0x7fffffffe420 "aheinecke@gnupg.org"
sl = 0x0
remusr = 0x6ddb40
locusr = 0x0
nrings = 0x0
afx = 0x7fffffffe420
configfp = 0x7fffffffe420
configlineno = 27
parse_debug = 7198720
cmd = aExportSshKey
malloc_hooks = {malloc = 0x405ee0 <gcry_malloc@plt>, realloc = 0x406d40<gcry_realloc@plt>, free = 0x406290 <gcry_free@plt>}
ctrl = 0x6dd810
Done with commit 4970868 to be released with 2.1.11.
This uses a new command and not an export option so that export options can be
kept in the conf file.
ECDSA keys (NIST keys) do not yet work.
Right, this is what I actually had in mind. Using the "<keyid>!" notaion it
would also be possible to export any primary of subkey in ssh format.
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 $
That fingerprint looks more like gibberish than something which should be
compared by the user. In that regard a SHA-1 fingerprint looks much more
serious and IMHO will be more secure than a base-64 fingerprint where you have
to explain that the users also need to match the case - if they are at all able
to compare that fingerprint.
We should take this to the mailing list.
It is base64 trimmed the last '='.
Introducing new specifier, say %f, would be good, while keeping %F as is.
%f includes the hash algorithm string as SSH does.
I confirmed that this is fixed in 2.0 and 2.1.
I wonder if this is a Problem for the new version that can send through
exchange. Available from ( https://wiki.gnupg.org/Gpg4win/Testversions ) We look
up the sender address with exchange a bit differently and I think it should
match the actual SMTP address used now.
It seems to be base64:
% ssh -V
OpenSSH_7.1p1 Debian-3, OpenSSL 1.0.2e 3 Dec 2015
% ssh-keygen -l -f .ssh/known_hosts -F playfair.gnupg.org -E md5 -q
playfair.gnupg.org RSA MD5:cc:dd:46:8e:ef:3d:d9:34:97:f8:b8:5a:59:51:80:4a
% ssh-keygen -l -f .ssh/known_hosts -F playfair.gnupg.org -E sha256 -q
playfair.gnupg.org RSA SHA256:KCh034SD0rMKqCkJbdH2wx354s1278tqt9F+xb5cidg
The keyserver preferences are major privacy problem. They should not be used
and in fact they are ignored in Tor mode. Thus we should not put too much work
in fixing this wish.
In GnuPG 2.1 most binaries carry version information and an icon.
We won't port that back to GnuPG 2.0.
6.7 still shows MD5 fingerprints thus switching won't be easy. Does the SHA-256
fingerprint use Base32? If that is the case it might be a serious UX problem
because most people are used to look for colon separated hex digits.
Secure deletion is a hard problem that depends on the operating system and the
file system used and might even depend on the hardware. I'm not sure if the way
mentioned in this wish would result in "Secure deletion".
GnuPG is not the tool for this.
Related issue: #1166.
Now that we have a dirmngr daemon, this should be feasible. I plan to implement
it like this:
Add two flags to the KS_GET command, --enqueue and --drain-queue. --enqueue
merely enqueues the key id and returns immediately, unless --drain-queue is
given.
This will also help us address issue #1827.
I'd be happy to implement this, but it is not clear to me how. Merely base64
encode the default representation? Or the canonical representation?
When this feature becomes available, then we should probably disable
"gtk-entry-password-hint-timeout". See the following Debian bug report for details:
I generalized the ssh key fingerprinting code so that we can select the digest algorithm.
Now I'm a little unsure how to proceed. We can easily include both the MD5 and the SHA256 digest
in the sshcontrol file. But what shall we use for expanding '%F' in key descriptions? If we
transition too soon or too late, users might not recognize their key. Displaying both surely is
too verbose. We could make it configurable, or at least a compile time option.
What do you think?
Err, fixed in 6ac57a48.
Fixed in
Fixed in a8308ba5.
% g10/gpg2 --keyserver hkp://keyring.debian.org --search-keys dkg
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: error searching keyserver: Not implemented
gpg: keyserver search failed: Not implemented
The problem here is that the hkp client code folds all http status codes other
than 200 and 3xx into GPG_ERR_NO_DATA. This is also a problem for issue #1038.
Because a CNAME gives us much more flexibility than using the currently most
favored pool.
The response from the DNS server is fully okay. There can't be any additional
info because the CNAME points to a different zone.
You should have told us the OS and GnuPG version you are using. For example 2.1
uses a very different strategy than older versions.
More difficult then I thought.
For PGP/Inline this should currently work. I had the problem that I can't
manipulate the Body in MAPI but over Outlook in the write event this worked.
PGP/Clearsigned support i've disabled for now.
With regards to mime mails:
I could modify / restore the mail there already using old code. The message
is not formed correctly but this looks like just a bug in the revert code.
As it turns out this was totally an understatement ;-) The old revert code can't
have worked. Maybe for S/MIME under some circumstances but otherwise not.
The problem is the main part how Outlook builds the MIME message. Were we have
very limited control about it. Just removing our attachments and leaving the
original MIME attachment leads to a MIME structure like:
<quote>
This is a multipart message in MIME format.
------=_NextPart_000_0000_01D12C53.76E82C90
Content-Type: multipart/alternative;
boundary="----=_NextPart_001_0001_01D12C53.76E82C90"
------=_NextPart_001_0001_01D12C53.76E82C90
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
------=_NextPart_001_0001_01D12C53.76E82C90
Content-Type: text/html;
protocol="application/pgp-encrypted";
boundary="nextPart3167407.zD7nylcVYN";
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-W3CDTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
rmj.rmm.rup.rpr">
<TITLE></TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<BR>
</BODY>
</HTML>
------=_NextPart_001_0001_01D12C53.76E82C90--
------=_NextPart_000_0000_01D12C53.76E82C90
Content-Type: application/pgp-encrypted;
name="Unbenannte Anlage 00001.dat"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Unbenannte Anlage 00001.dat"
Version: 1
------=_NextPart_000_0000_01D12C53.76E82C90
Content-Type: application/octet-stream;
name="msg.asc"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="msg.asc"
-----BEGIN PGP MESSAGE-----
Version: GnuPG v2
hQEMAx7U8Lxs+8kSAQf/eB4zBTz/VSVBBI+ihh/PSorJ98BRh5earBqF8HjmGZce
<end quote>
This is nothing even an MUA like KMail can handle. And GpgOL can handle this
neither. So if we modify the message we have to do it somehow in a way that
Outlook builds a Mime structure again that users can work with.
As we can actually send MIME messages I looked at the code in mimemaker that
builds a message. Using some tricks from there I was able to recreate a PGP/MIME
mail. But this needs special handling for all our message classes.
Still too buggy to commit. Leaks plaintext and I have at least seen that it led
to a duplicated message once.
Right, or for example to re-encrypt a message to a workmate.
Ready for implementation by Andre.
| So if you want to go ahead with the current plan, that's fine with me. |
Thanks for your feedback.
I was wondering specifically about the use-case when you want to enter
and "ok" the passphrase. The regular flow for this as I understand it would=
be
typing the passphrase and then "enter" or "return"
I think it is okay to have "tab" cycle between options, but including the=20
option of toggling visibility, because somebody who want to enter the=20
passphrase would (in my understand) always do the above flow and not=20
tab-tab-enter.
Modifying the mail in the afterwrite event did not work good. While the
attachment changes were synced to the server Outlook itself didn't reparse the
mail correctly. This let to a weird out of sync situation between MAPI and OOM.
But testing looks like this could work from the Write event indeed. Which would
be even better because we only have one write and we could replace the "Wipe
Message" code completely by just reverting the mail back to the original.
I'm optimistic this can be done. :-)
It's a bit iffy though and might be especially annoying from a performance side
for exchange users. Still it will be better then the Status Quo because you can
still use the mails with other clients.
The trick is not to revert back the message in the Write event, as we have to
work on the OOM in the Write event but in the AfterWrite event where we can work
on MAPI.
I could modify / restore the mail there already using old code. The message is
not formed correctly but this looks like just a bug in the revert code.
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.
(2nd try, the mailinterface failed for me.)
http://www.aelog.org/password-visibility-in-kpassworddialog/
Good that you found it.
In the comments Bogdan has a point.
The screenshots also do not look convincing, but I agree it makes sense to be
consistent there. Could we also get a screenshot about this implementation
for Windows 8 they are talking about?
For GTK we should implement it the way werner has outlined and as has been
discussed on the mailing list. So that users with more "Keyboard centric"
workflow have the GTK alternative available.
As gtk-pinentry
I'd say the discussion on the mailinglist is fully superceded.
In my view we should
a) design it close to pinentry-qt, because it also will be used on Windows
mostly and the consistency with other Windows password dialogs has a lot of weight
b) Look at other wide spread gtk-dialog for this functionality and use
the better design considerin Bogdans comment with a "switch".
The icon could possibly used in both implementations. (If the license allows
this. Oxygen used to have a bit less practical licene coming with it.)
Best,
Bernhar
Bernhard:
I've tried out KDE 5 and noticed that the standard password dialog there already
has such an option. http://www.aelog.org/password-visibility-in-kpassworddialog/
My strong preference for Pinentry-qt would be to make it similar. As a unified
UI adds value and pinentry-qt is afail most often used with Windows and KDE
desktops. And the solution outlined in the link above is also very similar to
the Windows 10 password entry.
For GTK we should implement it the way werner has outlined and as has been
discussed on the mailing list. So that users with more "Keyboard centric"
workflow have the GTK alternative available.
Would this be acceptable for you?
I've tried to improve the web page.
Since Werner needs to check this, I'm changing the status of this issue to
testing and adding him to the cc.
@Reuben: If you have some ideas of additional improvements, I'd be grateful.
Thanks.
To be clear: the limitation is that GnuPG doesn't currently allow selecting the
main key and subkeys at the same time.
In b64b33b, I've added the ability to update multiple subkeys at once. Note: it
is still not possible to update the main key and the subkeys at the same time,
but this should be a significant improvement, I think.
This tool has now been marked as deprecated in the documentation.
I now see I misunderstood the problem description.
The point is that a user has a message that is encrypted to key X. After
receiving the message, he wants to allow another key (say Y) to decrypt the
message by adding a symmetrically encrypted data packet to the message for Y,
i.e., without reencrypting the whole thing.
The reporter wasn't to specify the secret key to use. Werner indicated that
--try-secret-key does what the reporter wants in 2.1, but that this won't be
backported to 2.0. As such, I'm marking this issue as resolved.
I'm going to close this. The right forum to address these issues is the OpenPGP
working group.