Hi Arthur,
sorry for the late reply:

Outlook 2010 has new code for supporting OpenPGP and S/MIME,
we will tackling the problem differently there.
I think that the last code for GPgOL for Outlook 2007 uses
encryption.

If this is still relevant for you: Can you retest?

Hi,

as the extended support period of Outlook 2003 ended in 2014,
we will not get around fixing this for Outlook 2003.

Please open a new issue, if you encounter problems with a more recent version.

Best,
Bernhard

Since the last activity on this report, GpgOL was changed a lot.
Probably the original reporter does not use the Windows/Outlook combination
anymore. Thus closing this report.

On Friday 26 February 2016 at 11:45:07, xyzspeedy via BTS wrote:

We think, there ist a Problem in the Oulook-(Plugin)-Config on the tested
Systems, but i'm not sure,

xyzspeedy wrote to me that the behaviour is reproducable with
Windows 7, 8.1 and 10 (each time pro x64)

Andre,
let us fix this for 2.3.1.

Jens,
thanks for the report. Now I can classify this as GnuPG "modern" issue. :)
Bernhard

MDK7MX, did you retry ?

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.