Note that we could switch the wiki.gnupg.org back to local authentification
(or any other authentification that moinmo.in provides, see https://moinmo.in/AuthMarket)
and continue using it.

Yes, it is probably correct: the concept mockup was done a lot earlier. Whatever we have in master is most likely the current status.

Some details of these tasks are outline in the internal concept, including mockups.

Hi,
on which platform? (You can probably compare it to a working version and see which libraries is uses there.)

I can confirm that I can login again.

@justus: Thanks for the quick fix!

Werner: Will you provide a new authentication methods for people participating
in the GnuPG communit?

What should we do until then?
The wiki is potentially interesting each day. It is probably easiest for the
users if you restore the old behaviour until a new authentication method for the
GnuPG-Community is available. Otherwise users must change their credentials two
times (First to the separate wiki authentication now and then to the new one
once it is available.)

What is the estimated roadmap for replacing roundup?

Jochen, is T2448 (aheinecke on Sep 05 2016, 02:14 PM / Roundup) something you could do?

@werner, if I understand the description at
https://www.gnu.org/software/tar/manual/html_section/tar_68.html
then ustar would also be able to read "posix" archives.

Can you create a new issue with the data "loss" part?

As for the default format:
I think we should use and propose a default format that is mostly compatible
over platforms (and robust in the future). tar "posix" seems to be
such a format. Am not sure how this evaluates for karchive or 7zip.

I'm unsure about the compatibility issues with using a higher filename-length
limit.

Spoke to Werner, it is better to do ntbtls anyway.
Timeline is: this year, hopefully earlier.

For ntbtls also see: https://wiki.gnupg.org/NTBTLS

ntbtls is a development from Werner:
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=ntbtls.git;a=summary

What about using https://tls.mbed.org/? At least until ntbtls is mature?

@werner, if you prefer ntbtls over gnutls, okay. Can you add a link to ntblts
and outline the next steps. We'd probably need tls support for the web key
directory as well, so this needs a solution.

Jochen, can you please find out:
a) Does this still work on GNU/Linux?
b) Did this work with elder Gpg4win version? With binary search you

should find out qickley when this broke.

Okay, if this transfers line endings because of the textmode read, it will
depend on the contents of the CRL in question. This explains why the defect was
not seen in earlier testing.

And pem does not work for this (I guess and tried on a GNU system).
It is okay that pem does not work, because this is a rarely used function I think.

Hi,
the 2.1.13 announcement has
"""

• gpg: Allow export of non-passphrase protected secret keys.

"""
(from https://lists.gnupg.org/pipermail/gnupg-announce/2016q2/000390.html)
so this defect may be fixed with 2.1.13 I guess, cool!
Probably only need a test to confirm?

Hi,
without having checked it, I think that dirmngr should try ldapv3 first.
The 2.1 versions for sure. For the others, a fallback should be good enough.
(Would it help if I go digging into specs somewhat to back that up?)

@aheincke an myself observed different behaviour on two ldap server versions
(openldap).
Our new openldap server fails for old dirmngr 1.1.0 Version: 1.1.0+r347-0kk2
and 2.1.11 and master.

Internall we can still access the old ldap server for testing purposes.

Next step see on the wire what the differences could be.

I can confirm one defect with 2.1.11:
The ability to export a secret key without passphrase available in gnupg2.0
is gone. My use case is to write a testcase that automatically imports the key.

Duplicate of T2324

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 ?