I am resolving this issue as duplicate of T2324
in the case of intented empty passphrase for the exported key.
(the export-reset-subkey-passwd flag should be taken to an entirely different
issue.)

Both 2.1.11 and 2.1.12 are not in the index, so the update
was missed during the release process.
Werner, you probably know best where to place it in the release process,
so that it is not forgotten. An alternative would be to use a directory listing
module of the webserver which does this more dynamically (and caches the result).

Let us use T2305 for the index update.

Hi, I consider it a regular defect if unexplained, because the API somehow changed.

I ran into it while testing python3-gpgme on Debian Jessie.
Two testcases fail because of the changed gpgme behaviour to count more processed
"keys" than before.

pygpgme-0.3$ python3 -m unittest tests.test_import

F..F..

FAIL: test_import_concat (tests.test_import.ImportTestCase)

Traceback (most recent call last):

File "/home/bernhard/werkbank/2auto/pygpgme-0.3/tests/test_import.py", line 105, in

test_import_concat

self.assertEqual(result.considered, 3)

AssertionError: 5 != 3

FAIL: test_import_secret_file (tests.test_import.ImportTestCase)

Traceback (most recent call last):

File "/home/bernhard/werkbank/2auto/pygpgme-0.3/tests/test_import.py", line 58, in

test_import_secret_file

self.assertEqual(result.considered, 1)

AssertionError: 3 != 1

How to see the difference without pygpgme installed in Jessie with
Package: libgpgme11
Version: 1.6.0-99intevation1

Package: gnupg2
Version: 2.1.11-99intevation2

pygpgme-0.3/tests/keys$ LANG=C GNUPGHOME=~/tmp/dot.gnupg3 gpg2 --with-colons --import
key1.pub key1.sec key2.pub
gpg: Total number processed: 5

The same on wheezy:
Package: libgpgme11
Version: 1.3.1-0kk3

Package: gnupg2
Version: 2.0.25-99intevation2
ygpgme-0.3/tests/keys$ LANG=C GNUPGHOME=~/tmp/dot.gnupg gpg2 --with-colons --import
key1.pub key1.sec key2.pub

gpg: Total number processed: 3

Andre, we probably should also list the old certificate, because we still have
files out there with it.

Like, until 2.3.0 the codesigning certificate was: ..

For completeness, this are the pages:
https://www.gpg4win.de/package-integrity-de.html
https://www.gpg4win.de/package-integrity.html

GnstheGrain,

hmmm. :/

Thanks for the report.

Am Donnerstag, 14. April 2016 16:24:59 schrieb Andre Heinecke via BTS:

But from the discussion here and back then I took that draft to be no
longer up to date and that the MessageBox Question approach with small icon
buttons is not wanted.

Hi Justus,
my report describing the problem, not proposing a solution.
(I think that most report should describe the issue,
so that good solution ideas can be measursed against how could they
solve this and other problems.)

If there is no technical reason to have --faked-system-time
in 2.0.x, I guess that fixing the documentation is the easier solution.

Thanks for testing 2.1 and for reporting the results.
Good to know that it works now.

On Sunday 06 March 2016 at 15:18:54, Neal Walfield via BTS wrote:

is for --check-trustdb

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.