Re: Package maintainer script policy.
> Raul Miller wrote:
> > I think it should be a wishlist bug. This is a required package,
> > and in a secure environment you'd like to be able to verify the
> > dpkg scripts before running them (or perform the steps by hand).
Joey Hess <firstname.lastname@example.org> wrote:
> If you're ultra-paranoid, what's the difference between a postinst that is a
> binary (ie, libreadlineg2.deb) and a postinst that calls a binary that is
> contained in the package (ie, bash.deb)?
> We can't outlaw the second, so I see no reason to bother outlawing the
The differences are frequency of use, and need.
The postinst is run rarely (but always) and doesn't need to be a binary.
Bash and libreadline are run frequently, on many systems, and do need
to be binaries.
Because bash is long-running and large, it's difficult to assess all
its security flaws. However, it is well used and doesn't create any
network activity (or: didn't last time I looked). So it's a fairly
constrained problem. Same thing applies to libreadline and perl.
The readline postinst script runs only very briefly and is small, so
it's easy to read through its source. But it's a pointless exercise.
If it weren't for the policy requirement that these scripts respect $PATH,
this postinst could just be a symlink to /sbin/ldconfig. However, it's
just as easy to do:
# not a shell script because we're being silly about
# libreadline breaking bash.
Simple, direct, and note that perl's exec respects $PATH. Does
the postinst currently respect $PATH? Probably not (the binary
uses exec() and does not contain the string "PATH"). [I suppose
this is better classified as an integrity problem than a security
problem, but it's not been caught.]
Frankly, though, this whole excercise is silly. libc uses a
shell script for its postinst, and guess what? It works fine.
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org