gpg-agent shell variable output

[Daniel Kahn Gillmor]

On Wed 2016-10-05 13:56:58 -0400, Werner Koch wrote:
> On Wed,  5 Oct 2016 19:14, dkg at fifthhorseman.net said:
>
>> If, instead, gpg-agent just detects that it is already running, nothing
>> is printed to stdout.  Why not?
>
> Because it needs to connect to the running gpg-agent and fetch the
> socket name.  Using gpgconf is easier.  Or the portable way:
>
>   $ gpg-connect-agent '/datafile -' 'getinfo socket_name' /echo /bye
>   /run/user/1000/gnupg/S.gpg-agent
>
> (In a script I would suggest to replace "/bye" by "</dev/null".)

in this example, you appear to be asking users to change their scripts
and stop expecting the old behavior and keep working, by explicitly
removing functionality that people had been relying on without any
mid-way deprecation steps...

>> For symmetry, we could also introduce --disable-restricted-socket and
>> explicitly deprecate --extra-socket (if the socket is going to be named
>> S.gpg-agent.rstrd then we should refer to it consistently as "restricted
>
> The option name is in use for quite some time, thus we can't really
> change it anymore.

...and here you seem to be saying that we can't change options at all
because they'll break scripts.

If we're doing a hard cut (some might call this an "API break") then we
should make the changes so that post-cutover we have as clean and
normalized an API as possible.

If we're trying to do a gradual transition (not a hard cut), we should
still add the newer, normalized options as soon as possible, so that
they are available to people who want to use them.

[ out of order quoting, sorry… ]
>> --browser-socket has never been a documented option in a released
>> version.  We could replace it entirely with --disable-browser-socket and
>> not break any documented interfaces.
>
> Already done:  Use "none" or "/dev/null" to -e-xtra or --browser socket.

I'm aware of this, but to a person setting up GnuPG, it's bewildering to
have --enable-ssh-socket but then --extra-socket FILENAME.  If we're
deprecating things and tuning the interface, we should aim for as
regular and predictable an interface as possible.

> Yes, an alias for the option would be possible but then we need to
> restart the discussion on whether "restricted" is a good term :-(.  I
> hoped we had found a compromise by keeping the option name but naming
> the socket file "S.gpg-agent.rstrd"

Upon reflection, I sort of think this is the worst of all possible
worlds:

  * "rstrd" is hard to read unless you already know that it's supposed
    to be "restricted" -- could it be "restored" or "restrained" or
    "rastered" or "roistered" or "reconstructed" or "restarted"…

  * "rstrd" is a another 5 full characters toward the already-tight
    108-char sun_path limit.

  * neither "restricted" nor "rstrd" matches the actual command-line or
    config file option "--extra-socket"

  * "--extra-socket" still doesn't suggest to the user what they're
    signing up for

If we can settle on the term "restricted" (including moving to
"--disable-restricted-socket" with a deprecation of "--extra-socket"),
what about "S.restricted" or "S.gpg.restricted" or "S.gpg-agent.R".

If we settle on the term "extra", then maybe "S.extra" or "S.gpg.extra"
or "S.gpg-agent.X"

I'm open to other suggestions.

But using a combination that only makes sense if you've been following
gnupg-devel for years is not going to help users or developers make the
right choices when using gpg in the future.

      --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 930 bytes
Desc: not available
URL: </pipermail/attachments/20161005/ea2b3028/attachment.sig>