Bug#850657: [pkg-gnupg-maint] Bug#850657: gnupg: Please find gpg-agent on PATH
Thanks for providing a clear statement of your position and responding
promptly. That was very helpful.
Daniel Kahn Gillmor writes ("Re: [pkg-gnupg-maint] Bug#850657: gnupg: Please
find gpg-agent on PATH"):
> This is clearly not relevant, since we're not talking about maintainer
> scripts. Why cite Policy if this isn't actually a request related to
> Policy?
There are many aspects of that part of policy which clearly ought to
apply to all applicable parts of packages. (The imprecations about
shell error handling, for example.)
> Note that i'm not saying that we *should* use embedded paths everywhere,
> just that there are legitimate use cases where that's the right thing to
> do, and we don't avoid them out of vague notions of "that's not how we
> do things in debian".
Your point that policy does not address this clearly is well made.
But I still disagree on the underlying issue. (The fact that other
programs in Debian also have this bug is not convincing to me, of
course.)
I think the right route here is to change the policy manual. The
Debian policy change process is not suitable for controversial
changes; so it seemed to better to me to refer this question to the
Debian Technical Committee.
You'll see in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850967
that I have asked the TC for a ruling clarifying the policy (or, if
you prefer, extending the policy to cover this case).
I quoted your mail there, because it seemed like a good summary of the
kinds of things that people usually say when they want to object to
this kind of change.
You (or other Debian gpg maintainers) may well want to respond
yourself. I suggest that if you feel strongly enough about this
issue, that you subscribe to #850967.
For now I expect #850967 to be rather quiet because the MIPS binutils
problem clearly much more urgently needs the TC's attention.
Regards,
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#850657: [pkg-gnupg-maint] Bug#850657: gnupg: Please find gpg-agent on PATH
Hi Ian--
On Wed 2017-01-11 06:56:19 -0500, Ian Jackson wrote:
> Daniel Kahn Gillmor writes ("Re: [pkg-gnupg-maint] Bug#850657: gnupg: Please
> find gpg-agent on PATH"):
>> On Sun 2017-01-08 17:35:13 -0500, Ian Jackson wrote:
>> > gpg executes /usr/bin/gpg-agent, rather than fetching it from the
>> > PATH.
>> >
>> > This is contrary to Debian policy.
>>
>> Can you point to the specific part of debian policy that this violates?
>
> I looked for the appropriate part. debian-policy fails to specify
> many aspects of behaviour of programs other than maintainer scripts,
> but about maintainer scripts it has this to say:
>
> | Programs called from maintainer scripts should not normally have a
> | path prepended to them.
> (policy 6.1)
This is clearly not relevant, since we're not talking about maintainer
scripts. Why cite Policy if this isn't actually a request related to
Policy?
>> If you want to pass exciting options to gpg-agent, you can pass them
>> directly by launching the agent by hand. there aren't many contortions
>> involved, afaict. Can you explain what you're trying to do?
>
> I don't think it is fruitful in this bug report to speculate about
> other ways of achieving my objective at the time I noticed the bug.
> (I disagree that this is a wishlist request. Absolute paths are a
> bug.)
It is certainly fruitful to try to find other means to an end; but
reports of "i want to do Y, but i can't do X, which i see as a necessary
precondition" can be legitimately answered with "If you want Y, do Z".
I'm pretty sure you know this, and have probably helped many people
solve their problems with this kind of alternate solution proposal in
the past.
I'm not convinced that absolute paths are a bug full stop. There are
certainly circumstances where they're a bug, but it's not all of them.
Let's be sensible about invoking absolute rules.
> Putting a stunt wrapper of a program on PATH is a well-established
> technique for debugging, and for users interfering with and modifying
> the behaviour of their systems, and for thingse like test suites.
>
> Of course the system administrator can move the program aside (perhaps
> also using dpkg-divert), but that has global effect on the whole
> system, while setting PATH has only local impact and requires no
> privilege.
Again, there are lots of other ways to achieve local debugging tools
that do not involve the kind of divergence from upstream that you're
proposing here.
>> > Please change the package to execute all its programs from PATH.
>>
>> this almost certainly won't be done. for example, if a smarcard is
>> present, scdaemon is currently invoked from /usr/lib/gnupg/scdaemon ,
>> which isn't even in the path.
>
> Sorry, I was unclear. I meant to limit my request to those programs
> which are already on PATH directories, like gpg-agent.
If you're OK with full paths for an auto-launched scdaemon built from
the same source package, why are you not ok with full paths for an
auto-launched gpg-agent built from the same source package? What if i
shipped gpg-agent in /usr/lib/gnupg/, and included a symlink to it in
/usr/bin -- would it be ok then for gpg to invoke gpg-agent from
/usr/lib/gnupg/ ? (for clarity: i'm not going to do this, because i'm
uninterested in diverging from upstream on this point; this is a thought
experiment to ask why one situation might be OK and another is not)
>> > Ideally upstream would change too but my experience is that upstreams
>> > often don't like this kind of change.
>>
>> indeed, they don't like changes that make it more difficult to track
>> down problems, [...]
>
> I don't want to have this argument with upstream. IMO this is just
> how we do things in Debian.
sorry, Ian, but it's clearly *not* "just how we do things in debian".
There are lots of things in debian that embed full paths. For one
simple example, /usr/bin/pager is listed in 10 programs on my running
system:
0 dkg@alice:~$ find /bin /usr/bin -type f -print0 | xargs -0 grep -l
/usr/bin/pager
/usr/bin/sort-dctrl
/usr/bin/tbl-dctrl
/usr/bin/join-dctrl
/usr/bin/elinks
/usr/bin/grep-dctrl
/usr/bin/wdiff
/usr/bin/ucf
/usr/bin/units
/usr/bin/smbclient
/usr/bin/update-alternatives
0 dkg@alice:~$
For a closer analogy with what GnuPG is doing, you'll see that
/usr/bin/ssh-askpass is embedded in ssh-agent, ssh-keygen, ssh, and
ssh-add binaries. This is true in jessie, and in stretch/sid. I
haven't checked older versions, but i'd bet a tasty sandwich that it's
been true since the dawn of OpenSSH (or at least since the idea of
ssh-askpass):
0 dkg@alice:~$ strings /usr/bin/ssh-add | grep ssh-askpass
/usr/bin/ssh-askpass
0 dkg@alice:~$
Note that i'm not saying that we *should* use embedded p
Bug#850657: [pkg-gnupg-maint] Bug#850657: gnupg: Please find gpg-agent on PATH
Daniel Kahn Gillmor writes ("Re: [pkg-gnupg-maint] Bug#850657: gnupg: Please
find gpg-agent on PATH"):
> On Sun 2017-01-08 17:35:13 -0500, Ian Jackson wrote:
> > gpg executes /usr/bin/gpg-agent, rather than fetching it from the
> > PATH.
> >
> > This is contrary to Debian policy.
>
> Can you point to the specific part of debian policy that this violates?
I looked for the appropriate part. debian-policy fails to specify
many aspects of behaviour of programs other than maintainer scripts,
but about maintainer scripts it has this to say:
| Programs called from maintainer scripts should not normally have a
| path prepended to them.
(policy 6.1)
> If you want to pass exciting options to gpg-agent, you can pass them
> directly by launching the agent by hand. there aren't many contortions
> involved, afaict. Can you explain what you're trying to do?
I don't think it is fruitful in this bug report to speculate about
other ways of achieving my objective at the time I noticed the bug.
(I disagree that this is a wishlist request. Absolute paths are a
bug.)
Putting a stunt wrapper of a program on PATH is a well-established
technique for debugging, and for users interfering with and modifying
the behaviour of their systems, and for thingse like test suites.
Of course the system administrator can move the program aside (perhaps
also using dpkg-divert), but that has global effect on the whole
system, while setting PATH has only local impact and requires no
privilege.
> > Please change the package to execute all its programs from PATH.
>
> this almost certainly won't be done. for example, if a smarcard is
> present, scdaemon is currently invoked from /usr/lib/gnupg/scdaemon ,
> which isn't even in the path.
Sorry, I was unclear. I meant to limit my request to those programs
which are already on PATH directories, like gpg-agent.
> > Ideally upstream would change too but my experience is that upstreams
> > often don't like this kind of change.
>
> indeed, they don't like changes that make it more difficult to track
> down problems, [...]
I don't want to have this argument with upstream. IMO this is just
how we do things in Debian. In Debian we have reportbug, which is the
right place to address the kind of bug report handling difficulties
you mention. I have other serious objections to the arguments you
made in that paragraph but I'm hoping we don't have to go there.
I'd like to contrast the reaction to this bug report with that of the
Debian devscripts maintainers in http://bugs.debian.org/850655.
Thanks,
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#850657: [pkg-gnupg-maint] Bug#850657: gnupg: Please find gpg-agent on PATH
Control: tags 850657 + moreinfo Control: severity 850657 wishlist On Sun 2017-01-08 17:35:13 -0500, Ian Jackson wrote: > gpg executes /usr/bin/gpg-agent, rather than fetching it from the > PATH. > > This is contrary to Debian policy. Can you point to the specific part of debian policy that this violates? > (This behaviour got in my way because I wanted to pass exciting > options to gpg-agent, which involved contortions.) If you want to pass exciting options to gpg-agent, you can pass them directly by launching the agent by hand. there aren't many contortions involved, afaict. Can you explain what you're trying to do? > Please change the package to execute all its programs from PATH. this almost certainly won't be done. for example, if a smarcard is present, scdaemon is currently invoked from /usr/lib/gnupg/scdaemon , which isn't even in the path. > Ideally upstream would change too but my experience is that upstreams > often don't like this kind of change. indeed, they don't like changes that make it more difficult to track down problems, and knowing that the binary you're executing is the one that was built with the one that you're running isn't a totally unreasonable expectation. There are lots of systems where users install some who-knows-what variant of gpg in /usr/local, and it's entirely reasonable for /usr/local/bin/gpg to want to execute /usr/local/bin/gpg-agent, while /usr/bin/gpg might want to execute /usr/bin/gpg-agent. (this kind of approach would indeed raise a concern for future use of gpg once the agent is running of course, but that's a separate issue, and one not fixed by relying on $PATH either) Can you explain more about why you need this? I'm happy to help you figure out what you want in general, but the argument for this change in the moment seems pretty abstract. --dkg signature.asc Description: PGP signature
