* tools/gpgconf-comp.c (gc_component_check_options): Take care of
--homedir.
(retrieve_options_from_program): Ditto.
--
Note that due to the large changes in master we could not backport the
patch from there.
GnuPG-bug-id: 4882
* g10/delkey.c: Include shareddefs.h.
(delete_keys): Print a hint.
--
The option --yes has some side-effects so it is not desirable to use it
automatically. The code in master (2.3) has special treatment of
confirm messages and thus this patch is only for 2.2.
GnuPG-bug-id: 4667
Signed-off-by: Werner Koch <wk@gnupg.org>
* dirmngr/certcache.c (find_cert_bysubject): Add better debug output
and try to locate by keyid.
--
This change was suggested in T4536
but we do not have any test cases for this.
GnuPG-bug-id: 4536
Signed-off-by: Werner Koch <wk@gnupg.org>
(cherry picked from commit 4699e294cc9e59f35262adca26ca291927acca9e)
The bug report meanwhile has a test description but I have not done
the testing yet. I port this back to 2.2 anyway given that no
regression have been reported for master in nearly a year.
* g10/trustdb.c (tdb_register_trusted_key): accept fingerprint as well
as long key ID.
* doc/gpg.texi: document that --trusted-key can accept a fingerprint.
--
GnuPG-bug-id: 4855
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Fixed uses or return and kept the old string to avoid breaking
translations.
Signed-off-by: Werner Koch <wk@gnupg.org>
(cherry picked from commit 810ea2cc684480c6aadceb2a10dd00f3fa67f2fb)
Remove the test for FPRLEN which we do not have in 2.2
Signed-off-by: Werner Koch <wk@gnupg.org>
* g10/getkey.c (merge_selfsigs_main): Take a zero key creation time in
account.
--
Keys created at the Epoch have a creation time of 0; when figuring out
the latest signature with properties to apply to a key the usual
comparison A > B does not work if A is always 0. We now special case
this for the expiration and usage data.
Co-authored-by: gniibe@fsij.org
GnuPG-bug-id: 4670
Signed-off-by: Werner Koch <wk@gnupg.org>
(cherry picked from commit 161a098be6f9d50fb5f7e120baee81e75d6eb5ad)
* g10/gpg.c (opts): New options --auto-key-import,
--no-auto-key-import, and --no-include-key-block.
(gpgconf_list): Add them.
* g10/options.h (opt): Add field flags.auto_key_import.
* g10/mainproc.c (check_sig_and_print): Use flag to enable that
feature.
* tools/gpgconf-comp.c: Give the new options a Basic config level.
--
Note that the --no variants of the options are intended for easy
disabling at the command line.
GnuPG-bug-id: 4856
Signed-off-by: Werner Koch <wk@gnupg.org>
Backported from master.
Signed-off-by: Werner Koch <wk@gnupg.org>
* g10/import.c (read_key_from_file): Rename to ...
(read_key_from_file_or_buffer): this and add new parameters. Adjust
callers.
(import_included_key_block): New.
* g10/packet.h (PKT_signature): Add field flags.key_block.
* g10/parse-packet.c (parse_signature): Set that flags.
* g10/sig-check.c (check_signature2): Add parm forced_pk and change
all callers.
* g10/mainproc.c (do_check_sig): Ditto.
(check_sig_and_print): Try the included key block if no key is
available.
--
This is is the second part to support the new Key Block subpacket.
The idea is that after having received a signed mail, it is instantly
possible to reply encrypted - without the need for any centralized
infrastructure.
There is one case where this does not work: A signed mail is received
using a specified signer ID (e.g. using gpg --sender option) and the
key block with only that user ID is thus imported. The next time a
mail is received using the same key but with a different user ID; the
signatures checks out using the key imported the last time. However,
the new user id is not imported. Now when trying to reply to that
last mail, no key will be found. We need to see whether we can update
a key in such a case.
GnuPG-bug-id: 4856
Signed-off-by: Werner Koch <wk@gnupg.org>
Backported from master
Signed-off-by: Werner Koch <wk@gnupg.org>
* common/openpgpdefs.h (SIGSUBPKT_KEY_BLOCK): New.
* g10/gpg.c (oIncludeKeyBlock): New.
(opts): New option --include-key-block.
(main): Implement.
* g10/options.h (opt): New flag include_key_block.
* g10/parse-packet.c (dump_sig_subpkt): Support SIGSUBPKT_KEY_BLOCK.
(parse_one_sig_subpkt): Ditto.
(can_handle_critical): Ditto.
* g10/sign.c (mk_sig_subpkt_key_block): New.
(write_signature_packets): Call it for data signatures.
--
This patch adds support for a to be proposed OpenPGP ferature:
Introduce the Key Block subpacket to align OpenPGP with CMS.
This new subpacket may be used similar to the CertificateSet of
CMS (RFC-5652) and thus allows to start encrypted communication
after having received a signed message. In practice a stripped down
version of the key should be including having only the key material
and the self-signatures which are really useful and shall be used by
the recipient to reply encrypted.
#### Key Block
(1 octet with value 0, N octets of key data)
This subpacket MAY be used to convey key data along with a signature
of class 0x00, 0x01, or 0x02. It MUST contain the key used to create
the signature; either as the primary key or as a subkey. The key
SHOULD contain a primary or subkey capable of encryption and the
entire key must be a valid OpenPGP key including at least one User ID
packet and the corresponding self-signatures.
Implementations MUST ignore this subpacket if the first octet does not
have a value of zero or if the key data does not represent a valid
transferable public key.
GnuPG-bug-id: 4856
Signed-off-by: Werner Koch <wk@gnupg.org>
Backported from master.
Signed-off-by: Werner Koch <wk@gnupg.org>
* g10/export.c (push_export_filters): New.
(pop_export_filters): New.
(export_pubkey_buffer): Add args prefix and prefixlen. Adjust
callers.
* g10/import.c (impex_filter_getval): Add property "fpr".
* g10/main.h (struct impex_filter_parm_s): Add field hexfpr.
--
The push and pop feature will help us to use the export filter
internally in gpg. Same for the export_pubkey_buffer change.
GnuPG-bug-id: 4856
Signed-off-by: Werner Koch <wk@gnupg.org>
* g10/getkey.c (get_seckey_default_or_card): Handle the case
when card key is not suitable for requested usage.
--
GnuPG-bug-id: 4850
Signed-off-by: NIIBE Yutaka <gniibe@fsij.org>
* common/ksba-io-support.c (base64_reader_cb): Detect the END tag and
don't just rely on the padding chars. This could happen only with
CR+LF termnmated PEM files. Also move the detection into the invalid
character detection branch for a minor parser speedup.
--
GnuPG-bug-id: 4847
Signed-off-by: Werner Koch <wk@gnupg.org>
(cherry picked from commit 6248739799fd4a877529089375e2a4103d33e6f4)
* doc/gpg.texi: Update return value and warning sections.
Signed-off-by: Werner Koch <wk@gnupg.org>
(cherry picked from commit 113a8288b85725f7726bb2952431deea745997d8)
* common/util.h (EXTERN_UNLESS_MAIN_MODULE): Add the definion only
here but now without the Norcroft-C. Change all other places where it
gets defined.
* common/iobuf.h (iobuf_debug_mode): Declare unconditionally as
extern.
* common/iobuf.c (iobuf_debug_mode): Define it here.
* agent/gpg-agent.c (INCLUDED_BY_MAIN_MODULE): Define here and also in
all main modules of all other programs.
* g10/main.h: Put util.h before the local header files.
--
This change is required for use with gcc/ld's LTO feature which does
not allow common blocks. Further gcc 10 will make -fno-common the
default and thus this chnage is always needed. What a pitty.
Co-authored-by: Tomáš Mráz
GnuPG-bug-id: 4831
Signed-off-by: Werner Koch <wk@gnupg.org>
* g10/verify.c (verify_files): Track the first error code.
--
It seems to be possible to play tricks with packet structures so that
log_error is not used for a bad input data. By actually checking the
return code and let the main driver in gpg call log_error, we can fix
this case.
Note that using gpg --verify-files and relying solely on gpg's return
code is at best a questionable strategy. It is for example impossible
to tell which data has been signed.
Signed-off-by: Werner Koch <wk@gnupg.org>
(cherry picked from commit 5681b8eaa44005afdd30211b47e5fb1a799583dd)
* common/logging.c (log_inc_errorcount): Also protect against
overflow.
(log_error): Call log_inc_errorcount instead of directly bumping the
counter.
--
We already had an overflow checking for log_error but not for the
silent increment function.
This is basically the same fix we have in libgpg-error
(libgpg-error commit d72c1ddfde09ffa69745ec2439c5a16d15e2202f)
Signed-off-by: Werner Koch <wk@gnupg.org>
* tools/gpgconf.c (list_dirs): Check whether the homedir has been
taken from the registry.
--
Signed-off-by: Werner Koch <wk@gnupg.org>
(cherry picked from commit 7f12fb55f9757cd68147eca8f162c85378538405)
* g10/keylist.c (list_one): Probe for a secret key in --with-secret
mode.
--
In contrast to list_all(), list_one() did not tests for a secret key
and took MARK_TRUSTED verbatim as an indication for "secret key
available".
GnuPG-bug: 4061
Signed-off-by: Werner Koch <wk@gnupg.org>
(cherry picked from commit 59d49e4a0ac2ed27803507cb7d2c6af166527bd5)
* Makefile.am (EXTRA_DIST): Add wixlib.wxs
* build-aux/speedo.mk (w32-wixlib): New target.
(w32-release): Build wixlib if WIXPREFIX is set.
(help): Add documentation.
* build-aux/speedo/w32/wixlib.wxs
--
This build a wixlib of the Windows binaries of GnuPG.
A wixlib is a module that can be linked into another
wix project to create an installer including this
module. Gpg4win uses the wixlib from GnuPG for
it's MSI Package.
To build the wixlib you need wine with wine-mono installed
and the wixtoolset.
When calling speedo set the variable WIXPREFIX to
the location containing the extracted toolset.
e.g.:
make -f build-aux/speedo.mk w32-wixlib WIXPREFIX=~/wix
(cherry picked from commit 0b7088dc8035e8d5832c89085eea3b288de67710)
* dirmngr/server.c (proc_wkd_get): Print new NOTE status
"wkd_cached_result".
* g10/call-dirmngr.c (ks_status_cb): Detect this and print a not ein
verbose mode.
--
This little patch is helpful to see why a WKD change still does not
work after it has been updated on the server.
Signed-off-by: Werner Koch <wk@gnupg.org>
* sm/gpgsm.h (struct server_control_s): Add field 'current_time'.
* sm/certchain.c (find_up_search_by_keyid): Detect a corner case.
Also simplify by using ref-ed cert objects in place of an anyfound
var.
--
See the code for a description of the problem. Tested using the certs
from the bug report and various command lines
gpgsm --faked-system-time=XXXX --disable-crl-checks \
-ea -v --debug x509 -r 0x95599828
with XXXX being 20190230T000000 -> target cert too young
with XXXX being 20190330T000000 -> okay
with XXXX being 20190830T000000 -> okay, using the long term cert
with XXXX being 20220330T000000 -> target cert expired
The --disabled-crl-checks option is required because in our a simple
test setting dirmngr does not know about the faked time.
GnuPG-bug-id: 4696
Signed-off-by: Werner Koch <wk@gnupg.org>
(cherry picked from commit d246f317c04862cacfefc899c98da182ee2805a5)
* g10/getkey.c (get_pubkey_byname): Extend is_mbox checking.
(get_best_pubkey_byname): Ditto.
--
With this patch it is now possible to use
gpg -e -r '<foo@example.org>'
and auto key locate will find the key. Without that a plain mail
address; i.e.
gpg -e -r 'foo@example.org'
was required.
GnuPG-bug-id: 4726
Signed-off-by: Werner Koch <wk@gnupg.org>
* g10/pubkey-enc.c (get_session_key): Do not release SK.
--
Bug is in 2.2.18 only.
The semantics of the enum_secret_keys function changed in master.
When back porting this for 2.2.18 I missed this change and thus we ran
into a double free. The patches fixes the regression but is it clumsy.
We need to change the enum_secret_keys interface to avoid such a
surprising behaviour; this needs to be done in master first.
Regression-due-to: 9a317557c58d2bdcc504b70c366b77f4cac71df7
GnuPG-bug-id: 4762
Signed-off-by: Werner Koch <wk@gnupg.org>
