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
> instead,
> 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.
Reply to: