Re: libgcrypt selftest failed

2021-01-27 Thread Ingo Klöcker 
On Donnerstag, 28. Januar 2021 01:51:30 CET Christopher Mansfield wrote:
> Hi there,
> 
> I'm running libgcrypt-1.9.0 on a Gentoo linux arm64. (actually I have 3
> arm64 machines and one x86_64 machine, all running Gentoo). I use the
> keepassxc application on all of these machines. After updating libgcrypt
> in the past couple of days, keepassxc won't start on my arm64 machines
> anymore. If I start it from a terminal, I see this message:
> 
> libgcrypt selftest: kdf  (34): invalid tests data
> (0xFFFEF
> FFF) libgcrypt selftest: kdf  (34):
> Selftest failed
> 
> The same keepassxc application works just fine on my x86_64 machine.
> 
> I created a small c program that calls GCRYTL_SELFTEST and it gives the
> same error on my arm64 machine. No error from my x86_64 machine.

Several problems with arm64 have been reported for libgcrypt-1.9.0, e.g.
https://dev.gnupg.org/T5251

I suggest to report your findings also at https://dev.gnupg.org/ to ensure 
that it's fixed in 1.9.1.

Also: The gcrypt-devel mailing list [1] is better suited for reports/questions 
about libgcrypt.

Regards,
Ingo

[1] https://lists.gnupg.org/mailman/listinfo/gcrypt-devel

signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

libgcrypt selftest failed

2021-01-27 Thread Christopher Mansfield 

Hi there,

I'm running libgcrypt-1.9.0 on a Gentoo linux arm64. (actually I have 3 
arm64 machines and one x86_64 machine, all running Gentoo). I use the 
keepassxc application on all of these machines. After updating libgcrypt 
in the past couple of days, keepassxc won't start on my arm64 machines 
anymore. If I start it from a terminal, I see this message:


libgcrypt selftest: kdf  (34): invalid tests data 
(0xFFFE)

libgcrypt selftest: kdf  (34): Selftest failed

The same keepassxc application works just fine on my x86_64 machine.

I created a small c program that calls GCRYTL_SELFTEST and it gives the 
same error on my arm64 machine. No error from my x86_64 machine.


Would appreciate any help with figuring out what's wrong - not sure if 
it's an actual bug, or maybe just the wrong build options.


Thanks,
Chris

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Please tackle the Right Thing

2021-01-27 Thread André Colomb 
On 23/01/2021 04.17, Ángel wrote:
>> control.  In that case, the unrelated webserver would happily answer the
>> openpgpkey subdomain request, but simply not find the required directory
>> structure, giving a 404.  My proposed solution would give the user a
>> chance to still enjoy the WKD direct method.
> 
> That's the point where the fact that a WKD server MUST have a policy
> file become useful for a fetching-only client. If it's a real WKD
> server the file shall be there, if it's a 404, that's probably
> meaningless.

Very good point.  So that could be the second definite point to decide
that the advanced method should be working and not fall back to direct.

> GnuPG first tries to directly fetch the key from the url where it's
> supposed to be. If it's found, it finishes there. If that's a 404, it
> then check that there is a policy file (and if there's not, the process
> caches in memory that there is no WKD on that place and won't contact
> that server again)
> On the other hand, flowcrypt first tries to read the policy file, and
> only after that succeeds, does it go for the public key.

Obviously another case where the draft is not clear enough, as it leads
to the same setup working with some clients, but not others.  The
current draft has this to say about the policy file checking:

[Section 3.1]
   The server MUST serve a Policy Flags file as specified below.  That
   file is even required if the Web Key Directory Update Protocol is not
   supported.

[Section 4.5]
   A site supporting the Web Key Directory MUST serve this file; it is
   sufficient if that file has a zero length.  Clients may use this file
   to check for Web Key Directory support.

> On this line, a few days ago I suggested changing the draft to require
> fallback to direct if such file is missing (as opposed to considering
> that the openpgpkey subdomain exists just when having an A/AAA record):
> 
> [...]
> 
> and over the course of the days, I have only become more convinced that
> this would be a good idea.

I agree it's a nice possibility to explicitly control the fallback
cases.  How about this suggested wording to specify client behavior:

[Section 3.1]
   There are two variants on how to form the request URI: The advanced
   and the direct method.  For either method, client implementations
   MUST first request the Policy Flags file at its respective location,
   described below.  Implementations MUST first try the advanced method.
   If that results in a successful HTTP response (e.g. status code 2xx)
   for the Policy Flags file, it proves the intention to use the chosen
   method, so the client MUST NOT fall back to a different method, even
   when the request for the key itself indicates an error (e.g. not
   found).  If the Policy Flags file is inaccessible, they MUST fall
   back to the direct method.

   If the required sub-domain exists, but other errors occur during the
   connection, implementations SHOULD output an error message pointing
   out the failure reason to the end user.  Such other errors include,
   for example, invalid, expired or misconfigured TLS certificates and
   HTTP failure codes (4xx or 5xx).

[Section 4.5]
   A site supporting the Web Key Directory MUST serve this file; it is
   sufficient if that file has a zero length.  Clients MUST use this
   file to check for Web Key Directory support, before sending requests
   for any actual keys.


Probably still rough around the edges and maybe not quite clear enough,
but it's a starting point to attract comments on the approach.

By the way, is there something like a repository to send and discuss
pull requests against the WKD draft document?  Or is it just
hand-crafted text edited by the submitter based on suggestions?

Kind regards
André

-- 
Greetings...
From: André Colomb 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[Announce] Pinentry 1.1.1 released

2021-01-27 Thread Damien Goutte-Gattat via Gnupg-users 

Hi,

The GnuPG project is pleased to announce the availability of the latest 
release of the collection of PIN or passphrase entry dialogs for GnuPG, 
Pinentry 1.1.1.



Noteworthy changes in version 1.1.1 (2021-01-21)
===

* A Pinentry for the Enlightenment environment is available.

* In the GTK, QT, TQt, and curses pinentries, echoing can be disabled by 
pressing the backspace key prior to any other input.


* The TTY pinentry now supports line editing.

* The GTK pinentry now requires GTK+ 2.12.0 or a later version.


Download


Source code is hosted at the GnuPG FTP server and its mirrors as listed 
on .  On the primary server the 
source tarball and its signature are:


  ftp://ftp.gnupg.org/gcrypt/pinentry/pinentry-1.1.1.tar.bz2
  ftp://ftp.gnupg.org/gcrypt/pinentry/pinentry-1.1.1.tar.bz2.sig

The same files are also available via HTTP:

  https://gnupg.org/ftp/gcrypt/pinentry/pinentry-1.1.1.tar.bz2
  https://gnupg.org/ftp/gcrypt/pinentry/pinentry-1.1.1.tar.bz2.sig


Signing keys


The tarball is signed by the following keys:

pub  rsa4096 2014-03-14 [SC]
 Key fingerprint = 4FA2 0823 62FE 73AD 03B8 8830 A8DC 7067 E25F BABB
uid  Damien Goutte-Gattat 

pub  ed25519 3030-08-24 [SC] [expires: 2030-06-30]
 Key fingerprint = 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA
uid  Werner Koch (dist signing key 2020)

The first of those keys is available via a WKD lookup:

  $ gpg --locate-key dgouttegat...@incenp.org

The second is available in https://gnupg.org/signature_key.html and in 
any recently released GnuPG tarball in the file g10/distsigkey.gpg.



Copying
===

Pinentry is copyright by g10 Code GmbH and licensed under the GNU 
General Public License version 2 or later (GPL-2.0+). The full text of 
the license is included in the COPYING file of the source distribution.



Support
===

The Pinentry manual is included in the source distribution in TeXinfo 
format. For community support, you may ask on the gnupg-users mailing 
list .


If you need commercial support, check out 
.


Maintenance and development of Pinentry and of GnuPG as a whole is 
mostly financed by donations. Please consider donating via 
.


signature.asc
Description: PGP signature
___
Gnupg-announce mailing list
gnupg-annou...@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users