Re: imformation leakage in debian binaries
On Sat, 23 Aug 2003, Joey Hess wrote:
> It's interesting to examine what information about maintainers' build
> environments slips into binary packages, and consider the possible
> consequences and what, if anything, we can do about it.
> Here's an annotated and edited version of the output of the command
> strings -f /usr/bin/* /usr/sbin/* /bin/* /usr/lib/* /lib/* /sbin/* | \
> egrep '/home/.*/' | sort | uniq
> If you're only interested in checking your own packages, I suggest
> for d in *.deb; do dpkg-deb --fsys-tarfile $d | zgrep -a $HOME ; done
> /sbin/start-stop-daemon: /mount/md0/home/adam/debian/mine/dpkg/v1_10/dpkg-1.10.10/utils/start-stop-daemon.c
> # Given the __assert_fail in the symbol table, this is probably
> # displayed as part of an assertian. One of the more common cases.
> # Of course this leaves the user wondering why the program is
> # complaining about this "adam" person and his nonexistent home
> # directory. Hmm, raid0?
> # Note that assert only puts the full path to a file in if you give that
> # full path to gcc. A minor modification to dpkg's Makefiles would
> # convert this into just "utils/start-stop-daemon.c" and save us all a
> # few bytes. I'll skip the other ~50 copies in dpkg, dselect, etc.
I've thought about doing this for dpkg's build system, before, because of the
long path that is encoded.
I'll probably be part of dpkg 2.0.