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 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". > 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'm hoping the same thing! :) > I'd like to contrast the reaction to this bug report with that of the > Debian devscripts maintainers in http://bugs.debian.org/850655. That bug report is a very different bug report. it's not surprising that it got a different reaction; both reactions are reasonable. In that bug report, you're telling a package that is invoking an external tool that they should invoke the tool from the user's PATH. In this bug report, you're asking a tightly-coupled suite of tools to invoke each other via the PATH, which offers another avenue of potential breakage; upstream regularly receives reports from people who *don't even know what version of gpg their system is running* because of multiple copies of the thing having been installed in various places on their system (either deliberately or incidentally, but in either case forgotten about by the local sysadmin). It's entirely reasonable for a tightly-coupled suite to want to invoke its own tools in this situation. we have enough to debug in GnuPG as it is :/ Regards, --dkg
signature.asc
Description: PGP signature
