Re: imformation leakage in debian binaries
On Mon, 8 Sep 2003, Adam Heath wrote:
> 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.
Ok. I have it fixed.
bash-2.05b$ strings build/src/lib/tests/hashtable-test |grep hashtable-test.c
../../../src/lib/tests/hashtable-test.c
I might be able to fix it even better, by overriding __FILE__ myself(with -D)
on the cmdline, instead of letting it be filled in by cpp from -c.
Reply to: