Re: ctf-like WKD challenge (was: WKD proper behavior on fetch error)

2021-01-20 Thread Stefan Claas via Gnupg-users
On Thu, Jan 21, 2021 at 8:02 AM Stefan Claas wrote: > The nice things about OpenPGP amored messages is also that > procmail and friends can be used at providers to filter -BEGIN blah P.S. When Stale Schumacher ran the International PGP Homepage in the 90's people could download PGP for

Re: ctf-like WKD challenge (was: WKD proper behavior on fetch error)

2021-01-20 Thread Stefan Claas via Gnupg-users
On Thu, Jan 21, 2021 at 12:25 AM Ángel wrote: > Last night, I prepared the domain wkdtest.pgp.16bits.net It is a valid > wkd server. I have just created and uploaded there a new pgp key, and > you have to obtain it: > > > «We have intercepted the following communication sent to an spy using > an

Re: Please tackle the Right Thing

2021-01-20 Thread Ángel
On 2021-01-20 at 20:29 +0100, André Colomb wrote: > Hi all, > > after some more thought I came up with a possible wording to clarify > the > fallback behavior. Assuming that an opportunistic approach is > preferred, so the direct method should be used not only based on the > existence of

ctf-like WKD challenge (was: WKD proper behavior on fetch error)

2021-01-20 Thread Ángel
On 2021-01-20 at 08:08 +0100, Stefan Claas via Gnupg-users wrote: > On Wed, Jan 20, 2021 at 12:41 AM Ángel wrote: > > > A list of all (well, most) openpgpkey subdomains can be easily > > created. > > Yes and I believe that what Neal and you (in your new posting) have > explained makes it only

Re: Please tackle the Right Thing

2021-01-20 Thread Stefan Claas via Gnupg-users
On Wed, Jan 20, 2021 at 9:21 PM Stefan Claas wrote: > > On Wed, Jan 20, 2021 at 4:15 PM Stefan Claas > wrote: > > > > On Wed, Jan 20, 2021 at 1:55 PM Werner Koch wrote: > > > > > Broken implementations are not a reason to break correct > > > implementations. > > > > Since 'broken'

Re: Please tackle the Right Thing

2021-01-20 Thread Stefan Claas via Gnupg-users
On Wed, Jan 20, 2021 at 4:15 PM Stefan Claas wrote: > > On Wed, Jan 20, 2021 at 1:55 PM Werner Koch wrote: > > > Broken implementations are not a reason to break correct > > implementations. > > Since 'broken' implementations are available and can handle both cases, > and this is now generally

Re: Please tackle the Right Thing

2021-01-20 Thread André Colomb
Hi all, after some more thought I came up with a possible wording to clarify the fallback behavior. Assuming that an opportunistic approach is preferred, so the direct method should be used not only based on the existence of openpgpkey as a SRV or other record. Here goes: ---SNIP--- (page 3,

Re: make check failed tests

2021-01-20 Thread Stefan Claas via Gnupg-users
On Wed, Jan 20, 2021 at 6:11 PM wrote: > > On Wed, Jan 20, 2021, mettodo via Gnupg-users wrote: > > > 14 of 20 tests failed when doing "make check" for gnupg 2.2.27. What > > should I do? > > Most certainly you should not tell anyone which OS or compiler > or options you used. > Neither should

Re: make check failed tests

2021-01-20 Thread ca+gnupg-users
On Wed, Jan 20, 2021, mettodo via Gnupg-users wrote: > 14 of 20 tests failed when doing "make check" for gnupg 2.2.27. What > should I do? Most certainly you should not tell anyone which OS or compiler or options you used. Neither should you include the actual test failures.

Re: Please tackle the Right Thing

2021-01-20 Thread Stefan Claas via Gnupg-users
On Wed, Jan 20, 2021 at 1:55 PM Werner Koch wrote: > Broken implementations are not a reason to break correct > implementations. Since 'broken' implementations are available and can handle both cases, and this is now generally known, people do *not* need to follow a *draft* and can *happily*

Re: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS

2021-01-20 Thread Werner Koch via Gnupg-users
On Wed, 20 Jan 2021 14:46, Erich Eckner said: > is queried. This resolves to some old address (my DNS configuration > error), which serves the wrong content. Is it right, that this SRV record > should be queried? Should I update it or remove it? Yes, the SRV record is used if there is no

Re: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS

2021-01-20 Thread Erich Eckner via Gnupg-users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 20 Jan 2021, Werner Koch wrote: On Tue, 19 Jan 2021 17:24, Erich Eckner said: error in the subject when doing `gpg - --locate-external-keys Many -v don't really help here because the actual task is done by the dirmngr process.

Re: Please tackle the Right Thing

2021-01-20 Thread Werner Koch via Gnupg-users
On Tue, 19 Jan 2021 16:31, Stefan Claas said: > there exists also a direct-method in you current draft, which people like > to use, when low on budged or which like to avoid, for whatever privacy If you do some research on the infrastructure of large providers (which includes talking to them)

Re: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS

2021-01-20 Thread Werner Koch via Gnupg-users
On Tue, 19 Jan 2021 17:24, Erich Eckner said: > error in the subject when doing `gpg - --locate-external-keys Many -v don't really help here because the actual task is done by the dirmngr process. Thus to debug this put log-file /somewhere/dirmngr.log verbose debug ipc,network,dns

Re: libgcrypt-1.9.0: 32 bit cross build fails on asm code

2021-01-20 Thread Werner Koch via Gnupg-users
Hi! thanks for the report. I opened a ticket for this: https://dev.gnupg.org/T5257 Please check over there for status updates. (I accidently mentioned gnupg-users in the annoucement mail and not gcryypt-devel which would been the right one). Shalom-Salam, Werner -- Die Gedanken sind

make check failed tests

2021-01-20 Thread mettodo via Gnupg-users
Hey, 14 of 20 tests failed when doing "make check" for gnupg 2.2.27. What should I do? thanks! ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users

libgcrypt-1.9.0: 32 bit cross build fails on asm code

2021-01-20 Thread balducci
hello (my specs are enclosed below) just tried to cross-build 32 bit libgcrypt-1.9.0 on a 64 bit machine and getting: 8< libtool: compile: gcc -m32 -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I../mpi -I../mpi -I/usr/include -I/usr/Xorg/include -fvisibility=hidden