* common/homedir.c (gnupg_maybe_make_homedir): Also create a
common.conf.
* g10/keydb.c: Include comopt.h.
(maybe_create_keyring_or_box): Detect the creation of a common.conf.
* g10/gpg.c (main): Avoid adding more resources in this case.
* sm/keydb.c: Include comopt.h.
(maybe_create_keybox): Detect the creation of a common.conf.
* common/comopt.h (comopt): Remove the conditional "extern".
* agent/command-ssh.c (ssh_handler_request_identities): Remove double
check of ERR.
* g10/getkey.c (get_pubkey_byname): Remove double use of break.
* g10/pkglue.c (pk_encrypt): Handle possible NULL-ptr access due to
failed malloc.
Signed-off-by: Werner Koch <wk@gnupg.org>
* configure.ac: New option --enable-all-tests.
* tests/gpgscm/ffi.c (ffi_init): New gloabl var *run-all-tests*.
* tests/openpgp/all-tests.scm (all-tests): Use that var instead
of *maintainer-mode*.
* Makefile.am (AM_DISTCHECK_CONFIGURE_FLAGS): Add --enable-all-tests.
--
It is better to have a separate option to run all tests than to put
this on top of --enable-maintainer-mode. This way we can also make
sure to run all tests during "make distcheck".
Signed-off-by: Werner Koch <wk@gnupg.org>
--
dev.gnupg org is the development platform but the canonical bug
address is and has always been bugs.gnupg.org. We should keep on
using this address for the case that we switch the tracker again or
split it off the development system.
That is also the reason why we should keep on communicating a plain
bug number without the 'T' prefix.
Signed-off-by: Werner Koch <wk@gnupg.org>
Replace mentions of bugs.gnupg.org with https://dev.gnupg.org/. Since
the project has transitioned to a better workflow for supporting
contributions, we should ensure that our documentation points to the
right place.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
* configure.ac: Add option --disable-libdns
(USE_LIBDNS): New ac_subst and am_conditional.
(USE_C99_CFLAGS): Set only if libdns is used.
* dirmngr/Makefile.am (dirmngr_SOURCES): Move dns.c and dns.h to ...
(dirmngr_SOURCES) [USE_LIBDNS0: here.
(t_common_src): Ditto.
* dirmngr/dirmngr.c (oRecursiveResolver): New constant.
(opts): New option "--recursive-resolver".
(parse_rereadable_options): Set option.
* dirmngr/t-dns-stuff.c (main): Add option --recursive-resolver.
* dirmngr/server.c (cmd_getinfo): Depend output of "dnsinfo" on the
new variables.
* dirmngr/dns-stuff.c: Include dns.h only if USE_DNSLIB is defined.
Also build and call dnslib functions only if USE_DNSLIB is defined.
(recursive_resolver): New var.
(enable_recursive_resolver): New func.
(recursive_resolver_p): New func.
--
In case users run into problems building GnuPG, the configure option
allows to disable that support and continue w/o Tor support using the
system resolver.
--recursive-resolver was easy enough to implement and may be useful in
some situation. It does not fully work, though.
Signed-off-by: Werner Koch <wk@gnupg.org>
* README, agent/command.c, agent/keyformat.txt, common/i18n.c,
common/iobuf.c, common/keyserver.h, dirmngr/cdblib.c,
dirmngr/ldap-wrapper.c, doc/DETAILS, doc/TRANSLATE,
doc/announce-2.1.txt, doc/gpg.texi, doc/gpgsm.texi,
doc/scdaemon.texi, doc/tools.texi, doc/whats-new-in-2.1.txt,
g10/export.c, g10/getkey.c, g10/import.c, g10/keyedit.c, m4/ksba.m4,
m4/libgcrypt.m4, m4/ntbtls.m4, po/ca.po, po/cs.po, po/da.po,
po/de.po, po/el.po, po/eo.po, po/es.po, po/et.po, po/fi.po,
po/fr.po, po/gl.po, po/hu.po, po/id.po, po/it.po, po/ja.po,
po/nb.po, po/pl.po, po/pt.po, po/ro.po, po/ru.po, po/sk.po,
po/sv.po, po/tr.po, po/uk.po, po/zh_CN.po, po/zh_TW.po,
scd/app-p15.c, scd/ccid-driver.c, scd/command.c, sm/gpgsm.c,
sm/sign.c, tools/gpgconf-comp.c, tools/gpgtar.h: replace "Allow to"
with clearer text.
In standard English, the normal construction is "${XXX} allows ${YYY}
to" -- that is, the subject (${XXX}) of the sentence is allowing the
object (${YYY}) to do something. When the object is missing, the
phrasing sounds awkward, even if the object is implied by context.
There's almost always a better construction that isn't as awkward.
These changes should make the language a bit clearer.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
--
Also fixed some of my own copyright notices due to the termination of
my assignment. The one displayed by --version is kept at FSF because
we had contributors in 2014 with FSF assignments and it gives the FSF
some visibility.
* agent/command.c (cmd_import_key): Add option --unattended.
* agent/cvt-openpgp.c (convert_transfer_key): New.
(do_unprotect): Factor some code out to ...
(prepare_unprotect): new function.
(convert_from_openpgp): Factor all code out to ...
(convert_from_openpgp_main): this. Add arg 'passphrase'. Implement
openpgp-native protection modes.
(convert_from_openpgp_native): New.
* agent/t-protect.c (convert_from_openpgp_native): New dummy fucntion
* agent/protect-tool.c (convert_from_openpgp_native): Ditto.
* agent/protect.c (agent_unprotect): Add arg CTRL. Adjust all
callers. Support openpgp-native protection.
* g10/call-agent.c (agent_import_key): Add arg 'unattended'.
* g10/import.c (transfer_secret_keys): Use unattended in batch mode.
--
With the gpg-agent taking care of the secret keys, the user needs to
migrate existing keys from secring.gpg to the agent. This and also
the standard import of secret keys required the user to unprotect the
secret keys first, so that gpg-agent was able to re-protected them
using its own scheme. With many secret keys this is quite some
usability hurdle. In particular if a passphrase is not instantly
available.
To make this migration smoother, this patch implements an unattended
key import/migration which delays the conversion to the gpg-agent
format until the key is actually used. For example:
gpg2 --batch --import mysecretkey.gpg
works without any user interaction due to the use of --batch. Now if
a key is used (e.g. "gpg2 -su USERID_FROM_MYSECRETKEY foo"), gpg-agent
has to ask for the passphrase anyway, converts the key from the
openpgp format to the internal format, signs, re-encrypts the key and
tries to store it in the gpg-agent format to the disk. The next time,
the internal format of the key is used.
This patch has only been tested with the old demo keys, more tests
with other protection formats and no protection are needed.
Signed-off-by: Werner Koch <wk@gnupg.org>
Without Libgcrypt 1.5 is was not possible to use ECC keys. ECC is
major new feature and thus it does not make sense to allow building
with an older Libgcrypt without supporting ECC.
Also fixed a few missing prototypes.
