mirror of
git://git.gnupg.org/gnupg.git
synced 2024-12-22 10:19:57 +01:00
faf3c70c77
* configure.ac (GNUPG_CACHE_DIR): New const.
* tools/Makefile.am (libexec_PROGRAMS): Add gpg-pair-tool.
(gpg_pair_tool_SOURCES, gpg_pair_tool_CFLAGS)
(gpg_pair_tool_LDADD): New.
* tools/gpg-pair-tool.c: New.
--
This is a first try on a protocol to pair two devices so that they can
agree on a shared secret to exchange secret keys. The idea is that if
you want to sync your secret keys to another machine (e.g. from
desktop to mobile) you have physical access to both devices and thus a
pairing protocol allows to authenitcate the connection using a short
string. See the source for a protocol description.
How to test:
$ gpg-pair-tool -va --homedir . --initiate >msg.commit
$ gpg-pair-tool -va --homedir 2ndhome --respond \
<msg.commit >msg.dhpart1
$ gpg-pair-tool -va --homedir . --respond \
<msg.dhpart1 >msg.dhpart2
$ gpg-pair-tool -va --homedir 2ndhome --respond \
<msg.dhpart2 >msg.confirm
Now set the SAS as printed by the responder into SAS and run
$ gpg-pair-tool -va --homedir . --respond --sas $SAS <msg.confirm
Storing the secret on disk is obviously not the right thing to do.
With the new PUT_SECRET and GET_SECRET commands of gpg-agent we can
change this to store it all in gpg-agent instead. This will make it
also easier for gpg to access the secret and we won't need an option
to return it from gpg-pair-tool. Thus gpg-pair-tool can be dedicated
to run the protocol and maybe to popup info dialogs.
Adding a second expiration time for running the protocol in addition
to the expiration of the secret is probably a better idea than just
that simple catch-all TTL.
Signed-off-by: Werner Koch <wk@gnupg.org>
============ GPG Conf ============ Main documentation for this tool can be found in doc/tools.texi. BACKENDS ======== Backends should support the following commands: Command --gpgconf-list ---------------------- List the location of the configuration file, and all default values of all options. The location of the configuration file must be an absolute pathname. The format of each line is: NAME:FLAGS:DEFAULT:ARGDEF NAME This field contains a name tag for the group or option. The name tag is used to specify the group or option in all communication with GPGConf. The name tag is to be used verbatim. It is not in any escaped format. FLAGS The flags field contains an unsigned number. Its value is the OR-wise combination of the following flag values: 16 default If this flag is set, a default value is available. 32 default desc If this flag is set, a (runtime) default is available. This and the "default" flag are mutually exclusive. 64 no arg desc If this flag is set, and the "optional arg" flag is set, then the option has a special meaning if no argument is given. DEFAULT This field is defined only for options. Its format is that of an option argument (see section Format Conventions for details). If the default value is empty, then no default is known. Otherwise, the value specifies the default value for this option. Note that this field is also meaningful if the option itself does not take a real argument. ARGDEF This field is defined only for options for which the "optional arg" flag is set. If the "no arg desc" flag is not set, its format is that of an option argument (see section Format Conventions for details). If the default value is empty, then no default is known. Otherwise, the value specifies the default value for this option. If the "no arg desc" flag is set, the field is either empty or contains a description of the effect of this option if no argument is given. Note that this field is also meaningful if the option itself does not take a real argument. Example: $ dirmngr --gpgconf-list gpgconf-config-file:/mnt/marcus/.gnupg/dirmngr.conf ldapservers-file:/mnt/marcus/.gnupg/dirmngr_ldapservers.conf add-servers:0 max-replies:10 TODO ---- * Implement --dry-run and --quiet. * Extend the backend interface to include gettext domain and description, if available, to avoid repeating this information in gpgconf.