When this feature becomes available, then we should probably disable
"gtk-entry-password-hint-timeout". See the following Debian bug report for details:
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Dec 7 2015
Dec 7 2015
Dec 4 2015
Dec 4 2015
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
justus added a comment to T1221: gpg misinterprets under-implemented keyservers as empty, misreports search results to users.
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
Dec 3 2015
Dec 3 2015
justus added a comment to T1221: gpg misinterprets under-implemented keyservers as empty, misreports search results to users.
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.
• werner added a comment to T2164: Use pool.sks-keyservers.net directly as default in dirmngr.conf-skel (instead of the CNAME).
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.
Dec 1 2015
Dec 1 2015
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.
bernhard reassigned T2139: pinentry option to see the password in cleartext from bernhard to • aheinecke.
| 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.
Nov 30 2015
Nov 30 2015
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.
• werner removed a project from T2165: dirmngr doc references missing keyserver-options documention: Bug Report.
Nov 27 2015
Nov 27 2015
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:
- textentry
- Cancel
- OK
for pinentry-qt (same version as tested above) the tab ordering is:
- textentry
- OK
- Cancel
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
- currently does not allow tab-return
- and it does not make sense as a workflow
- we are lacking further evidence if there are users that still use this for a password entry. (Not response by dkg.)
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
• aheinecke added projects to T2163: Make it possible to restore MIME crypto mails to original: Windows, Windows 32, Feature Request, gpgol.
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?
Nov 24 2015
Nov 24 2015
neal removed a project from T1648: Missing step in instructions for verifying integrity: In Progress.
neal added a project to T1648: Missing step in instructions for verifying integrity: Restricted Project.
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.
Nov 23 2015
Nov 23 2015
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.
Nov 20 2015
Nov 20 2015
Nov 18 2015
Nov 18 2015
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.
bernhard added a project to T1858: Wish for additional TLS access to GnuPG and Gpg4win binaries: Feature Request.
Nov 17 2015
Nov 17 2015
cd2d685 fixes the assert. I don't see the utility of checking keyid (gpg will
do that). Closing.
neal raised the priority of T1481: Output format option for Textmode conversion from Wishlist to Normal.
Based on Werner's comment, I'm changing this to nobug and marking the issue as
resolved.
(At least) 2.1.9 should support version 3 (see dirmngr/ks-engine-ldap.c:492).
If this is still not working, please reopen this bug. Thanks.
I've fixed this with commit 0b86c74 by making it possible to select keys using
the key id. Consider:
gpg> key 4BFA08E4
pub rsa4096/D21739E9
created: 2007-06-02 expires: 2016-01-21 usage: SC validity: unknown
sub rsa4096/21484CFF
created: 2007-06-02 expired: 2015-02-26 usage: E
sub* rsa2048/4BFA08E4
created: 2008-06-19 expires: 2016-01-21 usage: A
sub rsa4096/1BFDFA5C
created: 2013-03-12 expires: 2016-01-21 usage: S
sub rsa2432/0CA757FB
created: 2013-09-11 expires: 2016-09-14 usage:
sub ed25519/BD7CFAB5
created: 2014-11-07 expired: 2015-05-06 usage: A
sub rsa4096/14D5DA70
created: 2015-01-21 expires: 2016-01-21 usage: E
sub ed25519/BD7CFAB5
created: 2014-11-07 expired: 2015-05-06 usage: A
sub ed25519/BD7CFAB5
created: 2014-11-07 expired: 2015-05-06 usage: A
sub ed25519/BD7CFAB5
created: 2014-11-07 expired: 2015-05-06 usage: A
sub ed25519/BD7CFAB5
created: 2014-11-07 expired: 2015-05-06 usage: A
[ unknown] (1). Daniel Kahn Gillmor <dkg@fifthhorseman.net>
[ unknown] (2) Daniel Kahn Gillmor <dkg@openflows.com>
[ revoked] (3) Daniel Kahn Gillmor <dkg@astro.columbia.edu>
[ revoked] (4) Daniel Kahn Gillmor <dkg-debian.org@fifthhorseman.net>
[ unknown] (5) [jpeg image of size 3515]
[ unknown] (6) Daniel Kahn Gillmor <dkg@debian.org>
[ unknown] (7) Daniel Kahn Gillmor <dkg@aclu.org>
cnd raised the priority of T1858: Wish for additional TLS access to GnuPG and Gpg4win binaries from Wishlist to High.
Bernhard - this is an issue of security, it is not a place for you to
exercise corruption by using your influence over administrators to shut down
opinions you disagree with.
You have made a statement that I am absolutely confident that no security
professional will support: "We will keep the non-TLS access, because there
are some people that will lose access otherwise.". Aside form this
statement being almost certainly totally untrue, this is nevertheless NOT a
valid reason to continue to distribute a security product over known
compromiseable channels. If anyone cannot get GPG because of TLS (which I
doubt), that is NOT a reason to for everyone to get GPG over an insecure
channel. Like I've said before, security-downgrade attacks are the most
effective weapon used by adversaries. Do not make is so easy for them.
Let me suggest a resolution to this problem, since we seem to be at a
stalemate:
Let us pick a security professional who is known and trusted. You can write
down your case for why you do not want to use TLS, and I will write down my
case why I want TLS to be mandatory, and we will each give our cases to this
professional.
If they pick your case, I will let you close this ticket and I will not come
back.
If they pick my case, you will resign from the GnuPG project and not come
back.
Deal?
Nov 13 2015
Nov 13 2015
Chris,
the admins tell me that it is easiest to remove your user account
to withdraw updating rights to this issue. This I may be forced to do,
unless we find a better solution for civility and availability of this tracker.
Regards,
Bernhard
bernhard added a project to T1858: Wish for additional TLS access to GnuPG and Gpg4win binaries: Feature Request.
This is still open: http://files.gpg4win.org/gpg4win-2.2.6.exe
So this stays open: T1858
cnd added a project to T1858: Wish for additional TLS access to GnuPG and Gpg4win binaries: Bug Report.
cnd raised the priority of T1858: Wish for additional TLS access to GnuPG and Gpg4win binaries from Wishlist to Unbreak Now!.
Oops. I used a plain old keyring and not a keybox. However the effect is the same.
This would add a lot of complexity because some users will soon request
configurable colors and attributes as well as different output formatting.
I suggest to write a wrapper to do this or resort to one of the GUI tools.
• werner lowered the priority of T1858: Wish for additional TLS access to GnuPG and Gpg4win binaries from Unbreak Now! to Wishlist.
• werner added a project to T1858: Wish for additional TLS access to GnuPG and Gpg4win binaries: Feature Request.
Mate - it's this simple. For as long as you're distributing a security
product over plaintext insecure channels, this bug needs to stay open.
TLS will NOT prevent anyone downloading this, no matter how hard you cling
to that irrational idea. If you work for someone who is exploiting this
attack vector SHAME ON YOU!!!
Stop wasting everyones time. If you don't want to fix this, go away and do
something else, stop preventing someone who *can* fix it from actually doing
that by messing with this ticket.
cnd raised the priority of T1858: Wish for additional TLS access to GnuPG and Gpg4win binaries from Wishlist to Unbreak Now!.
cnd added projects to T1858: Wish for additional TLS access to GnuPG and Gpg4win binaries: Info Needed, Bug Report.
bernhard lowered the priority of T1858: Wish for additional TLS access to GnuPG and Gpg4win binaries from Unbreak Now! to Wishlist.
bernhard added a project to T1858: Wish for additional TLS access to GnuPG and Gpg4win binaries: Feature Request.
Nov 12 2015
Nov 12 2015
• werner changed Version from 1.4.10 to master on T1173: gpg has no easy way to view the reason and description of revocation sigs.
• werner added a comment to T1173: gpg has no easy way to view the reason and description of revocation sigs.
That should go into the keylisting. Here is a listing of a revoked
key:
pub dsa1024/269E78D84738350A 1999-08-16 [revoked: 2011-02-15]
Key fingerprint = 72A2 A242 8623 84A9 5910 C454 269E 78D8 4738 350A
Keygrip = 2BBB5EF3D036022DD66EF4386680C194352A2EC2
uid [ revoked] Florian Lohoff <flo@[...]>
uid [ revoked] Florian Lohoff <flo@[...]>
uid [ revoked] Florian Lohoff <flor[...]>Another line after the Keygrip line could show key revocation
information. To show user id revocations a list option is anyway
required:
$ gpg --list-options show-unusable-uids \
--with-fingerprint --with-keygrip -k 6C7EE1B8621CC013
pub dsa1024/6C7EE1B8621CC013 1998-07-07 [expired: 2004-12-31]
Key fingerprint = ECAF 7590 EB34 43B5 C7CF 3ACB 6C7E E1B8 621C C013
Keygrip = E3003A38C3CCB63DFB39998A6C8A78EB9498E42A
uid [ expired] Werner Koch <wk@gnupg.org>
uid [ expired] Werner Koch <werner.koch@guug.de>
uid [ expired] Werner Koch <wk@[...].com>
uid [ revoked] Werner Koch <wk@openit.de>A similar formatted revocation reason could be shown after the revoked
user id. It would be best to indent that to align with the [revoked]
string.
And of course we also need to come up with a --with-colon format for
both cases.
Iff we do this it should only go into 2.1 thus I changed the Version field.
• werner changed Version from 1.4.10 to master on T1128: gpg should detect ambigious keys specifications.
My problem was a different one. Here is what I wrote to gnupg-devel:
$ ../g10/gpg2 -vsbau 0xE3FDFF218E45B72B </etc/motd >/dev/null [...] gpg: Error: the key specification '0xE3FDFF218E45B72B' is ambiguous. gpg: (check argument of option '--local-user') gpg: error reading key block for '0xE3FDFF218E45B72B': Unknown system error. gpg: Error: the key specification '1E42B367' is ambiguous. gpg: (check argument of option '--encrypt-to') gpg: error reading key block for '1E42B367': Unknown system error. gpg: Warning: value '1E42B367' for --default-key should be a long keyid or a
fingerprint.
gpg: Error: the key specification '1E42B367' is ambiguous. gpg: (check argument of option '--default-key') gpg: error reading key block for '1E42B367': Unknown system error. gpg: writing to stdout gpg: EDDSA/SHA256 signature from: "E3FDFF218E45B72B Werner Koch (wheatstone
commit signing)"
wk@wheatstone:~/b/gnupg/tmp$ echo $? 2
Note that I have only specified a short key id because this is pretty
common and gpg prints only a warning. Okay.
The real problem is that there are several error messages - one is
sufficient to let gpg exit with a failure and git won't continue. There
are 2 different kinds of errors:
gpg: Error: the key specification '0xE3FDFF218E45B72B' is ambiguous.
This is the keyid I specified on the command line. Let's check it:
$ ../g10/gpg2 -k 0xE3FDFF218E45B72B [...] gpg: Error: the key specification '1E42B367' is ambiguous. gpg: (check argument of option '--encrypt-to') gpg: error reading key block for '1E42B367': Unknown system error. gpg: Warning: value '1E42B367' for --default-key should be a long keyid or a
fingerprint.
gpg: Error: the key specification '1E42B367' is ambiguous. gpg: (check argument of option '--default-key') gpg: error reading key block for '1E42B367': Unknown system error. gpg: please do a --check-trustdb pub ed25519/E3FDFF218E45B72B 2015-02-18 [expires: 2025-02-15] uid [ultimate] Werner Koch (wheatstone commit signing)
(and -k shows the same result).
What is the ambiguity here?
The other two error messages are identical one for --encrypt-to and one
for --default-key:
gpg: Error: the key specification '1E42B367' is ambiguous.
Let's check it:
$ ../g10/gpg2 -k 1E42B367 [...] gpg: Error: the key specification '1E42B367' is ambiguous. gpg: (check argument of option '--encrypt-to') gpg: error reading key block for '1E42B367': Unknown system error. gpg: Warning: value '1E42B367' for --default-key should be a long keyid or a
fingerprint.
gpg: Error: the key specification '1E42B367' is ambiguous. gpg: (check argument of option '--default-key') gpg: error reading key block for '1E42B367': Unknown system error. gpg: please do a --check-trustdb pub dsa2048/F2AD85AC1E42B367 2007-12-31 [expires: 2018-12-31] uid [ unknown] Werner Koch <wk@gnupg.org> uid [ unknown] Werner Koch <wk@g10code.com> uid [ unknown] Werner Koch <werner@eifzilla.de> sub dsa1024/4F0540D577F95F95 2011-11-02 sub rsa2048/1E0FE11D664D7444 2014-01-02 [expires: 2016-12-31]
Also not ambiguous.
So this new feature break existing installations. This is a complaint
as mentioned in T1128 (wk on Nov 06 2015, 10:57 AM / Roundup). Not due to performance but due to severe
breakage. This needs a lot more testing before we can release it.
Nov 11 2015
Nov 11 2015
I've fixed the problem that Niibe reported in 7546e81.
(commit e8c53fc was for master)
This introduces a regression. I had to revert this commit to be able to keep on
using gpg in my configuration. A description of the problem can be found at:
https://lists.gnupg.org/pipermail/gnupg-devel/2015-November/030549.html
Nov 9 2015
Nov 9 2015
Nov 6 2015
Nov 6 2015
neal added a project to T1444: Check keyid after downloading key from keyserver and before importing it: gnupg.
In 2.1, these options are supported. They are not support in 1.4, but they are
in 1.4's manual.
At most, this is a performance bug. However, applygnupgdefaults isn't
performance critical. There is no reason to apply this so I'm dropping it.
https://www.gnupg.org/documentation/manpage.en.html is way out of date. Is
there a way to automatically generate this page (it needs to be converted to the
.org format).
neal added a comment to T1221: gpg misinterprets under-implemented keyservers as empty, misreports search results to users.
This seems to still be a problem:
$ gpg2 --keyserver hkp://keyring.debian.org --search-keys dkg
gpg: error searching keyserver: No data
gpg: keyserver search failed: No data
neal removed a project from T1327: gnupg-2.0.17 test failures on GNU/Linux IA-64 (Red Hat 5.6): Info Needed.
This bug report is very old and 2.0.17 is no longer supported. The right way
forward is to rerun the test suite with the latest version on a modern OS.
However, I expect that if these failures were still a problem, we'd have heard
about them. As such, I'm closing this bug.
Added the option --only-sign-text-ids in 28e1982