https://files.gpg4win.org/

I disagree, MitM cannot fake the origin so there is no gain in integrity
by using TLS. And if MitM can substitute traffic, it can also block TLS traffic
so there is also no again in availability.

Let me quote from T1858 (cnd on Nov 12 2015, 10:21 AM / Roundup):

So there is https://files.gpg4win.org/gpg4win-2.2.6.exe

Gpg4win installers have been code-signed with Authenticode for years and thus are
as securely authenticable as you trust the Microsoft code signing certificate chain
. (If the Microsoft code-signing certificate chaing is broken, your system is wide
open as it secures a lot.)

Gpg4win and GnuPG binaries are signed and additional available over TLS channels
(which provides less integrity protection.)

Hi!

@dkg:
Can you tell me more about your tab-return use case? Do you have hints/personal
observations about how many people are affected?
In the gtk2 pinentry this did not work so far (See my T2139 (bernhard on Oct 29 2015, 04:42 PM / Roundup)) other
implementation do not seem to allow it (I've also tested kdm login screen)
and it does not make much sense either when you can press "return" right away.
So to me it is still unclear how many people are affected.

@aheinecke: Thanks for contributing another case.
I think it is a good solution for a system login screen, where a login-change
probably is harder to do.
I think this slightly changes when you think about passphrases for pinentry
that may get entered less often and some people keep a backup on paper (which is
actually good under some circumstances) and I would claim that a passphrase
change on a key on average is easier to do than a system password.

@werner: You wrote that you've checked some other implementation, it would be cool
to have a list of those. Screenshots would be even better.

@all, my current design ideas are

• to have a text below the entry field, close to it, saying "show password" and a on-off switch or second best a check-box, third best a button.

Rationale: Because the space requirement is mainly in width. An on-off switch

probably has the most natural mapping, but this depend on the overal GUI design
of the system. On some a real slider-switch may not be available or look alien,
then we should use what ever users will recognise as an on-off thing.
The text is much less work than to select/design an icon and it uses
less height.

• It is okay to have that in the accessibility tab list, even after the entry field, because I personally believe that a lot more people want the natural order when using tab at all. Right now the data for how many people actually have the tab-enter habit is unknown, maybe Daniel can help us out here.

@dkg: I have been thinking about your use case:

I wonder about what fraction of people we are speaking of.
In many applications, just like pinentry, you can just hit "enter" right away
so there is no need to first hit "tab". First hitting "tab" does not make sense
for these kind of dialoges.

Then in some implementation like pinentry-gtk2 0.8.3-2,
this does not work right now, because the next tab is "cancel" which users then
would reach. So it depends on the standard for dialog windows where the
ok and cancel buttons are. Was there any problem report on pinentry-gtk-2?
I am not sure if any pinentry-gtk-2 user actually had this problem?

@werner
Running with --no-sig-cache took 30 Minutes.
gpg2 --delete-key 52D717F3
time LANG=C gpg2 -v --no-sig-cache --recv-keys 52D717F3
real 29m38.897s

While time LANG=C gpg2 -v --recv-keys 52D717F3 took 2 minutes.
Debian gnupg2 Version: 2.0.26-6 i386.

@neal:
Thanks for working on this, if you think it may may sense to test this
with real data, can you point to the steps required to do this?
(I guess building gpg-2.1-from your git branch, ...)

@All,
any idea what the change between 2.0.25-99intevation2 on Wheezy
and 2.0.26-6 on Jessie could be that would cause this problem?
(Or is it just a few small certs or trust settings more that will cause
this one magnitude higher load)

Daniel:
Thanks for your comment and adding the use case. I saw your suggestions
on the list like changing the tab order.

More specifically: Would it be fine with you to implement this without
a warning dialog that requires another click or attention?

My suggestion is also, to seek for an icon that is more self-explanatory.
Actually I would like the "gtk_switch" gui component, though Werner is right
that it takes up a bit more of space.

On Tuesday 04 August 2015 at 11:07:46, Andre Heinecke via BTS wrote:

f941252 It now makes it clear that you have to edit
gpg.conf.

I'll second this report, note that I noticed this change in behaviour
when migrating from Wheezy to Jessie and from gnupg2
2.0.25-99intevation2 to 2.0.26-6

More details copied from gnupg-devel@:
----------Original Message----------
From: Bernhard Reiter <bernhard@intevation.de>
Sent: Tuesday 23 June 2015, 16:21:54
To: gnupg-devel@gnupg.org
Subject: trustdb calculation very slow (gpg2.0 vs gpg1)

Hi
on a Debian GNU/Linux Jessie system I have a defect that
the trust calculation of a cert is taking a lot of time.
Almost 2 minutes with 100%cpu.
This used to be different with early gnupg2 versions I've used
and it is different to gpg (1), where it were 20 seconds.

No report found, thus seem to depend on my trustdb.
Any ideas on how to create a good report/debug?

Details:
How to recreate:
gpg2 --delete-key 52D717F3
time LANG=C gpg2 -v --recv-keys 52D717F3
real 1m57.144s
user 1m46.560s
sys 0m9.296s

as compared to gpg verison 1

gpg2 --delete-key 52D717F3
time LANG=C gpg --recv-keys 52D717F3
real 0m19.840s
user 0m18.192s
sys 0m0.900s

ii gnupg 1.4.18-7 i386 GNU privacy guard - a free PGP re
ii gnupg2 2.0.26-6 i386 GNU privacy guard - a free PGP re

With 2.0.25-99intevation2 on Wheezy I did not notice the issue,
but of course, my trustdb changed over time.

----------Original Message----------
From: "Dr. Peter Voigt" <pvoigt@uos.de>
Sent: Tuesday 23 June 2015, 23:35:14
To: gnupg-devel@gnupg.org
[..]

I am just having a fully configured VirtualBox VM of Jessie with Gnome
3 available, but I am not having this problem:

% time LANG=C gpg2 -v --recv-keys 52D717F3
...
LANG=C gpg2 -v --recv-keys 52D717F3 0.11s user 0.06s system 7% cpu
2.304 total

% dpkg -l gnupg2
Desired=Unknown/Install/Remove/Purge/Hold

Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

Name Version Architecture
Description

+++-

ii gnupg2 2.0.26-6 amd64 GNU
privacy guard - a free PGP replacement (new v2.x)

---------Original Message----------
From: Bernhard Reiter <bernhard@intevation.de>
Sent: Wednesday 24 June 2015, 09:17:35
To: gnupg-devel@gnupg.org

On Tuesday 23 June 2015 at 23:35:14, Dr. Peter Voigt wrote:

I am just having a fully configured VirtualBox VM of Jessie with Gnome
3 available, but I am not having this problem:

thanks for trying to reproduce!
As your result is showing as well:
It probably depends on my .gnupg data like the contents of my trustdb,
private keys and settings.

Of course I cannot just make this available,
so I am grateful for hints to find out more about the issue.

I could try to export, delete and reimport the trustdb, but because
gpg 1.4 works on it a lot better I assume that it is not a simple structural
problem of my trustdb. (Which I hope both gpg versions would detect.) So I am
not sure, if this is a good step to take.

----------Original Message----------
From: Pedro Coelho <pedro.msac@gmail.com>
Sent: Friday 19 June 2015, 14:55:41
To: gnupg-devel@gnupg.org
Subject: Issue 1998 Extended and Composed Characters on password.

Hi ,

Sorry to come up again with the same issue.
I posted some weeks ago an issue about gpg that I have detected while
working with gpg on Multiple/Cross systems.

This was passed to the bug tracking system as T1998.
I do not seem to be able to reply/follow-up on the bugtrack system so I
hope to contribute in here for the same issue.

I have tested to encrypt a file with a password that as several types of
characters, ascii, extended and composed.

As stated in the previous email listed below:

T1998

I was able to narrow down the problem to Composed Characters on the
password.

That is if one uses extended characters like the ones resulting from using
<altgr> or <altgr>+<shift> and try to decrypt the file on a different
OS/Computer, obviously the same keyboard layout must be present.
If the characters showing up on the CLI are the same as the ones used on
the password ... no problem for gpg to work correctly.

I made some tests passing the same file to Multiple Distros installed and
reached the conclusion that extended character support is not always
reliable to say the least ... but it can work.
For instance on Centos7 minimal with the exact same keyboard layout the
characters shown on display are not the same as in my default OpenSuSE 13.2
or Ubuntu. But once they are found gpg can decrypt the file.
That is an issue not of gpg but rather of the available mappings an Locales
on those particular systems. One as to simply be advised for those issues
in case of using gpg in multiple environments.

But problems do not stop there.
I have narrow down the problem of the decrypt bad key error to the Composed
Character.
If one uses composed characters problems keep showing up.

I used on the Same PC two sessions: One normal OpenSuSE KDE environment,
the other LXDE environment.
I noticed that on the LXDE session when using extended altgr/altgr+shift
chars I was able to decrypt my file.
The problem came about when dealing with Composed characters ... those
where a Symbol and a regular Character are composed.
Those who write in English most likelly never used such characters ... like
ã or õ. (don't even know if they even display correctly on your email
reader ... )

Those are a problem since in different systems Even with the same Locale
keyboard layout and Locale the use of a single composed chars can be
"misinterpreted".
On pinentry I've also seen for example when trying to enter a composed
character the box showed a double entry ...two chars (asteriscs) instead of
one ...

So this may indeed be a OS/Locale problem rather then a gpg problem ...

On Monday 08 June 2015 at 12:50:23, Werner Koch via BTS wrote:

Workaround: --allow-weak-digest-algos

Except the for doubled listing, is there any other potential drawback?

It probably would have been better to create two issues:
a) Dataloss with Kleo in 2.2.2 (fixed now)
b) crash with gpa

Jonny, can you confirm that the problem is gone with 2.2.3?

Probably needs a retest with gpa 0.9.5

Hi thanks for the report and for trying gpa!

Could you try Gpg4win 2.2.2 (or the version 2.2.3 if it is release).
Thanks!

What is the best way to switch the console to utf mode?
Should someone use the chcp command and how?

Anyway the default behaviour is surprising for users, so from my point of view,
it should be improved somehow. A good documentation how to switch would only
be a second grade solution. A better one would be if the .exes would switch the
code page themselfs, I assume.

For diagnostic reasons: could you try with Kleopatra as well?

Thanks for asking again, I did not remember that GPGex was missing from the
compendium.

It works similiar to GpgOL, see
http://git.gnupg.org/cgi-
bin/gitweb.cgi?p=gpgex.git;a=blob_plain;f=README;hb=HEAD
and in German:
http://lists.wald.intevation.org/pipermail/gpg4win-users-de/2013-
August/000593.html

Hi Henning,
thanks for your feedback on Gpg4win and of trying the new Gpgex.

Can you help us further by trying to get some more diagnostic output?
See the link in the last section of http://gpg4win.org/reporting-bugs.html

Best,
Bernhard

For completeness, this fix has been published as part of the regular Gpg4win
releases since 2.1.1-beta1. It is also included in 2.1.1. There is no need to
download the dll directly, just move to the recent Gpg4win version.

I strongly suggest to have an official recommendation how to solve this issue.
The currently available information does not help packagers and application
developers enought to get it right. Probable most distributions should prevent
gpg1 and gpg2 to be installed with their dependency handling.

I agree with Ralf that we need a solution for this.
I can be a multi-step solution.

But right now, most GNU distributions are not putting much effort in
the GnuPG installation and setup help. For example: With Debian squeeze
you cannot deinstall gpg1 because the dependencies would drag down other
software. Yes, this is partly a packaging problem with should be solved on
Debian's side (as well), but if we want GnuPG to be successful we need to offer
users and packagers best practice and clear recommendations.

My suggestions:
a) Make the suggestions more clear that gpg2 only should be recommened only in
almost all installations
b) offer some safety nets if there are both installed and gpgconf is used.

I agree that adding a better message is helpful.
What about something along the lines that says:

"cannot sign with or decrypt with key XYZ"

and explaining:

  "even when trying to decrypt with a different key, 
  the default signature key gets checked."

Certainly it would be much better if decryption would just try to
decrypt with the available keys, no matter of what status the
certificates to this or other keys are. I am worrying most about the
applications that are using Gnupg in this way, they probably will
not be able to either explain this properlto user or offer good
assistance. The reason you give why this is done is only an implementation
artifact and not logical for a user that has learned or tries to learn
about public key cryptography.

Without a real example file, I don't think that the problem can be
reproduced. Thus I'm closing this issue because of the lack of activity
for more than 12 months.

Matter: Thanks for the report! As Werner suggested: Please ask on the
mailinglist if you continue to have problems, until we can somehow produce a
test case and then somebody is able to file a new report.

Thanks for the answer.
What is the solution right now?
Not use libgcrypt 1.5.0 with GnuPG <= 2.0.17?
Or patch GnuPG?

Tested System was Debian Lenny, XEN Instance.
Used command was

gpg2 -b testfile.txt

Dirmngr 2.1.0-gitde7cfc0 also stays active.

Testing the fix:

Werner, where is the patch for dirmngr 1.1.0?
http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/?root=Dirmngr only goes up to rev346,
while you say rev347 has the fix. Maybe a missing sync on the svn repositories
on your part?

Haven't had a chance to test it, I was somehow waiting for a new release.
Just made sure I get a 1.1.0 patched package to test next.

Testing pinentry-qt Version: 0.8.0.svn234-0kk1 (the changelog indicates
that the change is in) on Debian Lenny with KWin from KDE 3.

It is okay for one request to take a long time or possibly even to block.
But it is not okay, if other, simultaniously made requests are blocked to wait
for this slow request. Especially if those parallel requests could be answered
easily and quickly, like ping.

To me this, issue makes dirmngr unsuitable as a system service
and it currently allows denail of service attacks on gpgsm based email
applications.

Hmm thinking about this, it is almost like a denail of service attack, because
dirmngr will block other clients.

Should probably beretested with Gnupg 2.1(beta or later)
because agent startup might have changed.

• Weitergeleitete Nachricht ----------

Datum: Montag, 26. Juli 2010
Von: Sebastien Lumineau <sebastien.lumineau@ac-grenoble.fr>
An: "g10 Code's BTS" <gnupg@bugs.g10code.com>

I believe we have two seperate issues
here, though of course they might be caused by the same defect.

There is also an T1251 (GPGOL creates broken attachments in Outlook 2007)
about creating encrypted messages. I believe we have two seperate issues
here, though of course they might be caused by the same defect.

Resolved after adding info to T1110.

Am Freitag, 23. Juli 2010 23:59:41 schrieb Sebastien Lumineau via BTS
issue1257:

I confirm that critical issue in Win7. Here is my config:

Windows 7
Outlook 2007 + MO SP2 (do not work without SP2 ether)
Gpg4win 2.0.3
GnuPG 2.0.14
GpgOL 1.1.1
GPA 0.9.0

Message body is decrypted correctly while there's no way to handle
attachment: try "view, open, save as" crashes outlook.

Duplicate of T1110