Hi Jens,
which version of gpg2 on which platform did you try this?

Which version of gnupg2 do you refer to? (On which platform?)
AFAIK 2.0.29 gpg2 does not have a --faked-system-time option.

More detail to the longer description:

Before on the machine kleo was running.
I've started the upgrade, now I get the hint that I should make
sure that all applications are closed, especially Outlook ...
So I close Kleo and continue.
After a while the problem with libksba comes up.

Some more infos:

https://www.openkeychain.org/faq/#importing-your-own-key-from-gnupg-fails
says that this is a problem for a number of people.

Werner told me that porting the fix back would mean to basically
migrate 2.0 to 2.1, which is useless because 2.1 is already 2.1.

Another possibility would be to change --export to mix public keys (certs)
with secret keys. This would create other problems and thus is not
adviable for a stable version.

So I think this is "won't fix" because it (technically) does not make
sense to fix in 1.4 or 2.0. Solutions: Use 2.1 or wait for 2.2.
As importing implementation: Be tolerant for this problem man use the cert
information if you can.

Ready for implementation by Andre.

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.

(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

1. currently does not allow tab-return
2. and it does not make sense as a workflow
3. 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

@dkg,
what do you think about T2139 (bernhard on Nov 02 2015, 10:09 AM / Roundup)?

Chris,
your arguments have been discussed before.
The transportation with OpenPGP and Authenticode signatures
is considered to be save enough.
And you can bring them up again in a public discussion forum,
not in a contributors todo list. Or you can use a platform of your chosen,
e.g. a personal blog.

Your last msg's wording is also against our rules as a community to
work together in a respectful and manner. You repeately imply
personal deficies by others like me or Werner you are not convinced
by your arguments. For the sake of our community, we cannot tolerate
that. Thus I'll have to see this specific acount to be removed, so we
can close this issue.

I hope to see respectful contributions from you in the future,
Bernhard

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

Chris,
as we want to keep this community functional, we require a basic politeness
and respect for the provided tools like this tracker.

As you keep insisting on an argument that Werner and myself
cannot follow and you do not respect that this tracker is the
todo list of the active contribution, we have to protect
our contribution community for repeated obstruction of our goals.
I will see if I can get this tracker issue closed.

Feel free to bring matters like this up on the public mailing list or
your own other channels.

Best,
Bernhard

Dear Chris <coward@anon.im>,

this is the todo list of active contributors
and to be useful to them, they get to decide what is tracked.

My argument that there are some people that are in situations
where they cannot get a TLS connection (behind a firewall or not having
the right software), they still get the same, integrity protected distribution.
All other can use TLS, if they want to. So it is more people overall
that have access.

Convince a few other active contributors of GnuPG or Ggp4win that
you are still having a valid point for the todo list. If so, open a new
issue. Reopening this one is not helpful.

Best,
Bernhard

We will keep the non-TLS access, because there are some people
that will lose access otherwise. This would be security loss in availability.

I appreciate that you checking what we do and that you want to help the initiative.
In order that many people can do so in a constructive way
the tracker is here to support the active contributors,
which will have the final say what they are going to see as a todo item or not.
We'll probably change some of the web pages and will move some more services
over time, but there is not much point in tracking it here.
Please respect this decision.

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.