pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap

Doug Barton dougb at
Sat Aug 25 01:36:23 UTC 2012

Hash: SHA256

On 8/24/2012 5:33 PM, Glen Barber wrote:
> On Sat, Aug 25, 2012 at 01:25:15AM +0100, Jonathan Anderson wrote:
>> On 24 Aug 2012, at 23:38, Doug Barton <dougb at> wrote:
>>> Let me rephrase that more simply ... very few users are ever going to
>>> need the bootstrapping tool that will be in the base.
> So, then they won't use it.  I fail to see the problem here.

That's because you're not paying attention. :)

Which comes first in your PATH, /usr/sbin, or /usr/local/sbin? Which
comes first in the default PATH?

What Baptiste said is that the way /usr/sbin/pkg works is to take
arguments handed to it and pass them through to /usr/local/sbin/pkg.
That means that every user who has their PATH configured in the default
manner (which is what every security text on Unix has recommended for 30
years) will be using /usr/sbin/pkg every time they type the pkg command.

>> But surely the whole point of pkgng is that people *will* use pkg
>> as the default method of acquiring third-party software, so they'll
>> want to "pkg install foo" and have it Just Work. To say either "you
>> must download the ports tree in order to use binary packages" or
>> "you must use pkg_add to install pkg" seems to miss the point...
> /usr/sbin/pkg installs /usr/local/sbin/pkg without requiring the Ports
> Collection to be available locally.

It does much more than that. Go read the code.

As to the security related problems, they should be obvious. Having 1
binary that is always executed to pass arguments to another binary at
minimum doubles your attack surface. Given what /usr/sbin/pkg does, it
more than doubles it. Not to mention the flat out wrong-headed design of
having a binary that will be run as root whose primary purpose is to
pass arguments to another binary.

The reason this defeats the purpose of putting pkg in the ports tree is
that if there is a bug in /usr/sbin/pkg (which of course, there will be)
then it has to be fixed in the base, with all of the consequent drama
and delays that this will entail. If there is a bug in
/usr/local/bin/pkg, it gets fixed in the ports tree and instantly
updated, which is part of the virtue of having it in the ports tree in
the first place.

Given that if we do the rollout properly the bootstrap function will be
limited to a very small percentage of users, it makes sense to split
that function out into a separate, limited binary; and not pollute the
pkg stream with extra cruft it does not need.

> What I would like to know, is why all the anti-progress emails[1] have
> to wait until the Last Minute(tm) when information on pkgng availability
> has been available for quite some time now.

First off, I resent being told that because I'm raising legitimate
issues with something that I am being "obstructionist," or
"anti-progress." And my concerns are certainly not "last minute." I've
been raising concerns about pkg since day 1, and given that there is
still no coherent, comprehensive project plan about the migration it's
not at all surprising that others are also starting to discover daemons
in the details.

It's also part and parcel of life in an open source project. Most people
don't pay attention about most things until they feel that it will be
affecting them. This is doubly true in open source. Given how well-known
this issue is, it should be planned for in any kind of big project such
as this. It's probably also worth mentioning that there are only so many
hours in the day, so one has to prioritize.


- -- 

    I am only one, but I am one.  I cannot do everything, but I can do
    something.  And I will not let what I cannot do interfere with what
    I can do.
			-- Edward Everett Hale, (1822 - 1909)
Version: GnuPG v1.4.12 (MingW32)


More information about the freebsd-ports mailing list