From jjelen at REDHAT.COM Tue Apr 6 17:42:35 2021
From: jjelen at REDHAT.COM (jjelen at REDHAT.COM)
Date: Tue, 06 Apr 2021 17:42:35 +0200
Subject: Jakub Jelen DCO
Message-ID: <606c816b.3jWNtfUlv+V/i0eS%jjelen@REDHAT.COM>
-----BEGIN PGP MESSAGE-----
owGdVH9MVVUcfwg4vciPJN0qq2PGgHg8KDDBBFMohUQolE2djfPuPe+9A/fe87r3
vPd6tbfQJpthjVhUuLAtHdkW/ZiTJmvMIjMGS1yAK0ZqEkOxXKu1GoJ973kPUir+
6O7e3R/n++Pz+Xw/5zbGR9sWRb06HN1yeOQyjeq94rRVq3tqNum+ik2omPiJyrzE
SDVRETE4dVEZc4KYC5Ub1E11B0JVxDAp09GDjmyp4P8ckrQxiDRcS3U3wkhmOjeo
08etmpwh7iEoDMZrsBoiczsqQbLAEoRFzNdKUhpOR9sg7pbcADaRbBCAqyAKrx6m
AnDDevZigyMnNCUI6woqkRAcHuwnohsQ83CrtelzapQjOH26Qgyx6DIIQSZz8QA2
CFKpTHSTiHyqK0Ic0U2EUpU8Ah0Bn/Nf8FETObEJ4T4vvHkN4qfMZ6IAM2oFL3uE
vSjuJCa3VNeCqFZnAZUobmK3SsjMTwyriECIdYS9oJPXoNaYLLAifS7gMO25lGdY
Yj4bx1k4P6yEWBIAA5R7kMaUsCGAjmkHhQnUMv4huqgwV3j7TZqaWJtP2DSfrhLT
BLxYQ+BFQGKV/3tAEe4I0LhADH0WfrpdFAAjzDcc+T/MAzr6qQIpCjXAd2rQaglI
Ab/J4M4stqIBgDKZYBtxJoUsMKUdWZMH6laPmyTXGY+IR5Swd7gDgCjpECDImNyK
Fpfb0kUIzz3UnNkEYo3PQR0mC+p5fU5QIBIDmRgBAWYoloPmJqE0qsuqT4HdF84/
maeqEUZYBblczNDEiAFcRHAxfQoOnU0FY4aNQt16JnO50i1vapjqHC6hukJcVKec
gIwWLg0HwdSAS6FmGEtECsBmwidriqLNLazZPJswzUyP7EM/U/1EAUUrAQ1RLDyZ
zuBaVIprfU5USlSio3U1Ndb9UQAACjlkphVK+6OOxdiiFtnuXr4yJiZQ/JW/d+uI
a/vZ8zM/x9gF1p/RJi1OmvnyaXLcdcm8J1/u7H64sui1ggR/z13tGTXSj6NbW8oa
Qr9Krsf7C8ekI+srCp/wZuPNl9pyE4cPLvx60MGe6rvYXEBuT329LrlF2lJy7/QX
oZTSF4cyWq8t6DgRvfGt/m92JTVd/qSs9ezHsXvGPwgtaT/Fu3I2XBpsz1n39vbV
L5Vuq0pOfuz0mc7dE/LBVzYnZLv7Fn70nDqamJ9Xfd9AkhRqGxoY/tLXppC6zvrp
pov1O386nsvfDTz0Yai4C6/KP/P7eOzeZ8a05gveqfLJ8e7cC6caqndoRw71xL1s
G3DkvPf0k1O1JWVv5r9RMaZ83uhZ1l2/vsld0XRoR86fDWM9u7u+T00N5TUeHae/
9Nx44bstuyZ2DlyVD6T1tqycuLMp5v34lipPtTszmLksY0XmH5/te4AO9aXUGV1x
+SfMcyTr5/GB1pP6bdN60ZLJ56dvZI2czvx2X5dj1Zrl7XfcvyalMvqHK3tLNthG
VyRMHjt+7vzS37IWo8PvDE4l1vGO/qXXmjuiy+OPPnt1/+rrfwE=
=VgAE
-----END PGP MESSAGE-----
From wk at gnupg.org Thu Apr 8 11:05:48 2021
From: wk at gnupg.org (Werner Koch)
Date: Thu, 08 Apr 2021 11:05:48 +0200
Subject: [Announce] GnuPG 2.3.0 released
Message-ID: <877dld87tf.fsf@wheatstone.g10code.de>
Hello!
We are pleased to announce the availability of a new GnuPG release:
version 2.3.0. This release marks the start of public testing releases
eventually leading to a new stable version 2.4.
Although some bugs might linger in the 2.3 versions, they are intended
to replace the 2.2 series. 2.3 may even be used for production purposes
if either the risk of minor regressions is acceptable or the new
features are important.
What is GnuPG
=============
The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation
of the OpenPGP and S/MIME standards.
GnuPG allows to encrypt and sign data and communication, features a
versatile key management system as well as access modules for public key
directories. GnuPG itself is a command line tool with features for easy
integration with other applications. The separate library GPGME provides
a uniform API to use the GnuPG engine by software written in common
programming languages. A wealth of frontend applications and libraries
making use of GnuPG are available. As an universal crypto engine GnuPG
provides support for S/MIME and Secure Shell in addition to OpenPGP.
GnuPG is Free Software (meaning that it respects your freedom). It can
be freely used, modified and distributed under the terms of the GNU
General Public License.
Three different versions of GnuPG are actively maintained:
- This version (2.3) is the latest development with a lot of new
features. This announcement is about the first release of this
version.
- Version 2.2 is our LTS (long term support) version and guaranteed to
be maintained at least until the end of 2024.
See https://gnupg.org/download/index.html#end-of-life
- Version 1.4 is maintained to allow decryption of very old data which
is, for security reasons, not anymore possible with other GnuPG
versions.
Noteworthy changes in version 2.3.0 (2021-04-07)
================================================
* A new experimental key database daemon is provided. To enable it
put "use-keyboxd" into gpg.conf and gpgsm.conf. Keys are stored
in a SQLite database and make key lookup much faster.
* New tool gpg-card as a flexible frontend for all types of
supported smartcards.
* New option --chuid for gpg, gpgsm, gpgconf, gpg-card, and
gpg-connect-agent.
* The gpg-wks-client tool is now installed under bin; a wrapper for
its old location at libexec is also installed.
* tpm2d: New daemon to physically bind keys to the local machine.
See https://gnupg.org/blog/20210315-using-tpm-with-gnupg-2.3.html
* gpg: Switch to ed25519/cv25519 as default public key algorithms.
* gpg: Verification results now depend on the --sender option and
the signer's UID subpacket. [#4735]
* gpg: Do not use any 64-bit block size cipher algorithm for
encryption. Use AES as last resort cipher preference instead of
3DES. This can be reverted using --allow-old-cipher-algos.
* gpg: Support AEAD encryption mode using OCB or EAX.
* gpg: Support v5 keys and signatures.
* gpg: Support curve X448 (ed448, cv448).
* gpg: Allow use of group names in key listings. [e825aea2ba]
* gpg: New option --full-timestrings to print date and time.
* gpg: New option --force-sign-key. [#4584]
* gpg: New option --no-auto-trust-new-key.
* gpg: The legacy key discovery method PKA is no longer supported.
The command --print-pka-records and the PKA related import and
export options have been removed.
* gpg: Support export of Ed448 Secure Shell keys.
* gpgsm: Add basic ECC support.
* gpgsm: Support creation of EdDSA certificates. [#4888]
* agent: Allow the use of "Label:" in a key file to customize the
pinentry prompt. [5388537806]
* agent: Support ssh-agent extensions for environment variables.
With a patched version of OpenSSH this avoids the need for the
"updatestartuptty" kludge. [224e26cf7b]
* scd: Improve support for multiple card readers and tokens.
* scd: Support PIV cards.
* scd: Support for Rohde&Schwarz Cybersecurity cards.
* scd: Support Telesec Signature Cards v2.0
* scd: Support multiple application on certain smartcard.
* scd: New option --application-priority.
* scd: New option --pcsc-shared; see man page for important notes.
* dirmngr: Support a gpgNtds parameter in LDAP keyserver URLs.
* The symcryptrun tool, a wrapper for the now obsolete external
Chiasmus tool, has been removed.
* Full Unicode support under Windows for the command line. [#4398]
Release-info: https://dev.gnupg.org/T5343
Getting the Software
====================
Please follow the instructions found at or
read on:
GnuPG 2.3.0 may be downloaded from one of the GnuPG mirror sites or
direct from its primary FTP server. The list of mirrors can be found at
. Note that GnuPG is not
available at ftp.gnu.org.
The GnuPG source code compressed using BZIP2 and its OpenPGP signature
are available here:
https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.3.0.tar.bz2 (7380k)
https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.3.0.tar.bz2.sig
An installer for Windows without any graphical frontend except for a
very minimal Pinentry tool is available here:
https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.3.0_20210407.exe (4560k)
https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.3.0_20210407.exe.sig
The source used to build the Windows installer can be found in the same
directory with a ".tar.xz" suffix.
A new version of Gpg4win featuring this version of GnuPG will be
released soon. In the meantime it is possible to install this GnuPG
version on top of Gpg4win 3.1.15.
Checking the Integrity
======================
In order to check that the version of GnuPG which you are going to
install is an original and unmodified one, you can do it in one of
the following ways:
* If you already have a version of GnuPG installed, you can simply
verify the supplied signature. For example to verify the signature
of the file gnupg-2.3.0.tar.bz2 you would use this command:
gpg --verify gnupg-2.3.0.tar.bz2.sig gnupg-2.3.0.tar.bz2
This checks whether the signature file matches the source file.
You should see a message indicating that the signature is good and
made by one or more of the release signing keys. Make sure that
this is a valid key, either by matching the shown fingerprint
against a trustworthy list of valid release signing keys or by
checking that the key has been signed by trustworthy other keys.
See the end of this mail for information on the signing keys.
* If you are not able to use an existing version of GnuPG, you have
to verify the SHA-1 checksum. On Unix systems the command to do
this is either "sha1sum" or "shasum". Assuming you downloaded the
file gnupg-2.3.0.tar.bz2, you run the command like this:
sha1sum gnupg-2.3.0.tar.bz2
and check that the output matches the next line:
44d06ef6625378e2d135420543e5fb06b62437ab gnupg-2.3.0.tar.bz2
6069b70870cb378b1937a79a752ccc3e9951e0a1 gnupg-w32-2.3.0_20210407.tar.xz
2c1a25a57a785cc96ae7ec317de9d1fb513161b7 gnupg-w32-2.3.0_20210407.exe
Internationalization
====================
This version of GnuPG has support for 26 languages with Chinese
(traditional and simplified), Czech, French, German, Italian,
Japanese, Norwegian, Polish, Russian, and Ukrainian being almost
completely translated.
Documentation and Support
=========================
The file gnupg.info has the complete reference manual of the system.
Separate man pages are included as well but they miss some of the
details available only in the manual. The manual is also available
online at
https://gnupg.org/documentation/manuals/gnupg/
or can be downloaded as PDF at
https://gnupg.org/documentation/manuals/gnupg.pdf
You may also want to search the GnuPG mailing list archives or ask on
the gnupg-users mailing list for advise on how to solve problems. Most
of the new features are around for several years and thus enough public
experience is available. https://wiki.gnupg.org has user contributed
information around GnuPG and relate software.
In case of build problems specific to this release please first check
https://dev.gnupg.org/T5343 for updated information.
Please consult the archive of the gnupg-users mailing list before
reporting a bug: https://gnupg.org/documentation/mailing-lists.html.
We suggest to send bug reports for a new release to this list in favor
of filing a bug at https://bugs.gnupg.org. If you need commercial
support go to https://gnupg.com or https://gnupg.org/service.html.
If you are a developer and you need a certain feature for your project,
please do not hesitate to bring it to the gnupg-devel mailing list for
discussion.
Thanks
======
Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH
and still mostly financed by donations. Three full-time employed
developers as well as two contractors exclusively work on GnuPG and
closely related software like Libgcrypt, GPGME and Gpg4win.
We like to thank all the nice people who are helping the GnuPG project,
be it testing, coding, translating, suggesting, auditing, administering
the servers, spreading the word, or answering questions on the mailing
lists.
The financial support of the governmental CERT of Luxembourg
(GOVCERT.LU) allowed us to develop new and improved features for
smartcards (Yubikey, PIV and Scute) as well as various usability
features. Thanks.
Many thanks also to all other financial supporters, both corporate and
individuals. Without you it would not be possible to keep GnuPG in a
good and secure shape and to address all the small and larger requests
made by our users.
Happy hacking,
Your GnuPG hackers
p.s.
This is an announcement only mailing list. Please send replies only to
the gnupg-users at gnupg.org mailing list.
p.p.s
List of Release Signing Keys:
To guarantee that a downloaded GnuPG version has not been tampered by
malicious entities we provide signature files for all tarballs and
binary versions. The keys are also signed by the long term keys of
their respective owners. Current releases are signed by one or more
of these four keys:
ed25519 2020-08-24 [expires: 2030-06-30]
Key fingerprint = 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA
Werner Koch (dist signing 2020)
rsa3072 2017-03-17 [expires: 2027-03-15]
Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28
Andre Heinecke (Release Signing Key)
rsa2048 2011-01-12 [expires: 2021-12-31]
Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6
Werner Koch (dist sig)
The keys are available at https://gnupg.org/signature_key.html and
in any recently released GnuPG tarball in the file g10/distsigkey.gpg .
Note that this mail has been signed by a different key.
--
"If privacy is outlawed, only outlaws will have privacy."
- PRZ 1991
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL:
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce
From dgouttegattat at incenp.org Sun Apr 11 14:06:40 2021
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Sun, 11 Apr 2021 13:06:40 +0100
Subject: [PATCH gnupg] wks-client: Allow use with the keybox daemon.
Message-ID: <20210411120640.17532-1-dgouttegattat@incenp.org>
* tools/gpg-wks.h (struct opt): New member use_keyboxd.
* tools/gpg-wks-client.c (opts): New option --use-keyboxd.
(add_user_id): Call gpg with --use-keyboxd if needed.
(decrypt_stream): Likewise.
(encrypt_response): Likewise.
* tools/wks-util.c (wks_get_key): Likewise.
(wks_list_key): Likewise.
(wks_filter_uid): Likewise.
--
The gpg-wks-client always calls gpg with --no-options to ignore
whatever options are in the user's gpg.conf. This makes the client
unusable if gpg is normally configured to use the keybox daemon,
as the 'use-keyboxd' directive in gpg.conf will be ignored as well
and the gpg process called from gpg-wks-client will then attempt
to find the public keys in pubring.kbx.
The quick workaround here is to add a --use-keyboxd option to
gpg-wks-client as well. Maybe a better long-term fix would be to
enquire the status of gpg's --use-keyboxd option from gpgconf.
Signed-off-by: Damien Goutte-Gattat
---
doc/wks.texi | 6 ++++++
tools/gpg-wks-client.c | 11 +++++++++++
tools/gpg-wks.h | 1 +
tools/wks-util.c | 6 ++++++
4 files changed, 24 insertions(+)
diff --git a/doc/wks.texi b/doc/wks.texi
index ad239f132..68492ef63 100644
--- a/doc/wks.texi
+++ b/doc/wks.texi
@@ -178,6 +178,12 @@ Use @var{dir} as top level directory for the commands
@option{--install-key} and @option{--remove-key}. The default is
@file{openpgpkey}.
+ at item --use-keyboxd
+ at opindex use-keyboxd
+Get the public keys from the keybox daemon. This is necessary if gpg
+is itself configured to use the daemon instead of the old pubring.kbx
+file.
+
@item --verbose
@opindex verbose
Enable extra informational output.
diff --git a/tools/gpg-wks-client.c b/tools/gpg-wks-client.c
index b56343232..8294047c3 100644
--- a/tools/gpg-wks-client.c
+++ b/tools/gpg-wks-client.c
@@ -72,6 +72,7 @@ enum cmd_and_opt_values
oFakeSubmissionAddr,
oStatusFD,
oWithColons,
+ oUseKeyboxd,
oDummy
};
@@ -111,6 +112,7 @@ static gpgrt_opt_t opts[] = {
ARGPARSE_s_i (oStatusFD, "status-fd", N_("|FD|write status info to this FD")),
ARGPARSE_s_n (oWithColons, "with-colons", "@"),
ARGPARSE_s_s (oDirectory, "directory", "@"),
+ ARGPARSE_s_n (oUseKeyboxd, "use-keyboxd", ("get the keys from keyboxd")),
ARGPARSE_s_s (oFakeSubmissionAddr, "fake-submission-addr", "@"),
@@ -236,6 +238,9 @@ parse_arguments (gpgrt_argparse_t *pargs, gpgrt_opt_t *popts)
case oWithColons:
opt.with_colons = 1;
break;
+ case oUseKeyboxd:
+ opt.use_keyboxd = 1;
+ break;
case aSupported:
case aCreate:
@@ -509,6 +514,8 @@ add_user_id (const char *fingerprint, const char *uid)
ccparray_init (&ccp, 0);
ccparray_put (&ccp, "--no-options");
+ if (opt.use_keyboxd)
+ ccparray_put (&ccp, "--use-keyboxd");
if (!opt.verbose)
ccparray_put (&ccp, "--quiet");
else if (opt.verbose > 1)
@@ -594,6 +601,8 @@ decrypt_stream (estream_t *r_output, struct decrypt_stream_parm_s *decinfo,
ccparray_init (&ccp, 0);
ccparray_put (&ccp, "--no-options");
+ if (opt.use_keyboxd)
+ ccparray_put (&ccp, "--use-keyboxd");
/* We limit the output to 64 KiB to avoid DoS using compression
* tricks. A regular client will anyway only send a minimal key;
* that is one w/o key signatures and attribute packets. */
@@ -1245,6 +1254,8 @@ encrypt_response (estream_t *r_output, estream_t input, const char *addrspec,
ccparray_init (&ccp, 0);
ccparray_put (&ccp, "--no-options");
+ if (opt.use_keyboxd)
+ ccparray_put (&ccp, "--use-keyboxd");
if (!opt.verbose)
ccparray_put (&ccp, "--quiet");
else if (opt.verbose > 1)
diff --git a/tools/gpg-wks.h b/tools/gpg-wks.h
index 6c5dc8b17..941b54614 100644
--- a/tools/gpg-wks.h
+++ b/tools/gpg-wks.h
@@ -38,6 +38,7 @@ struct
int quiet;
int use_sendmail;
int with_colons;
+ int use_keyboxd;
const char *output;
const char *gpg_program;
const char *directory;
diff --git a/tools/wks-util.c b/tools/wks-util.c
index 516c7fe00..e1d5437b1 100644
--- a/tools/wks-util.c
+++ b/tools/wks-util.c
@@ -204,6 +204,8 @@ wks_get_key (estream_t *r_key, const char *fingerprint, const char *addrspec,
ccparray_init (&ccp, 0);
ccparray_put (&ccp, "--no-options");
+ if (opt.use_keyboxd)
+ ccparray_put (&ccp, "--use-keyboxd");
if (!opt.verbose)
ccparray_put (&ccp, "--quiet");
else if (opt.verbose > 1)
@@ -301,6 +303,8 @@ wks_list_key (estream_t key, char **r_fpr, uidinfo_list_t *r_mboxes)
ccparray_init (&ccp, 0);
ccparray_put (&ccp, "--no-options");
+ if (opt.use_keyboxd)
+ ccparray_put (&ccp, "--use-keyboxd");
if (!opt.verbose)
ccparray_put (&ccp, "--quiet");
else if (opt.verbose > 1)
@@ -478,6 +482,8 @@ wks_filter_uid (estream_t *r_newkey, estream_t key, const char *uid,
ccparray_init (&ccp, 0);
ccparray_put (&ccp, "--no-options");
+ if (opt.use_keyboxd)
+ ccparray_put (&ccp, "--use-keyboxd");
if (!opt.verbose)
ccparray_put (&ccp, "--quiet");
else if (opt.verbose > 1)
--
2.27.0
From dgouttegattat at incenp.org Mon Apr 12 13:17:48 2021
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Mon, 12 Apr 2021 12:17:48 +0100
Subject: [PATCH gnupg] gpg: Fix showpref to list AEAD feature.
Message-ID: <20210412111748.21059-1-dgouttegattat@incenp.org>
* g10/keyedit.c (show_prefs): Show 'AEAD' if flags.aead is set.
--
The terse 'pref' command in the key editor correctly shows '[aead]'
if the uid->flags.aead is set, but the more verbose 'showpref'
command does not, due to an inverted condition check.
Signed-off-by: Damien Goutte-Gattat
---
g10/keyedit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/g10/keyedit.c b/g10/keyedit.c
index d07ec6526..531d3e128 100644
--- a/g10/keyedit.c
+++ b/g10/keyedit.c
@@ -3419,7 +3419,7 @@ show_prefs (PKT_user_id * uid, PKT_signature * selfsig, int verbose)
tty_printf ("MDC");
any = 1;
}
- if (!uid->flags.aead)
+ if (uid->flags.aead)
{
if (any)
tty_printf (", ");
--
2.27.0
From wk at gnupg.org Tue Apr 13 16:30:22 2021
From: wk at gnupg.org (Werner Koch)
Date: Tue, 13 Apr 2021 16:30:22 +0200
Subject: [PATCH gnupg] wks-client: Allow use with the keybox daemon.
In-Reply-To: <20210411120640.17532-1-dgouttegattat@incenp.org> (Damien
Goutte-Gattat via Gnupg-devel's message of "Sun, 11 Apr 2021 13:06:40
+0100")
References: <20210411120640.17532-1-dgouttegattat@incenp.org>
Message-ID: <87mtu22r5t.fsf@wheatstone.g10code.de>
On Sun, 11 Apr 2021 13:06, Damien Goutte-Gattat said:
> unusable if gpg is normally configured to use the keybox daemon,
> as the 'use-keyboxd' directive in gpg.conf will be ignored as well
> and the gpg process called from gpg-wks-client will then attempt
Right, that is obvious. Actually I am not very happy with the
use-keybox option because this needs to be set into gpg.conf and
gpgsm.conf. And in other as you noted. This is quite confusing and it
can be expected to be a common issue in bug reports.
I have two ideas on how to fix that:
1. Add an option "enable" to keyboxd.conf and let all other tools read
this config file too.
2. Provide a gnupg.conf file which can be used for such system wide
options. log-file socket:// would also be a canditate for such a
file.
The former would be the quick way to handle things, the latter the more
universal solution.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL:
From jcb62281 at gmail.com Wed Apr 14 03:40:32 2021
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Tue, 13 Apr 2021 20:40:32 -0500
Subject: [PATCH gnupg] wks-client: Allow use with the keybox daemon.
In-Reply-To: <87mtu22r5t.fsf@wheatstone.g10code.de>
References: <20210411120640.17532-1-dgouttegattat@incenp.org>
<87mtu22r5t.fsf@wheatstone.g10code.de>
Message-ID: <60764810.3000708@gmail.com>
Werner Koch via Gnupg-devel wrote:
> 2. Provide a gnupg.conf file which can be used for such system wide
> options. log-file socket:// would also be a canditate for such a
> file.
>
> The former would be the quick way to handle things, the latter the more
> universal solution.
>
For whatever it is worth, I advocate for the more universal solution and
suggest also adding [section] headers for tool-specific configuration in
gnupg.conf. Allowing [TOOL:TAG] with TAG given using a command-line
option could enable users to group common settings for different uses.
If this approach is taken, I suggest that options set before any
[section] is reached would be global, applying to all tools in GPG; the
log-file and keyboxd options would go in that unnamed first section.
-- Jacob
From wk at gnupg.org Wed Apr 14 13:18:27 2021
From: wk at gnupg.org (Werner Koch)
Date: Wed, 14 Apr 2021 13:18:27 +0200
Subject: [PATCH gnupg] wks-client: Allow use with the keybox daemon.
In-Reply-To: <60764810.3000708@gmail.com> (Jacob Bachmeyer via Gnupg-devel's
message of "Tue, 13 Apr 2021 20:40:32 -0500")
References: <20210411120640.17532-1-dgouttegattat@incenp.org>
<87mtu22r5t.fsf@wheatstone.g10code.de> <60764810.3000708@gmail.com>
Message-ID: <87sg3t15do.fsf@wheatstone.g10code.de>
On Tue, 13 Apr 2021 20:40, Jacob Bachmeyer said:
> and suggest also adding [section] headers for tool-specific
Nope, we can't do that due to backward compatibility. Instead we have
an advanced system to handle global options inclusive a way to ignore
options set by a user. It is not weel documented, I should finish my
draft blog entry for this.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL:
From jcb62281 at gmail.com Thu Apr 15 03:37:55 2021
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Wed, 14 Apr 2021 20:37:55 -0500
Subject: [PATCH gnupg] wks-client: Allow use with the keybox daemon.
In-Reply-To: <87sg3t15do.fsf@wheatstone.g10code.de>
References: <20210411120640.17532-1-dgouttegattat@incenp.org> <87mtu22r5t.fsf@wheatstone.g10code.de>
<60764810.3000708@gmail.com> <87sg3t15do.fsf@wheatstone.g10code.de>
Message-ID: <607798F3.6060102@gmail.com>
Werner Koch wrote:
> On Tue, 13 Apr 2021 20:40, Jacob Bachmeyer said:
>
>> and suggest also adding [section] headers for tool-specific
>>
>
> Nope, we can't do that due to backward compatibility. Instead we have
> an advanced system to handle global options inclusive a way to ignore
> options set by a user. It is not weel documented, I should finish my
> draft blog entry for this.
How would this break backwards compatibility? As I understand,
"[SECTION]" is currently invalid syntax, so no existing files would
become invalid.
It may be necessary for GPG to continue to recognize GPG-specific
options in the global section, but adding section headers provides a
migration path forwards.
-- Jacob
From wk at gnupg.org Thu Apr 15 08:30:13 2021
From: wk at gnupg.org (Werner Koch)
Date: Thu, 15 Apr 2021 08:30:13 +0200
Subject: [PATCH gnupg] wks-client: Allow use with the keybox daemon.
In-Reply-To: <607798F3.6060102@gmail.com> (Jacob Bachmeyer via Gnupg-devel's
message of "Wed, 14 Apr 2021 20:37:55 -0500")
References: <20210411120640.17532-1-dgouttegattat@incenp.org>
<87mtu22r5t.fsf@wheatstone.g10code.de> <60764810.3000708@gmail.com>
<87sg3t15do.fsf@wheatstone.g10code.de> <607798F3.6060102@gmail.com>
Message-ID: <87y2dkys96.fsf@wheatstone.g10code.de>
On Wed, 14 Apr 2021 20:37, Jacob Bachmeyer said:
> How would this break backwards compatibility? As I understand,
> "[SECTION]" is currently invalid syntax, so no existing files would
> become invalid.
For example because you can't use the same config files anymore with the
2.2 version. GnuPG has always used component specific configuration
file and such section lines would change that.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL:
From dantipov at cloudlinux.com Thu Apr 15 16:30:12 2021
From: dantipov at cloudlinux.com (Dmitry Antipov)
Date: Thu, 15 Apr 2021 17:30:12 +0300
Subject: No key data exported by gpgme_op_export_keys()
Message-ID:
Hello,
could someone please explain why an attached test program (loosely based on gpgme tests)
is able to echo back my test key but refuses to zero output bytes for Fedora 33 primary one?
$ gcc -Wall -O2 $(pkg-config --cflags gpgme) -g t-gpgme-import.c -o t-gpgme-import $(pkg-config --libs gpgme)
$ ./t-gpgme-import RPM-GPG-KEY-test
1 key(s) found
read 4443 bytes of key(s) data:
-----BEGIN PGP PUBLIC KEY BLOCK-----
...actual data follows...
-----END PGP PUBLIC KEY BLOCK-----
$ ./t-gpgme-import RPM-GPG-KEY-fedora-33-primary
1 key(s) found
read 0 bytes of key(s) data:
???
Observed on gnupg2-2.2.27 + gpgme-1.15.1, if that matters.
Thanks,
Dmitry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t-gpgme-import.c
Type: text/x-csrc
Size: 1690 bytes
Desc: not available
URL:
-------------- next part --------------
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQINBGBcTc4BEADF7NC6a5RPC0m6s6OXS4CEkkK6EKna7Vm9+dmSMWWuonZWQGH3
VG3Kd8GDymFHAAO8zBfm49XEt1qKi2tXghnsXKQVo4fj/vHCcGzzd3D62SFqkOr0
Q0DlNoNZGzht94ihmm095hegOLoQfyuFQ6wyn8ZK1Mg0dCgWwY5tq834FjMyeWJN
bweiQ+n/JvmOnM7ETO3p3vCXTPWdr/9i64CGbvnVDqhyl77TFj9GCPIvikKgePtq
Y0h9Rvh8F9jabzxE+vHNcLRQWjAqhs90gZK0ag78dXiPSt/lVmQ40GtScRqk8zgZ
csGfVqVOELUAVXbNOq1pBK36K5eNMrwHzPFNggIpxA2V2ccigfblghe7DnbqypxD
uXkf46lmAJBmPhBlH2O6dY61U6VGKA5RdULhrLvmAOfDhxLhXYHuAkcgbPSP0Udu
z3ECgaE+enaiJAPYIzEMBd4e4j8VxQzpXKrOLFt4wzO1mUJRuePpWyBO/DJPyia6
9WbeBLbJGCyHooyrSG8MxE6672ZSP9zbDEkDAO9Tx8V3mz3oJ32+6dl+ogxt0Bsy
umrLs7tlZZonlSBUkY9nuTlClTw7aCqkEbxFbBEBOsApkCOCVM5jT8gzouotCOcL
vtEyXwGKWf9zao2rbOpwG7JJwl0AC2AIw2yVvVgiXf4Bgh96NAogmrv41wARAQAB
tCZDbG91ZExpbnV4LCBJbmMuIDxpbmZvQGNsb3VkbGludXguY29tPokCVAQTAQgA
PhYhBBDfoEUEh9jmYxc41B1moXiUd8UjBQJgXE3OAhsBBQkDwmcABQsJCAcCBhUK
CQgLAgQWAgMBAh4BAheAAAoJEB1moXiUd8UjtmMP/26n9BaMLefvRsFYRIYIFQ6A
f8by+WNYgTZ3eAWq3jUuIAK5YzHUt6/ep8apYqAhAJa+lKsnGSnVCMyml4uByeN7
YtxzeJuTN6aUt2wc/y8zxj6TuQuisyO7CV7CroGd6wNX+8TARjHOL3ZfMDuBUege
v6cbPVLAj7G4sxj6gqG8NDWV9l+g9I+50D5v9eLd+cuM9QcdQSvckJAOBi37ITdK
1KDIWkiV45uSK9LoFWe6fcy6Y3FMw5IMxCpaYMcRr3ZUNCKvT+8Fltti/dRS8p9c
UKJdBQ36XffyoZ66HpOTOGBaAb91F6EnifrFsepY0SWsYiFnjUTQ1h082jPOBFB8
Yn4diPjB28BrOnWXcpdvfuOM5S5+06OCTn6rzvR3E0oyBn7ZAsdHqwTmHh8mPPxN
NGtmtScjOXhGfUDlHnEy5e2PbudFZKybTCnHMjKH3/OeZtDfZzPbxrPcidT2hvcj
ndTP5KoG6xuv44jK/a4SAFMQLb9bxCmqx8cAq34X2fB4+5Mf3AhSid6dbnw+4hdV
TJi2gpm33UJUhOWscKBJtUNW2lpivF0AO5Ov3QDCNjPEckbb7R+b/XcQB4PAqVk0
d9UQjbNAe6/KpWZc2VrNKRqv0zep75Uufd/NeZXCahuOcSyEuhVRVI6tFAE15fs3
qY5R5hL4uhtcTQ+fehNwtChEbWl0cnkgQW50aXBvdiA8ZGFudGlwb3ZAY2xvdWRs
aW51eC5jb20+iQJUBBMBCAA+FiEEEN+gRQSH2OZjFzjUHWaheJR3xSMFAmBcTh4C
GwEFCQPCZwAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQHWaheJR3xSO3exAA
iKfqKGyrIWLR9Nr7q1/Cxq2IuJJFtzJw+QZlBTSECQPPCzIHBjxaN8YaoUUn6odR
Hsr5tq5VYnLH78eSOzG72FFGbdUrXHA32ghSmMPlM7DIRZnB2tKb23UIQCn20U21
J7E2/YCSk3yxrJgGA55t6DXKLQ69K2c+2OYiJVv0CqNhVW9KhCAzwC/uHG7WqBiM
GTfnWJyziuxntDeuc0RYJE1pAeja0FwqsZdOT7YPPugrOyhOYqz/jum2oMePn3gz
U0bMFos+uP/3H6JDTBMtxyRgQOTu423dmQX9oDCkvMWXrdmB5VzZLtEMDotbjx4X
tQy38RBfvP7ngAlVcXXgW8kGVDQnTfhPLMWRMvczlCb6/esMJVih3ehAAo2XNfVK
QHAnEo5P8gtmX2R2d7C1I0TZhHeZZVhh9I/bm0PvpQmL/EMHpKv6Svn/2la6o1Pq
Yi3Ddeinba7EHzWJbSMOvZvfUBE+9eKR2G+t1xhu/NtiBFjc53ZXK6BKQ1tbRcAj
2p6xi3MksS6ZIy5qxQJwY3H4nVoSdAFSjM4as4NXtSwL8g88KNmhQg/6+8NQenYj
dtrFDNpmvjatP1YbAL62b7fT6hudzq+tQ9DBTMRJTj2fYVuR+JyMqWfEy8h6oWlF
dzsN8kj7e8x37tLLjjaRPHjui6ovNaW0Tu+bPjBwi0y5AY0EYFxN/gEMALT7wVFV
xbqa86e6puRATlVe2F7WfletD634s3jxS7QjW6ZY6pjVoU07lsBLMi0btdNwDijX
puql/9LjNYmRQtQZRC38V21jD/N8rETRkqVNeXv8g1z18G4FdVuU6wO1+oAYXU4y
waumo2WBwgTcPBl5hV10/LHDuqAqnRp2oOTNbXlCChLMiXiwVkjYbE5AjxqJxXSW
rpAmg33WPpxJSLX/eiVkdv4LVd9ywmetXaL2P6WaI/8Tac2aCyJ4YVqu1T7OoPoa
gLk0SDdnXMbKWydZ73sXoH+Axn7zh0CZURV1XvexQeML4zB4H3Lk6sX9uiV0u7B1
Bix+dovb/23zrvKHUah+yyaeZbM3850XOawf4D4QKE2pifwpzKCwbxlfmlUhoVhq
PiUwmQaDrAcqPsOy8KI5SzrtuTXRHKO3sGRk879g+oj2ua2XAg2l27DoJy18KiMM
l3PTQWer9uLFPPj4FUwEiVn9/4V9hx9pKcpm/7I8TpjlTOAfqU4rXsJIRwARAQAB
iQPyBBgBCAAmFiEEEN+gRQSH2OZjFzjUHWaheJR3xSMFAmBcTf4CGwIFCQPCZwAB
wAkQHWaheJR3xSPA9CAEGQEIAB0WIQRuOq6OcbjbnltBgjqq0SjkmQfqGwUCYFxN
/gAKCRCq0SjkmQfqG0l8C/9qZ0H2NlcQZwtUOr8bHe+dLiZEl61tS4laPVK3wK/S
TRHpwxGr0kf4tP3vbm4GL6LCFP8bIUdIany1Q6/q5ortD3BOsVISngduk8NWFF+A
2E9aG7OR8KV4YTzM2d/f/WFPdxbwcCddADjYJs+EPhqB2wDZ3LTMzAmjoi63DEuL
uRsUA1LlXwGFBJDEP4DTKVQXUIDuq2A8INIHcHmsi10KOpFDcxaqz5MOSZ27Aybf
PaHQ+GlRp/HBy07GfpLEsp7ZnyfY220IuMbRZ9Uv/pRqoHEwRzL4FkzaTGA8sb4o
5pM9OdcUKSu2Pv1AXg4XGyCT/+OQHcPh9W2OPmuQZwUskjElfCe34SgnrIYKg2dW
df+kkiA7GuyXkltwTn3QK8WlxmjfIdoKeVniOrn2sQPDq4u9R8/PsSqGcp5Adgm0
MbCT92ne80PEWyNlLg3jnJ2kEErfWefz+m21e8E1PIzh91/M9qA5kd35Y+ElUugk
FOyGtoqvNVwaJ2C8Zj7af1aMyg//QQU3dOZyeoKUMh4Ajkq+bq+57IOGaDJE76En
VY4NRnOP434Hej/Fv/1cZSJPUERmz8LvxK7uxw0OdxcObTCLmp6Tjtp5i275knB6
fp5ex1dcRVHte5UjIoOS6FA5zfjCoVjau/2wOiBXiKsIzgDzxzxGXuYiOtbUVTrz
pBkuQXE+BRIgC2bzARZ8hKU7uUEshHGHRYq6BZkhbaG54czKrFvVHym1kmxKohSy
d5l1+AtFUaWpokyojgIG1hsvr6Sf1/m5KeBunU9RmlkwPSD98vzD3QKkKHggbDQh
8ltqze6pEFDWJkdYtPKpbObJ3Gu0dxjIibJiWWdiJDCm6Bu8hDJnWVAfclhsaOFg
y00SbkFfnDbWqGiFFWVAL2LkWZBsuuXGOStntrxt9vOWoBes+iZdX/MPSMm8Oy7H
9IB4LIltvhtnyyzn8sFfqfLXaotXr0+YlxZ4PhxxsTi9apJ4N2r5t4/6fOE7dNNh
nY77Uh7PYMXWgLAHPi8JcGP0wxiv8SlLh/9etpfbhew3gtnw+8qxuRyK3IMWZx0s
YvJAsk3NBQZVi1hh/xOOTLt/ezVy5iefKD8E/N26fnmFnhXlnaydx5pKpgorsegH
kNaUOsFFtc8QZRsB5H00MTw1eRhwmCREdPjJBobPKLHWeoHQfCWgx7j0mq7EtOrP
Syc7ScA=
=g1MT
-----END PGP PUBLIC KEY BLOCK-----
-------------- next part --------------
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQINBF4wBvsBEADQmcGbVUbDRUoXADReRmOOEMeydHghtKC9uRs9YNpGYZIB+bie
bGYZmflQayfh/wEpO2W/IZfGpHPL42V7SbyvqMjwNls/fnXsCtf4LRofNK8Qd9fN
kYargc9R7BEz/mwXKMiRQVx+DzkmqGWy2gq4iD0/mCyf5FdJCE40fOWoIGJXaOI1
Tz1vWqKwLS5T0dfmi9U4Tp/XsKOZGvN8oi5h0KmqFk7LEZr1MXarhi2Va86sgxsF
QcZEKfu5tgD0r00vXzikoSjn3qA5JW5FW07F1pGP4bF5f9J3CZbQyOjTSWMmmfTm
2d2BURWzaDiJN9twY2yjzkoOMuPdXXvovg7KxLcQerKT+FbKbq8DySJX2rnOA77k
UG4c9BGf/L1uBkAT8dpHLk6Uf5BfmypxUkydSWT1xfTDnw1MqxO0MsLlAHOR3J7c
oW9kLcOLuCQn1hBEwfZv7VSWBkGXSmKfp0LLIxAFgRtv+Dh+rcMMRdJgKr1V3FU+
rZ1+ZAfYiBpQJFPjv70vx+rGEgS801D3PJxBZUEy4Ic4ZYaKNhK9x9PRQuWcIBuW
6eTe/6lKWZeyxCumLLdiS75mF2oTcBaWeoc3QxrPRV15eDKeYJMbhnUai/7lSrhs
EWCkKR1RivgF4slYmtNE5ZPGZ/d61zjwn2xi4xNJVs8q9WRPMpHp0vCyMwARAQAB
tDFGZWRvcmEgKDMzKSA8ZmVkb3JhLTMzLXByaW1hcnlAZmVkb3JhcHJvamVjdC5v
cmc+iQI4BBMBAgAiBQJeMAb7AhsPBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAK
CRBJ/XdJlXD/MZm2D/9kriL43vd3+0DNMeA82n2v9mSR2PQqKny39xNlYPyy/1yZ
P/KXoa4NYSCA971LSd7lv4n/h5bEKgGHxZfttfOzOnWMVSSTfjRyM/df/NNzTUEV
7ORA5GW18g8PEtS7uRxVBf3cLvWu5q+8jmqES5HqTAdGVcuIFQeBXFN8Gy1Jinuz
AH8rJSdkUeZ0cehWbERq80BWM9dhad5dW+/+Gv0foFBvP15viwhWqajr8V0B8es+
2/tHI0k86FAujV5i0rrXl5UOoLilO57QQNDZH/qW9GsHwVI+2yecLstpUNLq+EZC
GqTZCYoxYRpl0gAMbDLztSL/8Bc0tJrCRG3tavJotFYlgUK60XnXlQzRkh9rgsfT
EXbQifWdQMMogzjCJr0hzJ+V1d0iozdUxB2ZEgTjukOvatkB77DY1FPZRkSFIQs+
fdcjazDIBLIxwJu5QwvTNW8lOLnJ46g4sf1WJoUdNTbR0BaC7HHj1inVWi0p7IuN
66EPGzJOSjLK+vW+J0ncPDEgLCV74RF/0nR5fVTdrmiopPrzFuguHf9S9gYI3Zun
Yl8FJUu4kRO6JPPTicUXWX+8XZmE94aK14RCJL23nOSi8T1eW8JLW43dCBRO8QUE
Aso1t2pypm/1zZexJdOV8yGME3g5l2W6PLgpz58DBECgqc/kda+VWgEAp7rO2A==
=EPL3
-----END PGP PUBLIC KEY BLOCK-----
From kloecker at kde.org Thu Apr 15 18:59:48 2021
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Thu, 15 Apr 2021 18:59:48 +0200
Subject: No key data exported by gpgme_op_export_keys()
In-Reply-To:
References:
Message-ID: <2259848.gzGyzVz9xI@breq>
On Donnerstag, 15. April 2021 16:30:12 CEST Dmitry Antipov via Gnupg-devel
wrote:
> Hello,
>
> could someone please explain why an attached test program (loosely based on
> gpgme tests) is able to echo back my test key but refuses to zero output
> bytes for Fedora 33 primary one?
I'm getting
1 key(s) found
read 0 bytes of key(s) data:
for both files. Are both keys in your actual public key ring?
My guess is that the export needs the actual key data and that's not part of
the result of the key list. The result of the key list only tells
gpgme_op_export_keys() which keys you want to export. gpgme_op_export_keys()
then calls gpg to retrieve the actual public key data. Obviously, this only
works for keys that are in your public key ring.
Try running your program with
GPGME_DEBUG=
with one of the debug levels in src/debug.h
Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL:
From dantipov at cloudlinux.com Thu Apr 15 19:28:53 2021
From: dantipov at cloudlinux.com (Dmitry Antipov)
Date: Thu, 15 Apr 2021 20:28:53 +0300
Subject: No key data exported by gpgme_op_export_keys()
In-Reply-To: <2259848.gzGyzVz9xI@breq>
References:
<2259848.gzGyzVz9xI@breq>
Message-ID: <4bee9a77-ffe9-b309-8de8-b95754b5f27d@cloudlinux.com>
On 4/15/21 7:59 PM, Ingo Kl?cker wrote:
> Are both keys in your actual public key ring?
$ gpg --list-packets < RPM-GPG-KEY-test
# off=0 ctb=99 tag=6 hlen=3 plen=525
:public key packet:
version 4, algo 1, created 1616661966, expires 0
pkey[0]: [4096 bits]
pkey[1]: [17 bits]
keyid: 1D66A1789477C523
# off=528 ctb=b4 tag=13 hlen=2 plen=38
:user ID packet: "CloudLinux, Inc. "
# off=568 ctb=89 tag=2 hlen=3 plen=596
:signature packet: algo 1, keyid 1D66A1789477C523
version 4, created 1616661966, md5len 0, sigclass 0x13
digest algo 8, begin of digest b6 63
hashed subpkt 33 len 21 (issuer fpr v4 10DFA0450487D8E6631738D41D66A1789477C523)
hashed subpkt 2 len 4 (sig created 2021-03-25)
hashed subpkt 27 len 1 (key flags: 01)
hashed subpkt 9 len 4 (key expires after 2y0d0h0m)
hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 2)
hashed subpkt 21 len 5 (pref-hash-algos: 10 9 8 11 2)
hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
hashed subpkt 30 len 1 (features: 01)
hashed subpkt 23 len 1 (keyserver preferences: 80)
subpkt 16 len 8 (issuer key ID 1D66A1789477C523)
data: [4095 bits]
# off=1167 ctb=b4 tag=13 hlen=2 plen=40
:user ID packet: "Dmitry Antipov "
# off=1209 ctb=89 tag=2 hlen=3 plen=596
:signature packet: algo 1, keyid 1D66A1789477C523
version 4, created 1616662046, md5len 0, sigclass 0x13
digest algo 8, begin of digest b7 7b
hashed subpkt 33 len 21 (issuer fpr v4 10DFA0450487D8E6631738D41D66A1789477C523)
hashed subpkt 2 len 4 (sig created 2021-03-25)
hashed subpkt 27 len 1 (key flags: 01)
hashed subpkt 9 len 4 (key expires after 2y0d0h0m)
hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 2)
hashed subpkt 21 len 5 (pref-hash-algos: 10 9 8 11 2)
hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
hashed subpkt 30 len 1 (features: 01)
hashed subpkt 23 len 1 (keyserver preferences: 80)
subpkt 16 len 8 (issuer key ID 1D66A1789477C523)
data: [4096 bits]
# off=1808 ctb=b9 tag=14 hlen=3 plen=397
:public sub key packet:
version 4, algo 1, created 1616662014, expires 0
pkey[0]: [3072 bits]
pkey[1]: [17 bits]
keyid: AAD128E49907EA1B
# off=2208 ctb=89 tag=2 hlen=3 plen=1010
:signature packet: algo 1, keyid 1D66A1789477C523
version 4, created 1616662014, md5len 0, sigclass 0x18
digest algo 8, begin of digest 8c ca
hashed subpkt 33 len 21 (issuer fpr v4 10DFA0450487D8E6631738D41D66A1789477C523)
hashed subpkt 2 len 4 (sig created 2021-03-25)
hashed subpkt 27 len 1 (key flags: 02)
hashed subpkt 9 len 4 (key expires after 2y0d0h0m)
subpkt 16 len 8 (issuer key ID 1D66A1789477C523)
subpkt 32 len 435 (signature: v4, class 0x19, algo 1, digest algo 8)
data: [4095 bits]
$ ./t-gpgme-import RPM-GPG-KEY-test
1 key(s) found
read 4443 bytes of key(s) data:
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQINBGBcTc4BEADF7NC6a5RPC0m6s6OXS4CEkkK6EKna7Vm9+dmSMWWuonZWQGH3
VG3Kd8GDymFHAAO8zBfm49XEt1qKi2tXghnsXKQVo4fj/vHCcGzzd3D62SFqkOr0
Q0DlNoNZGzht94ihmm095hegOLoQfyuFQ6wyn8ZK1Mg0dCgWwY5tq834FjMyeWJN
bweiQ+n/JvmOnM7ETO3p3vCXTPWdr/9i64CGbvnVDqhyl77TFj9GCPIvikKgePtq
Y0h9Rvh8F9jabzxE+vHNcLRQWjAqhs90gZK0ag78dXiPSt/lVmQ40GtScRqk8zgZ
csGfVqVOELUAVXbNOq1pBK36K5eNMrwHzPFNggIpxA2V2ccigfblghe7DnbqypxD
uXkf46lmAJBmPhBlH2O6dY61U6VGKA5RdULhrLvmAOfDhxLhXYHuAkcgbPSP0Udu
z3ECgaE+enaiJAPYIzEMBd4e4j8VxQzpXKrOLFt4wzO1mUJRuePpWyBO/DJPyia6
9WbeBLbJGCyHooyrSG8MxE6672ZSP9zbDEkDAO9Tx8V3mz3oJ32+6dl+ogxt0Bsy
umrLs7tlZZonlSBUkY9nuTlClTw7aCqkEbxFbBEBOsApkCOCVM5jT8gzouotCOcL
vtEyXwGKWf9zao2rbOpwG7JJwl0AC2AIw2yVvVgiXf4Bgh96NAogmrv41wARAQAB
tCZDbG91ZExpbnV4LCBJbmMuIDxpbmZvQGNsb3VkbGludXguY29tPokCVAQTAQgA
PhYhBBDfoEUEh9jmYxc41B1moXiUd8UjBQJgXE3OAhsBBQkDwmcABQsJCAcCBhUK
CQgLAgQWAgMBAh4BAheAAAoJEB1moXiUd8UjtmMP/26n9BaMLefvRsFYRIYIFQ6A
f8by+WNYgTZ3eAWq3jUuIAK5YzHUt6/ep8apYqAhAJa+lKsnGSnVCMyml4uByeN7
YtxzeJuTN6aUt2wc/y8zxj6TuQuisyO7CV7CroGd6wNX+8TARjHOL3ZfMDuBUege
v6cbPVLAj7G4sxj6gqG8NDWV9l+g9I+50D5v9eLd+cuM9QcdQSvckJAOBi37ITdK
1KDIWkiV45uSK9LoFWe6fcy6Y3FMw5IMxCpaYMcRr3ZUNCKvT+8Fltti/dRS8p9c
UKJdBQ36XffyoZ66HpOTOGBaAb91F6EnifrFsepY0SWsYiFnjUTQ1h082jPOBFB8
Yn4diPjB28BrOnWXcpdvfuOM5S5+06OCTn6rzvR3E0oyBn7ZAsdHqwTmHh8mPPxN
NGtmtScjOXhGfUDlHnEy5e2PbudFZKybTCnHMjKH3/OeZtDfZzPbxrPcidT2hvcj
ndTP5KoG6xuv44jK/a4SAFMQLb9bxCmqx8cAq34X2fB4+5Mf3AhSid6dbnw+4hdV
TJi2gpm33UJUhOWscKBJtUNW2lpivF0AO5Ov3QDCNjPEckbb7R+b/XcQB4PAqVk0
d9UQjbNAe6/KpWZc2VrNKRqv0zep75Uufd/NeZXCahuOcSyEuhVRVI6tFAE15fs3
qY5R5hL4uhtcTQ+fehNwtChEbWl0cnkgQW50aXBvdiA8ZGFudGlwb3ZAY2xvdWRs
aW51eC5jb20+iQJUBBMBCAA+FiEEEN+gRQSH2OZjFzjUHWaheJR3xSMFAmBcTh4C
GwEFCQPCZwAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQHWaheJR3xSO3exAA
iKfqKGyrIWLR9Nr7q1/Cxq2IuJJFtzJw+QZlBTSECQPPCzIHBjxaN8YaoUUn6odR
Hsr5tq5VYnLH78eSOzG72FFGbdUrXHA32ghSmMPlM7DIRZnB2tKb23UIQCn20U21
J7E2/YCSk3yxrJgGA55t6DXKLQ69K2c+2OYiJVv0CqNhVW9KhCAzwC/uHG7WqBiM
GTfnWJyziuxntDeuc0RYJE1pAeja0FwqsZdOT7YPPugrOyhOYqz/jum2oMePn3gz
U0bMFos+uP/3H6JDTBMtxyRgQOTu423dmQX9oDCkvMWXrdmB5VzZLtEMDotbjx4X
tQy38RBfvP7ngAlVcXXgW8kGVDQnTfhPLMWRMvczlCb6/esMJVih3ehAAo2XNfVK
QHAnEo5P8gtmX2R2d7C1I0TZhHeZZVhh9I/bm0PvpQmL/EMHpKv6Svn/2la6o1Pq
Yi3Ddeinba7EHzWJbSMOvZvfUBE+9eKR2G+t1xhu/NtiBFjc53ZXK6BKQ1tbRcAj
2p6xi3MksS6ZIy5qxQJwY3H4nVoSdAFSjM4as4NXtSwL8g88KNmhQg/6+8NQenYj
dtrFDNpmvjatP1YbAL62b7fT6hudzq+tQ9DBTMRJTj2fYVuR+JyMqWfEy8h6oWlF
dzsN8kj7e8x37tLLjjaRPHjui6ovNaW0Tu+bPjBwi0y5AY0EYFxN/gEMALT7wVFV
xbqa86e6puRATlVe2F7WfletD634s3jxS7QjW6ZY6pjVoU07lsBLMi0btdNwDijX
puql/9LjNYmRQtQZRC38V21jD/N8rETRkqVNeXv8g1z18G4FdVuU6wO1+oAYXU4y
waumo2WBwgTcPBl5hV10/LHDuqAqnRp2oOTNbXlCChLMiXiwVkjYbE5AjxqJxXSW
rpAmg33WPpxJSLX/eiVkdv4LVd9ywmetXaL2P6WaI/8Tac2aCyJ4YVqu1T7OoPoa
gLk0SDdnXMbKWydZ73sXoH+Axn7zh0CZURV1XvexQeML4zB4H3Lk6sX9uiV0u7B1
Bix+dovb/23zrvKHUah+yyaeZbM3850XOawf4D4QKE2pifwpzKCwbxlfmlUhoVhq
PiUwmQaDrAcqPsOy8KI5SzrtuTXRHKO3sGRk879g+oj2ua2XAg2l27DoJy18KiMM
l3PTQWer9uLFPPj4FUwEiVn9/4V9hx9pKcpm/7I8TpjlTOAfqU4rXsJIRwARAQAB
iQPyBBgBCAAmFiEEEN+gRQSH2OZjFzjUHWaheJR3xSMFAmBcTf4CGwIFCQPCZwAB
wAkQHWaheJR3xSPA9CAEGQEIAB0WIQRuOq6OcbjbnltBgjqq0SjkmQfqGwUCYFxN
/gAKCRCq0SjkmQfqG0l8C/9qZ0H2NlcQZwtUOr8bHe+dLiZEl61tS4laPVK3wK/S
TRHpwxGr0kf4tP3vbm4GL6LCFP8bIUdIany1Q6/q5ortD3BOsVISngduk8NWFF+A
2E9aG7OR8KV4YTzM2d/f/WFPdxbwcCddADjYJs+EPhqB2wDZ3LTMzAmjoi63DEuL
uRsUA1LlXwGFBJDEP4DTKVQXUIDuq2A8INIHcHmsi10KOpFDcxaqz5MOSZ27Aybf
PaHQ+GlRp/HBy07GfpLEsp7ZnyfY220IuMbRZ9Uv/pRqoHEwRzL4FkzaTGA8sb4o
5pM9OdcUKSu2Pv1AXg4XGyCT/+OQHcPh9W2OPmuQZwUskjElfCe34SgnrIYKg2dW
df+kkiA7GuyXkltwTn3QK8WlxmjfIdoKeVniOrn2sQPDq4u9R8/PsSqGcp5Adgm0
MbCT92ne80PEWyNlLg3jnJ2kEErfWefz+m21e8E1PIzh91/M9qA5kd35Y+ElUugk
FOyGtoqvNVwaJ2C8Zj7af1aMyg//QQU3dOZyeoKUMh4Ajkq+bq+57IOGaDJE76En
VY4NRnOP434Hej/Fv/1cZSJPUERmz8LvxK7uxw0OdxcObTCLmp6Tjtp5i275knB6
fp5ex1dcRVHte5UjIoOS6FA5zfjCoVjau/2wOiBXiKsIzgDzxzxGXuYiOtbUVTrz
pBkuQXE+BRIgC2bzARZ8hKU7uUEshHGHRYq6BZkhbaG54czKrFvVHym1kmxKohSy
d5l1+AtFUaWpokyojgIG1hsvr6Sf1/m5KeBunU9RmlkwPSD98vzD3QKkKHggbDQh
8ltqze6pEFDWJkdYtPKpbObJ3Gu0dxjIibJiWWdiJDCm6Bu8hDJnWVAfclhsaOFg
y00SbkFfnDbWqGiFFWVAL2LkWZBsuuXGOStntrxt9vOWoBes+iZdX/MPSMm8Oy7H
9IB4LIltvhtnyyzn8sFfqfLXaotXr0+YlxZ4PhxxsTi9apJ4N2r5t4/6fOE7dNNh
nY77Uh7PYMXWgLAHPi8JcGP0wxiv8SlLh/9etpfbhew3gtnw+8qxuRyK3IMWZx0s
YvJAsk3NBQZVi1hh/xOOTLt/ezVy5iefKD8E/N26fnmFnhXlnaydx5pKpgorsegH
kNaUOsFFtc8QZRsB5H00MTw1eRhwmCREdPjJBobPKLHWeoHQfCWgx7j0mq7EtOrP
Syc7ScA=
=g1MT
-----END PGP PUBLIC KEY BLOCK-----
$ gpg --list-packets < RPM-GPG-KEY-fedora-33-primary
# off=0 ctb=99 tag=6 hlen=3 plen=525
:public key packet:
version 4, algo 1, created 1580205819, expires 0
pkey[0]: [4096 bits]
pkey[1]: [17 bits]
keyid: 49FD77499570FF31
# off=528 ctb=b4 tag=13 hlen=2 plen=49
:user ID packet: "Fedora (33) "
# off=579 ctb=89 tag=2 hlen=3 plen=568
:signature packet: algo 1, keyid 49FD77499570FF31
version 4, created 1580205819, md5len 0, sigclass 0x13
digest algo 2, begin of digest 99 b6
hashed subpkt 2 len 4 (sig created 2020-01-28)
hashed subpkt 27 len 1 (key flags: 0F)
hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2)
hashed subpkt 21 len 5 (pref-hash-algos: 8 2 9 10 11)
hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
hashed subpkt 30 len 1 (features: 01)
hashed subpkt 23 len 1 (keyserver preferences: 80)
subpkt 16 len 8 (issuer key ID 49FD77499570FF31)
data: [4095 bits]
$ ./t-gpgme-import RPM-GPG-KEY-fedora-33-primary
1 key(s) found
read 0 bytes of key(s) data:
> My guess is that the export needs the actual key data and that's not part of
> the result of the key list. The result of the key list only tells
> gpgme_op_export_keys() which keys you want to export.
If so, it seems that the API is just designed to shoot yourself in the foot.
> Try running your program with
> GPGME_DEBUG=
> with one of the debug levels in src/debug.h
Thanks, will try it as well.
Dmitry
From kloecker at kde.org Thu Apr 15 21:50:32 2021
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Thu, 15 Apr 2021 21:50:32 +0200
Subject: No key data exported by gpgme_op_export_keys()
In-Reply-To: <4bee9a77-ffe9-b309-8de8-b95754b5f27d@cloudlinux.com>
References:
<2259848.gzGyzVz9xI@breq>
<4bee9a77-ffe9-b309-8de8-b95754b5f27d@cloudlinux.com>
Message-ID: <1768751.6KKhJiAXcZ@breq>
On Donnerstag, 15. April 2021 19:28:53 CEST Dmitry Antipov via Gnupg-devel
wrote:
> On 4/15/21 7:59 PM, Ingo Kl?cker wrote:
> > Are both keys in your actual public key ring?
You didn't answer my question. I bet
$ gpg -k 1D66A1789477C523
returns your key while
$ gpg -k 49FD77499570FF31
returns nothing because the Fedora key is not in your key ring.
> > My guess is that the export needs the actual key data and that's not part
> > of the result of the key list. The result of the key list only tells
> > gpgme_op_export_keys() which keys you want to export.
>
> If so, it seems that the API is just designed to shoot yourself in the foot.
It seems that you did not fully understand what
gpgme_op_keylist_from_data_start() (and friends) and gpgme_op_export_keys()
do.
If you check
https://www.gnupg.org/documentation/manuals/gpgme/Key-objects.html
then you will see that the gpgme_key_t structures returned by
gpgme_op_keylist_next() do not contain the actual public key data. Those
structures only contain information on the keys. In particular, they contain
their fingerprints which is then use by gpgme_op_export_keys() to know which
keys you want to export. The actual key data to export is then read from the
key ring.
I do agree that the documentation of gpgme_op_export_keys()
https://www.gnupg.org/documentation/manuals/gpgme/Exporting-Keys.html
is a bit misleading. I can see how "The keys to export are taken form the NULL
terminated array keys." can be misunderstood, but it says "The keys to export
[...]" and not "The key data to export [...]". It's like "The people to call
are taken from the list of contacts." A contact identifies a person (more or
less), but it certainly isn't the person.
Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL:
From dantipov at cloudlinux.com Fri Apr 16 06:51:16 2021
From: dantipov at cloudlinux.com (Dmitry Antipov)
Date: Fri, 16 Apr 2021 07:51:16 +0300
Subject: No key data exported by gpgme_op_export_keys()
In-Reply-To: <1768751.6KKhJiAXcZ@breq>
References:
<2259848.gzGyzVz9xI@breq>
<4bee9a77-ffe9-b309-8de8-b95754b5f27d@cloudlinux.com>
<1768751.6KKhJiAXcZ@breq>
Message-ID:
On 4/15/21 10:50 PM, Ingo Kl?cker wrote:
> You didn't answer my question. I bet
> $ gpg -k 1D66A1789477C523
> returns your key while
> $ gpg -k 49FD77499570FF31
> returns nothing because the Fedora key is not in your key ring.
Yes.
> It seems that you did not fully understand what
> gpgme_op_keylist_from_data_start() (and friends) and gpgme_op_export_keys()
> do.
Absolutely. I've expected that
err = gpgme_data_new_from_file (&in, argv[1], 1);
fail_if_err (err);
err = gpgme_op_keylist_from_data_start (ctx, in, 0);
fail_if_err (err);
uses data from file (i.e. argv[1]) to create a kind of key ring in CTX.
I'm calling (something which looks like and pretends to be) a library
function and so expecting a behavior of a library function - do something
with arguments and return the result. But the whole thing here looks
like a call to strcmp() which sends an e-mail to Microsoft.
Dmitry
From okigan at gmail.com Mon Apr 19 02:02:57 2021
From: okigan at gmail.com (Igor Okulist)
Date: Sun, 18 Apr 2021 17:02:57 -0700
Subject: [PATCH] ssh: update certificate support
Message-ID: <20210419000257.149867-1-okigan@gmail.com>
Following up on gpg-agent certificate support:
* updated the patches to single patch and rebased atop 2.3 release
* updated per prior feedback
* considering this as useful functionality as it allows for smoother workflow
Looking forward to feedback and comments.
visual diff: https://github.com/gpg/gnupg/compare/master...okigan:feature/tp-5487-on-latest?expand=1
CI build results: https://github.com/okigan/gnupg-workspace/runs/2376308761
GnuPG-bug-id: https://dev.gnupg.org/T1756
Signed-off-by: Igor Okulist
---
agent/agent.h | 3 +-
agent/command-ssh.c | 126 ++++++++++++++++++++++++++++++++++++++++----
agent/cvt-openpgp.c | 12 ++++-
agent/findkey.c | 47 ++++++++++++++---
4 files changed, 168 insertions(+), 20 deletions(-)
diff --git a/agent/agent.h b/agent/agent.h
index 064b7be74..19c8813d9 100644
--- a/agent/agent.h
+++ b/agent/agent.h
@@ -723,7 +723,8 @@ extract_private_key (gcry_sexp_t s_key, int req_private_key_data,
const char **r_algoname, int *r_npkey, int *r_nskey,
const char **r_format,
gcry_mpi_t *mpi_array, int arraysize,
- gcry_sexp_t *r_curve, gcry_sexp_t *r_flags);
+ gcry_sexp_t *r_curve, gcry_sexp_t *r_flags,
+ gcry_sexp_t *key_type);
/*-- sexp-secret.c --*/
gpg_error_t fixup_when_ecc_private_key (unsigned char *buf, size_t *buflen_p);
diff --git a/agent/command-ssh.c b/agent/command-ssh.c
index 73f98e9cd..83b4f2fa7 100644
--- a/agent/command-ssh.c
+++ b/agent/command-ssh.c
@@ -59,7 +59,7 @@
#include "../common/ssh-utils.h"
-
+
/* Request types. */
#define SSH_REQUEST_REQUEST_IDENTITIES 11
@@ -1943,11 +1943,39 @@ ssh_key_to_blob (gcry_sexp_t sexp, int with_secret,
}
else
{
+ gcry_sexp_t list = gcry_sexp_find_token (sexp, "key-type", 0);
+ size_t len = 0;
+ const char *key_type = gcry_sexp_nth_data (list, 1, &len);
+
+ if (key_type)
+ {
+ gcry_sexp_t certificate_sexp = gcry_sexp_find_token (sexp, "certificate", 0);
+ size_t certificate_sexp_b64_len = 0;
+ char *certificate_sexp_b64 = gcry_sexp_nth_buffer(certificate_sexp, 1, &certificate_sexp_b64_len);
+
+ struct b64state b64s = {};
+ long int certificate_len = 0;
+
+ if ((err = b64dec_start (&b64s, NULL)) ||
+ (err = b64dec_proc (&b64s, certificate_sexp_b64, certificate_sexp_b64_len, &certificate_len)) ||
+ (err = b64dec_finish (&b64s)) ||
+ (err = stream_write_data (stream, certificate_sexp_b64, certificate_len)))
+ {
+ xfree (certificate_sexp_b64);
+ goto out;
+ }
+
+ xfree (certificate_sexp_b64);
+ goto done;
+ }
+ else
+ {
/* Note: This is also used for EdDSA. */
err = stream_write_cstring (stream, key_spec.ssh_identifier);
if (err)
goto out;
}
+ }
/* Write the parameters. */
for (p_elems = elems; *p_elems; p_elems++)
@@ -1995,6 +2023,7 @@ ssh_key_to_blob (gcry_sexp_t sexp, int with_secret,
}
}
+done:
if (es_fclose_snatch (stream, &blob, &blob_size))
{
err = gpg_error_from_syserror ();
@@ -2014,7 +2043,6 @@ ssh_key_to_blob (gcry_sexp_t sexp, int with_secret,
return err;
}
-
/*
@@ -2078,19 +2106,19 @@ ssh_receive_key (estream_t stream, gcry_sexp_t *key_new, int secret,
if (err)
goto out;
+ unsigned char *cert_buffer = NULL;
+ u32 cert_buffer_len = 0;
+
if ((spec.flags & SPEC_FLAG_WITH_CERT))
{
/* This is an OpenSSH certificate+private key. The certificate
is an SSH string and which we store in an estream object. */
- unsigned char *buffer;
- u32 buflen;
char *cert_key_type;
- err = stream_read_string (stream, 0, &buffer, &buflen);
+ err = stream_read_string (stream, 0, &cert_buffer, &cert_buffer_len);
if (err)
goto out;
- cert = es_fopenmem_init (0, "rb", buffer, buflen);
- xfree (buffer);
+ cert = es_fopenmem_init (0, "rb", cert_buffer, cert_buffer_len);
if (!cert)
{
err = gpg_error_from_syserror ();
@@ -2238,8 +2266,61 @@ ssh_receive_key (estream_t stream, gcry_sexp_t *key_new, int secret,
goto out;
}
- err = sexp_key_construct (&key, spec, secret, curve_name, mpi_list,
- comment? comment:"");
+ if (0 == strcmp(spec.ssh_identifier, "ssh-rsa-cert-v01 at openssh.com"))
+ {
+ struct b64state b64s = {};
+ estream_t stream = NULL;
+ long int b64_cert_buffer_len = 0;
+
+ stream = es_fopenmem(0, "wt");
+ if ((err = b64enc_start_es (&b64s, stream, "")) ||
+ (err = b64enc_write (&b64s, cert_buffer, cert_buffer_len)) ||
+ (err = b64enc_finish (&b64s)))
+ {
+ goto out;
+ }
+
+ b64_cert_buffer_len = es_ftell (stream);
+
+ char *b64_cert_buffer = xtrymalloc (b64_cert_buffer_len + 1);
+ size_t nread = 0;
+
+ if ((err = es_fseek(stream, 0, SEEK_SET)) ||
+ (err = es_read (stream, b64_cert_buffer, b64_cert_buffer_len, &nread)))
+ {
+ goto out;
+ }
+
+ b64_cert_buffer[b64_cert_buffer_len] = '\0';
+ es_fclose (stream);
+
+ err = gcry_sexp_build (&key, NULL,
+ "(private-key "
+ " (rsa (n %m) (e %m) (d %m) (p %m) (q %m) (u %m) )"
+ " (comment %s)"
+ " (key-type %s)"
+ " (certificate %s)"
+ " )",
+ // 1 and 0 required swapped!
+ mpi_list[1], mpi_list[0], mpi_list[2], mpi_list[3], mpi_list[4], mpi_list[5],
+ comment!=NULL?comment:"",
+ spec.ssh_identifier,
+ b64_cert_buffer);
+
+ xfree(b64_cert_buffer);
+ b64_cert_buffer = NULL;
+
+ if (err)
+ goto out;
+ }
+ else
+ {
+ err = sexp_key_construct (&key, spec, secret, curve_name, mpi_list,
+ comment? comment:"");
+ if (err)
+ goto out;
+ }
+
if (!err)
{
if (key_spec)
@@ -2253,6 +2334,8 @@ ssh_receive_key (estream_t stream, gcry_sexp_t *key_new, int secret,
xfree (key_type);
xfree (comment);
+ xfree (cert_buffer);
+
return err;
}
@@ -2345,7 +2428,7 @@ ssh_read_key_public_from_blob (unsigned char *blob, size_t blob_size,
/* This function calculates the key grip for the key contained in the
S-Expression KEY and writes it to BUFFER, which must be large
- enough to hold it. Returns usual error code. */
+ enough to hold 20 characters. Returns usual error code. */
static gpg_error_t
ssh_key_grip (gcry_sexp_t key, unsigned char *buffer)
{
@@ -2355,6 +2438,29 @@ ssh_key_grip (gcry_sexp_t key, unsigned char *buffer)
return err? err : gpg_error (GPG_ERR_INTERNAL);
}
+ // if the key contains "key-type" update the gcry_pk_get_keygrip computed
+ // keygrip by the hashing it with key-type value
+ gcry_sexp_t list = NULL;
+ const char *data = NULL;
+ size_t data_len = 0;
+
+ list = gcry_sexp_find_token (key, "key-type", 0);
+ data = gcry_sexp_nth_data(list, 1, &data_len);
+
+ if (data)
+ {
+ gcry_md_hd_t md = NULL;
+ gcry_md_open (&md, GCRY_MD_SHA1, 0);
+
+ gcry_md_write (md, buffer, 20);
+ gcry_md_write (md, data, data_len);
+
+ memcpy (buffer, gcry_md_read (md, GCRY_MD_SHA1), 20);
+ gcry_md_close (md);
+ }
+
+ gcry_sexp_release(list);
+
return 0;
}
diff --git a/agent/cvt-openpgp.c b/agent/cvt-openpgp.c
index 3da553f95..36d8b91d0 100644
--- a/agent/cvt-openpgp.c
+++ b/agent/cvt-openpgp.c
@@ -1259,7 +1259,8 @@ extract_private_key (gcry_sexp_t s_key, int req_private_key_data,
const char **r_algoname, int *r_npkey, int *r_nskey,
const char **r_elems,
gcry_mpi_t *array, int arraysize,
- gcry_sexp_t *r_curve, gcry_sexp_t *r_flags)
+ gcry_sexp_t *r_curve, gcry_sexp_t *r_flags,
+ gcry_sexp_t *r_key_type)
{
gpg_error_t err;
gcry_sexp_t list, l2;
@@ -1268,6 +1269,7 @@ extract_private_key (gcry_sexp_t s_key, int req_private_key_data,
int npkey, nskey;
gcry_sexp_t curve = NULL;
gcry_sexp_t flags = NULL;
+ gcry_sexp_t key_type = NULL;
*r_curve = NULL;
*r_flags = NULL;
@@ -1289,6 +1291,8 @@ extract_private_key (gcry_sexp_t s_key, int req_private_key_data,
return gpg_error (GPG_ERR_BAD_SECKEY);
}
+ key_type = gcry_sexp_find_token (list, "key_type", 0);
+
l2 = gcry_sexp_cadr (list);
gcry_sexp_release (list);
list = l2;
@@ -1371,6 +1375,9 @@ extract_private_key (gcry_sexp_t s_key, int req_private_key_data,
*r_curve = curve;
*r_flags = flags;
+ if (r_key_type)
+ *r_key_type = key_type;
+
return 0;
}
}
@@ -1389,6 +1396,7 @@ convert_to_openpgp (ctrl_t ctrl, gcry_sexp_t s_key, const char *passphrase,
gcry_mpi_t array[10];
gcry_sexp_t curve = NULL;
gcry_sexp_t flags = NULL;
+ gcry_sexp_t key_name = NULL;
char protect_iv[16];
char salt[8];
unsigned long s2k_count;
@@ -1402,7 +1410,7 @@ convert_to_openpgp (ctrl_t ctrl, gcry_sexp_t s_key, const char *passphrase,
array[i] = NULL;
err = extract_private_key (s_key, 1, &algoname, &npkey, &nskey, NULL,
- array, DIM (array), &curve, &flags);
+ array, DIM (array), &curve, &flags, &key_name);
if (err)
return err;
diff --git a/agent/findkey.c b/agent/findkey.c
index 28ff61781..2b5830458 100644
--- a/agent/findkey.c
+++ b/agent/findkey.c
@@ -1192,14 +1192,14 @@ agent_public_key_from_file (ctrl_t ctrl,
gcry_mpi_t array[10];
gcry_sexp_t curve = NULL;
gcry_sexp_t flags = NULL;
- gcry_sexp_t uri_sexp, comment_sexp;
- const char *uri, *comment;
- size_t uri_length, comment_length;
- int uri_intlen, comment_intlen;
+ gcry_sexp_t uri_sexp, comment_sexp, key_type_sexp, certificate_sexp;
+ const char *uri, *comment, *key_type, *certificate;
+ size_t uri_length, comment_length, key_type_length, certificate_length;
+ int uri_intlen, comment_intlen, key_type_intlen, certificate_intlen;
membuf_t format_mb;
char *format;
- void *args[2+7+2+2+1]; /* Size is 2 + max. # of elements + 2 for uri + 2
- for comment + end-of-list. */
+ void *args[2+7+2+2+2+1]; /* Size is 2 + max. # of elements + 2 for uri + 2
+ for comment + key_type + certificate + end-of-list. */
int argidx;
gcry_sexp_t list = NULL;
const char *s;
@@ -1216,7 +1216,7 @@ agent_public_key_from_file (ctrl_t ctrl,
array[i] = NULL;
err = extract_private_key (s_skey, 0, &algoname, &npkey, NULL, &elems,
- array, DIM (array), &curve, &flags);
+ array, DIM (array), &curve, &flags, &key_type_sexp);
if (err)
{
gcry_sexp_release (s_skey);
@@ -1235,6 +1235,19 @@ agent_public_key_from_file (ctrl_t ctrl,
if (comment_sexp)
comment = gcry_sexp_nth_data (comment_sexp, 1, &comment_length);
+ key_type = NULL;
+ key_type_length = 0;
+ key_type_sexp = gcry_sexp_find_token (s_skey, "key-type", 0);
+ if (key_type_sexp)
+ key_type = gcry_sexp_nth_data (key_type_sexp, 1, &key_type_length);
+
+ certificate = NULL;
+ certificate_length = 0;
+ certificate_sexp = gcry_sexp_find_token (s_skey, "certificate", 0);
+ if (certificate_sexp)
+ certificate = gcry_sexp_nth_data (certificate_sexp, 1, &certificate_length);
+
+
gcry_sexp_release (s_skey);
s_skey = NULL;
@@ -1253,6 +1266,26 @@ agent_public_key_from_file (ctrl_t ctrl,
args[argidx++] = &array[idx];
}
put_membuf_str (&format_mb, ")");
+
+ if (key_type)
+ {
+ key_type_intlen = (int)key_type_length;
+ put_membuf_str (&format_mb, "(key-type %b)");
+ log_assert (argidx+1 < DIM (args));
+ args[argidx++] = (void *)&key_type_intlen;
+ log_assert (argidx+1 < DIM (args));
+ args[argidx++] = (void*)&key_type;
+ }
+ if (certificate)
+ {
+ certificate_intlen = (int)certificate_length;
+ put_membuf_str (&format_mb, "(certificate %b)");
+ log_assert (argidx+1 < DIM (args));
+ args[argidx++] = (void *)&certificate_intlen;
+ log_assert (argidx+1 < DIM (args));
+ args[argidx++] = (void*)&certificate;
+ }
+
if (uri)
{
put_membuf_str (&format_mb, "(uri %b)");
--
2.30.2
From wk at gnupg.org Mon Apr 19 13:14:36 2021
From: wk at gnupg.org (Werner Koch)
Date: Mon, 19 Apr 2021 13:14:36 +0200
Subject: [PATCH] ssh: update certificate support
In-Reply-To: <20210419000257.149867-1-okigan@gmail.com> (Igor Okulist via
Gnupg-devel's message of "Sun, 18 Apr 2021 17:02:57 -0700")
References: <20210419000257.149867-1-okigan@gmail.com>
Message-ID: <875z0ile5f.fsf@wheatstone.g10code.de>
On Sun, 18 Apr 2021 17:02, Igor Okulist said:
> + if (0 == strcmp(spec.ssh_identifier, "ssh-rsa-cert-v01 at openssh.com"))
Don't do this. Use this pattern:
if (!strcmp(spec.ssh_identifier, "ssh-rsa-cert-v01 at openssh.com"))
> + "(private-key "
> + " (rsa (n %m) (e %m) (d %m) (p %m) (q %m) (u %m) )"
> + " (comment %s)"
> + " (key-type %s)"
> + " (certificate %s)"
That is never going to fly. The "certificate" and other new items are
nothing we want as the part of a private key. See keyformat.txt on how
to add meta information to a key.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL:
From wk at gnupg.org Mon Apr 19 13:17:50 2021
From: wk at gnupg.org (Werner Koch)
Date: Mon, 19 Apr 2021 13:17:50 +0200
Subject: [PATCH gnupg] wks-client: Allow use with the keybox daemon.
In-Reply-To: <20210411120640.17532-1-dgouttegattat@incenp.org> (Damien
Goutte-Gattat via Gnupg-devel's message of "Sun, 11 Apr 2021 13:06:40
+0100")
References: <20210411120640.17532-1-dgouttegattat@incenp.org>
Message-ID: <871rb6le01.fsf@wheatstone.g10code.de>
Hi!
I got another solution to this. use-keyboxd is now an option for the
new common.conf file. The existing use-keyboxd options will be kept for
the next release but print a diagnostic.
The common.conf is always read even if gpg is called with --no-options
so things should now work automagically. See
gnupg/doc/example/common.conf.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL:
From wk at gnupg.org Mon Apr 19 13:19:29 2021
From: wk at gnupg.org (Werner Koch)
Date: Mon, 19 Apr 2021 13:19:29 +0200
Subject: [PATCH gnupg] gpg: Fix showpref to list AEAD feature.
In-Reply-To: <20210412111748.21059-1-dgouttegattat@incenp.org> (Damien
Goutte-Gattat via Gnupg-devel's message of "Mon, 12 Apr 2021 12:17:48
+0100")
References: <20210412111748.21059-1-dgouttegattat@incenp.org>
Message-ID: <87wnsyjzcu.fsf@wheatstone.g10code.de>
Thanks,
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL:
From gniibe at fsij.org Tue Apr 20 04:24:46 2021
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 20 Apr 2021 11:24:46 +0900
Subject: [PATCH] ssh: update certificate support
In-Reply-To: <20210419000257.149867-1-okigan@gmail.com>
References: <20210419000257.149867-1-okigan@gmail.com>
Message-ID: <874kg14rrl.fsf@iwagami.gniibe.org>
Igor Okulist wrote:
> Following up on gpg-agent certificate support:
>
> * updated the patches to single patch and rebased atop 2.3 release
> * updated per prior feedback
> * considering this as useful functionality as it allows for smoother workflow
>
> Looking forward to feedback and comments.
Sorry for my miscommunication. Finally, I realized that OpenSSH newer
versions behave differently. (It were good if you had addressed that
directly.)
I tried to understand your shell script. The problem can be worked
around when we use -k option for ssh-add and -i option with certificate
for ssh. That recovers the old behaviour of ssh-add/ssh (of older
versions of OpenSSH); With the -k option, ssh-add does not send
certificates to ssh-agent. With -i option plus path to certificate, ssh
handles the certificate by itself (when asked by remote sshd) and only
asks ssh-agent for signing.
IIUC, the purpose of your patch is to make ssh-emulation of gpg-agent
behave just like original ssh-agent does. To support this feature (if
it's worth to support), we need to enhance the file format of the
private key. In the source code, gnupg/agent/keyformat.txt suggested
use of "OpenSSH-cert" field.
But, in my opinion, I'm not that positive to this approach.
I think that good points will be:
* ssh-agent emulation of gpg-agent will be more compatible.
* we will be able to remove the certificate file under .ssh.
And it would be also good if gpg frontend can support making SSH
certificate (the work ssh-keygen does) by signing SSH CA key.
I'm afraid that adding more feature (like handling certificate, public
part of data) to gpg-agent and adding more data to the private key file
are against the design philosophy... making gpg-agent as small as
possible, focusing on private key operations.
--
From wk at gnupg.org Tue Apr 20 15:27:47 2021
From: wk at gnupg.org (Werner Koch)
Date: Tue, 20 Apr 2021 15:27:47 +0200
Subject: [Announce] GnuPG 2.3.1 released
Message-ID: <87im4hjdbg.fsf@wheatstone.g10code.de>
Hello!
We are pleased to announce the availability of a new GnuPG release:
version 2.3.1. This is the second release in the new 2.3 series which
fixes a couple of bugs and adds a few new things. See below for details.
Although some bugs might linger in the 2.3 versions, they are intended
to replace the 2.2 series. 2.3 may even be used for production purposes
if either the risk of minor regressions is acceptable or the new
features are important.
What is GnuPG
=============
The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation
of the OpenPGP and S/MIME standards.
GnuPG allows to encrypt and sign data and communication, features a
versatile key management system as well as access modules for public key
directories. GnuPG itself is a command line tool with features for easy
integration with other applications. The separate library GPGME provides
a uniform API to use the GnuPG engine by software written in common
programming languages. A wealth of frontend applications and libraries
making use of GnuPG are available. As an universal crypto engine GnuPG
provides support for S/MIME and Secure Shell in addition to OpenPGP.
GnuPG is Free Software (meaning that it respects your freedom). It can
be freely used, modified and distributed under the terms of the GNU
General Public License.
Three different versions of GnuPG are actively maintained:
- This version (2.3) is the latest development with a lot of new
features. This announcement is about the first release of this
version.
- Version 2.2 is our LTS (long term support) version and guaranteed to
be maintained at least until the end of 2024.
See https://gnupg.org/download/index.html#end-of-life
- Version 1.4 is maintained to allow decryption of very old data which
is, for security reasons, not anymore possible with other GnuPG
versions.
Noteworthy changes in version 2.3.1
===================================
* The new configuration file common.conf is now used to enable the
use of the key database daemon with "use-keyboxd". Using this
option in gpg.conf and gpgsm.conf is supported for a transitional
period. See doc/example/common.conf for more.
* gpg: Force version 5 key creation for ed448 and cv448 algorithms.
* gpg: By default do not use the self-sigs-only option when
importing from an LDAP keyserver. [#5387]
* gpg: Lookup a missing public key of the active card via LDAP.
[d7e707170f]
* gpgsm: New command --show-certs. [51419d6341]
* scd: Fix CCID driver for SCM SPR332/SPR532. [#5297]
* scd: Further improvements for PKCS#15 cards.
* Fix build problems on Fedora. [#5389]
* Fix build problems on macOS. [#5400]
* New configure option --with-tss to allow the selection of the TSS
library. [93c88d0af3]
Release-info: https://dev.gnupg.org/T5386
Getting the Software
====================
Please follow the instructions found at or
read on:
GnuPG may be downloaded from one of the GnuPG mirror sites or direct
from its primary FTP server. The list of mirrors can be found at
. Note that GnuPG is not
available at ftp.gnu.org.
The GnuPG source code compressed using BZIP2 and its OpenPGP signature
are available here:
https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.3.1.tar.bz2 (7392k)
https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.3.1.tar.bz2.sig
An installer for Windows without any graphical frontend except for a
very minimal Pinentry tool is available here:
https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.3.1_20210420.exe (4570k)
https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.3.1_20210420.exe.sig
The source used to build the Windows installer can be found in the same
directory with a ".tar.xz" suffix.
A new version of Gpg4win featuring this version of GnuPG will be
released soon. In the meantime it is possible to install this GnuPG
version on top of Gpg4win 3.1.15.
Checking the Integrity
======================
In order to check that the version of GnuPG which you are going to
install is an original and unmodified one, you can do it in one of
the following ways:
* If you already have a version of GnuPG installed, you can simply
verify the supplied signature. For example to verify the signature
of the file gnupg-2.3.1.tar.bz2 you would use this command:
gpg --verify gnupg-2.3.1.tar.bz2.sig gnupg-2.3.1.tar.bz2
This checks whether the signature file matches the source file.
You should see a message indicating that the signature is good and
made by one or more of the release signing keys. Make sure that
this is a valid key, either by matching the shown fingerprint
against a trustworthy list of valid release signing keys or by
checking that the key has been signed by trustworthy other keys.
See the end of this mail for information on the signing keys.
* If you are not able to use an existing version of GnuPG, you have
to verify the SHA-1 checksum. On Unix systems the command to do
this is either "sha1sum" or "shasum". Assuming you downloaded the
file gnupg-2.3.1.tar.bz2, you run the command like this:
sha1sum gnupg-2.3.1.tar.bz2
and check that the output matches the next line:
a8f66ba4f7dcb2e7322aef786f942ce5ccca6f14 gnupg-2.3.1.tar.bz2
8e81d5592b0f3c88c3b5c9928ec4bc50e811357b gnupg-w32-2.3.1_20210420.tar.xz
af13b1620c234dd6124531ad2698827caaaa6287 gnupg-w32-2.3.1_20210420.exe
Internationalization
====================
This version of GnuPG has support for 26 languages with Chinese
(traditional and simplified), Czech, French, German, Italian,
Japanese, Norwegian, Polish, Russian, and Ukrainian being almost
completely translated.
Documentation and Support
=========================
The file gnupg.info has the complete reference manual of the system.
Separate man pages are included as well but they miss some of the
details available only in the manual. The manual is also available
online at
https://gnupg.org/documentation/manuals/gnupg/
or can be downloaded as PDF at
https://gnupg.org/documentation/manuals/gnupg.pdf
You may also want to search the GnuPG mailing list archives or ask on
the gnupg-users mailing list for advise on how to solve problems. Most
of the new features are around for several years and thus enough public
experience is available. https://wiki.gnupg.org has user contributed
information around GnuPG and relate software.
In case of build problems specific to this release please first check
https://dev.gnupg.org/T5405 for updated information.
Please consult the archive of the gnupg-users mailing list before
reporting a bug: https://gnupg.org/documentation/mailing-lists.html.
We suggest to send bug reports for a new release to this list in favor
of filing a bug at https://bugs.gnupg.org. If you need commercial
support go to https://gnupg.com or https://gnupg.org/service.html.
If you are a developer and you need a certain feature for your project,
please do not hesitate to bring it to the gnupg-devel mailing list for
discussion.
Thanks
======
Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH
and still mostly financed by donations. Three full-time employed
developers as well as two contractors exclusively work on GnuPG and
closely related software like Libgcrypt, GPGME and Gpg4win.
We like to thank all the nice people who are helping the GnuPG project,
be it testing, coding, translating, suggesting, auditing, administering
the servers, spreading the word, or answering questions on the mailing
lists.
The financial support of the governmental CERT of Luxembourg
(GOVCERT.LU) allowed us to develop new and improved features for
smartcards (Yubikey, PIV and Scute) as well as various usability
features. Thanks.
Many thanks also to all other financial supporters, both corporate and
individuals. Without you it would not be possible to keep GnuPG in a
good and secure shape and to address all the small and larger requests
made by our users.
Happy hacking,
Your GnuPG hackers
p.s.
This is an announcement only mailing list. Please send replies only to
the gnupg-users at gnupg.org mailing list.
p.p.s
List of Release Signing Keys:
To guarantee that a downloaded GnuPG version has not been tampered by
malicious entities we provide signature files for all tarballs and
binary versions. The keys are also signed by the long term keys of
their respective owners. Current releases are signed by one or more
of these four keys:
ed25519 2020-08-24 [expires: 2030-06-30]
Key fingerprint = 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA
Werner Koch (dist signing 2020)
rsa3072 2017-03-17 [expires: 2027-03-15]
Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28
Andre Heinecke (Release Signing Key)
rsa2048 2011-01-12 [expires: 2021-12-31]
Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6
Werner Koch (dist sig)
The keys are available at https://gnupg.org/signature_key.html and
in any recently released GnuPG tarball in the file g10/distsigkey.gpg .
Note that this mail has been signed by a different key.
--
"If privacy is outlawed, only outlaws will have privacy."
- PRZ 1991
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL:
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce
From okigan at gmail.com Wed Apr 21 02:15:00 2021
From: okigan at gmail.com (Igor Okulist)
Date: Tue, 20 Apr 2021 17:15:00 -0700
Subject: [PATCH] ssh: update certificate support
In-Reply-To: <875z0ile5f.fsf@wheatstone.g10code.de>
References: <20210419000257.149867-1-okigan@gmail.com>
<875z0ile5f.fsf@wheatstone.g10code.de>
Message-ID:
On Mon, Apr 19, 2021 at 4:15 AM Werner Koch wrote:
>
> On Sun, 18 Apr 2021 17:02, Igor Okulist said:
> > + if (0 == strcmp(spec.ssh_identifier, "ssh-rsa-cert-v01 at openssh.com"))
>
> Don't do this. Use this pattern:
>
> if (!strcmp(spec.ssh_identifier, "ssh-rsa-cert-v01 at openssh.com"))
>
IO: Noted, will change
> > + "(private-key "
> > + " (rsa (n %m) (e %m) (d %m) (p %m) (q %m) (u %m) )"
> > + " (comment %s)"
> > + " (key-type %s)"
> > + " (certificate %s)"
>
> That is never going to fly. The "certificate" and other new items are
> nothing we want as the part of a private key. See keyformat.txt on how
> to add meta information to a key.
IO: the reason for this approach is that the "meta information" needs
to be passed
IO: through multiple layers, so even if it would be saved in separate
field it seem it would
IO: be very extensive changes to pass such "meta information" through
the system.
IO: For example, if the comment was saved as such "meta information"
would we need to change
IO: all signatures of all functions passing the key to pass the
comment along? Is there or is there another way?
>
>
> Shalom-Salam,
>
> Werner
>
>
> --
> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From kirelagin at gmail.com Mon Apr 26 04:58:15 2021
From: kirelagin at gmail.com (Kirill Elagin)
Date: Sun, 25 Apr 2021 22:58:15 -0400
Subject: [PATCH gnupg] scd: Fix unblock (via a Reset Code) with KDF
In-Reply-To: <20210426025523.30172-1-kirelagin@gmail.com>
References: <20210426025523.30172-1-kirelagin@gmail.com>
Message-ID:
Please, note that I did not test this change and did it pretty much blindly.
Additionally, I think it would be important to back-port it to 2.2.
Cheers,
Kirill
On Sun, Apr 25, 2021 at 10:55 PM Kirill Elagin wrote:
>
> * scd/app-openpgp.c (do_change_pin): Fix unblock with KDF
> --
>
> When KDF is enabled, instead of sending PIN verbatim we send its salted
> hash. User PIN, Admin PIN, and Reset Code all use different salts.
> When executing the `unblock` command (that allows the user to reset
> their PIN using the Reset Code) we were incorrectly using salt number 0
> (the one used for the Reset Code) to hash the User PIN.
>
> Use the correct salt number 1 instead.
>
> This bug was present since the original implementation of KDF back in
> 91303b7df9c3e810cfcd4920f78bac6f8b7df2b2.
> ---
> scd/app-openpgp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c
> index 5508ec68e..506b58232 100644
> --- a/scd/app-openpgp.c
> +++ b/scd/app-openpgp.c
> @@ -3454,7 +3454,7 @@ do_change_pin (app_t app, ctrl_t ctrl, const char *chvnostr,
>
> rc = pin2hash_if_kdf (app, 0, resetcode, &result1, &resultlen1);
> if (!rc)
> - rc = pin2hash_if_kdf (app, 0, pinvalue, &result2, &resultlen2);
> + rc = pin2hash_if_kdf (app, 1, pinvalue, &result2, &resultlen2);
> if (!rc)
> {
> bufferlen = resultlen1 + resultlen2;
> --
> 2.29.3
>
From kirelagin at gmail.com Mon Apr 26 04:55:23 2021
From: kirelagin at gmail.com (Kirill Elagin)
Date: Sun, 25 Apr 2021 22:55:23 -0400
Subject: [PATCH gnupg] scd: Fix unblock (via a Reset Code) with KDF
Message-ID: <20210426025523.30172-1-kirelagin@gmail.com>
* scd/app-openpgp.c (do_change_pin): Fix unblock with KDF
--
When KDF is enabled, instead of sending PIN verbatim we send its salted
hash. User PIN, Admin PIN, and Reset Code all use different salts.
When executing the `unblock` command (that allows the user to reset
their PIN using the Reset Code) we were incorrectly using salt number 0
(the one used for the Reset Code) to hash the User PIN.
Use the correct salt number 1 instead.
This bug was present since the original implementation of KDF back in
91303b7df9c3e810cfcd4920f78bac6f8b7df2b2.
---
scd/app-openpgp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c
index 5508ec68e..506b58232 100644
--- a/scd/app-openpgp.c
+++ b/scd/app-openpgp.c
@@ -3454,7 +3454,7 @@ do_change_pin (app_t app, ctrl_t ctrl, const char *chvnostr,
rc = pin2hash_if_kdf (app, 0, resetcode, &result1, &resultlen1);
if (!rc)
- rc = pin2hash_if_kdf (app, 0, pinvalue, &result2, &resultlen2);
+ rc = pin2hash_if_kdf (app, 1, pinvalue, &result2, &resultlen2);
if (!rc)
{
bufferlen = resultlen1 + resultlen2;
--
2.29.3
From gniibe at fsij.org Tue Apr 27 13:49:00 2021
From: gniibe at fsij.org (Niibe Yutaka)
Date: Tue, 27 Apr 2021 20:49:00 +0900
Subject: [PATCH gnupg] scd: Fix unblock (via a Reset Code) with KDF
In-Reply-To:
References: <20210426025523.30172-1-kirelagin@gmail.com>
Message-ID: <87wnsorlqr.fsf@jumper.gniibe.org>
Hello,
Thank you for the patch. It's pushed to master. Tracked as T5413.
Kirill Elagin wrote:
> Additionally, I think it would be important to back-port it to 2.2.
Yes, I'll do.
--
From ericonr at disroot.org Tue Apr 27 17:02:17 2021
From: ericonr at disroot.org (=?UTF-8?q?=C3=89rico=20Nogueira?=)
Date: Tue, 27 Apr 2021 12:02:17 -0300
Subject: [PATCH libgpg-error] build: Restore support for cross building to
musl targets.
In-Reply-To: <20210427150217.28452-1-ericonr@disroot.org>
References: <20210427150217.28452-1-ericonr@disroot.org>
Message-ID: <20210427150217.28452-2-ericonr@disroot.org>
From: ?rico Nogueira
* configure.ac: Loosen the condition of using gen-lock-obj.sh for
Linux. Commit 1fb90a7da186ee2ee098a666f6f3a35bb1720e59 tightened this
check, but the objdump+awk trick used here works with musl toolchains
as well as it does with glibc ones. Furthermore, uClibc targets that
have pthreads available can also take advantage of it.
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 53a343b..7b66133 100644
--- a/configure.ac
+++ b/configure.ac
@@ -603,7 +603,7 @@ if test x"$gl_use_threads" = xno; then
AC_MSG_NOTICE([generated src/lock-obj-pub.native.h for $host])
elif test x$cross_compiling = xyes; then
case $host in
- *-*-linux-gnu*)
+ *-*-linux*)
AC_CHECK_TOOL(OBJDUMP, [objdump])
if test -n "$OBJDUMP"; then
lock_obj_h_generated=yes
--
2.31.1
From ericonr at disroot.org Tue Apr 27 17:02:16 2021
From: ericonr at disroot.org (=?UTF-8?q?=C3=89rico=20Nogueira?=)
Date: Tue, 27 Apr 2021 12:02:16 -0300
Subject: [PATCH libgpg-error] build: Be more consistent with memory management.
Message-ID: <20210427150217.28452-1-ericonr@disroot.org>
From: ?rico Nogueira
* src/mkheader.c: remove xfree wrapper (free(NULL) is well-defined),
use xmalloc instead of malloc+check return value, use macros to block
malloc and strdup from being used in the program.
---
src/mkheader.c | 35 +++++++++--------------------------
1 file changed, 9 insertions(+), 26 deletions(-)
diff --git a/src/mkheader.c b/src/mkheader.c
index 1d2ea20..995f95f 100644
--- a/src/mkheader.c
+++ b/src/mkheader.c
@@ -41,16 +41,7 @@ static int use_posix_threads;
static int stdint_h_included;
static int sys_types_h_included;
-
-/* The usual free wrapper. */
-static void
-xfree (void *a)
-{
- if (a)
- free (a);
-}
-
-
+/* Malloc wrappers. */
static char *
xmalloc (size_t n)
{
@@ -77,6 +68,9 @@ xstrdup (const char *string)
return p;
}
+/* Protect from using raw malloc or strdup in rest of file. */
+#define malloc undef
+#define strdup undef
/* Return a malloced string with TRIPLET. If TRIPLET has an alias
* return that instead. In general build-aux/config.sub should do the
@@ -161,7 +155,7 @@ canon_host_triplet (const char *triplet, int no_vendor_hack, char **r_os)
}
*p = 0;
result = canon_host_triplet (buf, 1, NULL);
- xfree (buf);
+ free (buf);
goto leave;
}
@@ -233,7 +227,7 @@ parse_config_h (const char *fname)
p1 = strtok (NULL, "\"");
if (!*p1)
continue; /* oops */
- xfree (replacement_for_off_type);
+ free (replacement_for_off_type);
replacement_for_off_type = xstrdup (p1);
}
else if (!strcmp (p1, "USE_POSIX_THREADS"))
@@ -364,14 +358,8 @@ mk_include_name (const char *name, const char *repl)
char *incfname, *p;
const char *s;
- incfname = malloc (strlen (srcdir) + strlen (name)
+ incfname = xmalloc (strlen (srcdir) + strlen (name)
+ (repl?strlen (repl):0) + 1);
- if (!incfname)
- {
- fputs (PGM ": out of core\n", stderr);
- exit (1);
- }
-
if (*name == '.' && name[1] == '/')
*incfname = 0;
else
@@ -676,12 +664,7 @@ main (int argc, char **argv)
host_triplet = canon_host_triplet (host_triplet_raw, 0, &host_os);
- srcdir = malloc (strlen (fname) + 2 + 1);
- if (!srcdir)
- {
- fputs (PGM ": out of core\n", stderr);
- return 1;
- }
+ srcdir = xmalloc (strlen (fname) + 2 + 1);
strcpy (srcdir, fname);
p1 = strrchr (srcdir, '/');
if (p1)
@@ -775,6 +758,6 @@ main (int argc, char **argv)
if (fp)
fclose (fp);
- xfree (host_triplet);
+ free (host_triplet);
return 0;
}
--
2.31.1
From ericonr at disroot.org Tue Apr 27 16:41:17 2021
From: ericonr at disroot.org (=?UTF-8?q?=C3=89rico=20Nogueira?=)
Date: Tue, 27 Apr 2021 11:41:17 -0300
Subject: [PATCH libgpg-error] build: Be more consistent with memory management.
Message-ID: <20210427144117.14753-1-ericonr@disroot.org>
From: ?rico Nogueira
* src/mkheader.c: remove xfree wrapper (free(NULL) is well-defined),
use xmalloc instead of malloc+check return value, use macros to block
malloc and strdup from being used in the program.
---
src/mkheader.c | 35 +++++++++--------------------------
1 file changed, 9 insertions(+), 26 deletions(-)
diff --git a/src/mkheader.c b/src/mkheader.c
index 1d2ea20..995f95f 100644
--- a/src/mkheader.c
+++ b/src/mkheader.c
@@ -41,16 +41,7 @@ static int use_posix_threads;
static int stdint_h_included;
static int sys_types_h_included;
-
-/* The usual free wrapper. */
-static void
-xfree (void *a)
-{
- if (a)
- free (a);
-}
-
-
+/* Malloc wrappers. */
static char *
xmalloc (size_t n)
{
@@ -77,6 +68,9 @@ xstrdup (const char *string)
return p;
}
+/* Protect from using raw malloc or strdup in rest of file. */
+#define malloc undef
+#define strdup undef
/* Return a malloced string with TRIPLET. If TRIPLET has an alias
* return that instead. In general build-aux/config.sub should do the
@@ -161,7 +155,7 @@ canon_host_triplet (const char *triplet, int no_vendor_hack, char **r_os)
}
*p = 0;
result = canon_host_triplet (buf, 1, NULL);
- xfree (buf);
+ free (buf);
goto leave;
}
@@ -233,7 +227,7 @@ parse_config_h (const char *fname)
p1 = strtok (NULL, "\"");
if (!*p1)
continue; /* oops */
- xfree (replacement_for_off_type);
+ free (replacement_for_off_type);
replacement_for_off_type = xstrdup (p1);
}
else if (!strcmp (p1, "USE_POSIX_THREADS"))
@@ -364,14 +358,8 @@ mk_include_name (const char *name, const char *repl)
char *incfname, *p;
const char *s;
- incfname = malloc (strlen (srcdir) + strlen (name)
+ incfname = xmalloc (strlen (srcdir) + strlen (name)
+ (repl?strlen (repl):0) + 1);
- if (!incfname)
- {
- fputs (PGM ": out of core\n", stderr);
- exit (1);
- }
-
if (*name == '.' && name[1] == '/')
*incfname = 0;
else
@@ -676,12 +664,7 @@ main (int argc, char **argv)
host_triplet = canon_host_triplet (host_triplet_raw, 0, &host_os);
- srcdir = malloc (strlen (fname) + 2 + 1);
- if (!srcdir)
- {
- fputs (PGM ": out of core\n", stderr);
- return 1;
- }
+ srcdir = xmalloc (strlen (fname) + 2 + 1);
strcpy (srcdir, fname);
p1 = strrchr (srcdir, '/');
if (p1)
@@ -775,6 +758,6 @@ main (int argc, char **argv)
if (fp)
fclose (fp);
- xfree (host_triplet);
+ free (host_triplet);
return 0;
}
--
2.31.1
From ericonr at disroot.org Tue Apr 27 16:52:45 2021
From: ericonr at disroot.org (=?UTF-8?q?=C3=89rico=20Nogueira?=)
Date: Tue, 27 Apr 2021 11:52:45 -0300
Subject: [PATCH libgpg-error] build: Restore support for cross building to
musl targets.
Message-ID: <20210427145245.21864-1-ericonr@disroot.org>
From: ?rico Nogueira
* configure.ac: Loosen the condition of using gen-lock-obj.sh for
Linux. Commit 1fb90a7da186ee2ee098a666f6f3a35bb1720e59 tightened this
check, but the objdump+awk trick used here works with musl toolchains
as well as it does with glibc ones. Furthermore, uClibc targets that
have pthreads available can also take advantage of it.
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 53a343b..7b66133 100644
--- a/configure.ac
+++ b/configure.ac
@@ -603,7 +603,7 @@ if test x"$gl_use_threads" = xno; then
AC_MSG_NOTICE([generated src/lock-obj-pub.native.h for $host])
elif test x$cross_compiling = xyes; then
case $host in
- *-*-linux-gnu*)
+ *-*-linux*)
AC_CHECK_TOOL(OBJDUMP, [objdump])
if test -n "$OBJDUMP"; then
lock_obj_h_generated=yes
--
2.31.1
From wk at gnupg.org Tue Apr 27 20:34:35 2021
From: wk at gnupg.org (Werner Koch)
Date: Tue, 27 Apr 2021 20:34:35 +0200
Subject: [PATCH libgpg-error] build: Be more consistent with memory
management.
In-Reply-To: <20210427150217.28452-1-ericonr@disroot.org> (=?utf-8?Q?=22?=
=?utf-8?Q?=C3=89rico?= Nogueira via
Gnupg-devel"'s message of "Tue, 27 Apr 2021 12:02:16 -0300")
References: <20210427150217.28452-1-ericonr@disroot.org>
Message-ID: <871ravfuf8.fsf@wheatstone.g10code.de>
On Tue, 27 Apr 2021 12:02, ?rico Nogueira said:
> * src/mkheader.c: remove xfree wrapper (free(NULL) is well-defined),
It is weel defined but there SunOS bails out on it. Further on Windows
you need to use a matching free from the same CRT; in particular for
inter-DLL use malloc and free. Thuis having a warpper is a good idea.
> use xmalloc instead of malloc+check return value, use macros to block
> malloc and strdup from being used in the program.
Nope. xmalloc is a shortcut to make things easier for short living
programs; replacing existing code by its inferior variant is a Bad
Thing.
If you have a need for changes in libgpg-error, it is best to
communicate your reasons and not just to toss some patches.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL:
From ericonr at disroot.org Tue Apr 27 21:09:13 2021
From: ericonr at disroot.org (=?UTF-8?Q?=c3=89rico_Nogueira?=)
Date: Tue, 27 Apr 2021 16:09:13 -0300
Subject: [PATCH libgpg-error] build: Be more consistent with memory
management.
In-Reply-To: <871ravfuf8.fsf@wheatstone.g10code.de>
References: <20210427150217.28452-1-ericonr@disroot.org>
<871ravfuf8.fsf@wheatstone.g10code.de>
Message-ID: <272346ba-2b4e-86b6-dd7a-9779ad6de480@disroot.org>
Em 27/04/2021 15:34, Werner Koch escreveu:
> On Tue, 27 Apr 2021 12:02, ?rico Nogueira said:
>
>> * src/mkheader.c: remove xfree wrapper (free(NULL) is well-defined),
>
> It is weel defined but there SunOS bails out on it. Further on Windows
> you need to use a matching free from the same CRT; in particular for
> inter-DLL use malloc and free. Thuis having a warpper is a good idea.
There were some free() calls in the code already. In that case, wouldn't
it be best to use a consistent function here (even if xfree())? Someone
testing only on modern *nix could miss the need to use xfree() in a
specific spot.
>
>> use xmalloc instead of malloc+check return value, use macros to block
>> malloc and strdup from being used in the program.
>
> Nope. xmalloc is a shortcut to make things easier for short living
> programs; replacing existing code by its inferior variant is a Bad
> Thing.
This is a build tool that doesn't really have much to do except fail
with an error if it can't allocate enough memory. Furthermore, the error
message + exit(1) or return 1; (in main()) code is needlessly duplicated
in the two spots where malloc() is used. Any further addition to the
tool would then have to either remember to use xmalloc() or copy the
error handling again. Blocking malloc() from being used means the
programmer (and reviewers) won't have to worry about remembering all the
rules. I agree that xmalloc doesn't fit in a library, but it definitely
fits in a build tool.
>
> If you have a need for changes in libgpg-error, it is best to
> communicate your reasons and not just to toss some patches.
I'm not tossing some patches, I just found a place to slightly improve
code terseness and overall consistency while I investigated a build
failure (for which I sent another patch).
>
>
> Shalom-Salam,
>
> Werner
>
From angel at pgp.16bits.net Wed Apr 28 01:12:47 2021
From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=)
Date: Wed, 28 Apr 2021 01:12:47 +0200
Subject: [PATCH gnupg] scd: Fix unblock (via a Reset Code) with KDF
In-Reply-To: <87wnsorlqr.fsf@jumper.gniibe.org>
References: <20210426025523.30172-1-kirelagin@gmail.com>
<87wnsorlqr.fsf@jumper.gniibe.org>
Message-ID:
Maybe it would be desirable to use an
enum salt_types { Reset_Code_salt, User_PIN_salt, Admin_PIN_salt } ?
Directly passing those literals look quite fragile maintainability-
wise.
Good job figuring it out, Kirill!