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!