Re: PW#5-11: Policy on stripping static libraries
On 16 Jan, joost witteveen wrote:
>
> Most security people seem to agree that security-wise it's
> better to have shared binaries.
>
I'm not a security expert, so I can take this for granted.
>> If the libs are compiled with -DDEBUG
>
> They aren't.
Yours maybe. Mine are.
Some sources embeds debugging statements conditionally compiled by that
flag. Others embed assertions activated by -UNDEBUG. I think we should
force recompilation of code with -DDEBUG -UNDEBUG to create dbg
libraries.
In fact, if I had to debug a lib which contains such debugging code, I
would expect that the dbg lib execute that code. Otherways I'd raise a
bug against the dbg package asking to use those flags.
>> Well, actually those programs are statically linked, so we have anyway
>> a big advantage.
>
> I'm only talking about dynamically linked programmes. Where do you
> see statically linked programmes?
My nightly upgraded available file tells me that there are 17 -dbg
packages; I think that only 4 carry shared libs (one yours and 3 mine),
and the rest have static libs. Wanting to debug one of these libs, you
have tho link statically, and this is much worse than a "doubled" shared
lib.
Also, if the runtime library is in use when you install the dbg package,
it will stay loaded in memory, and you'll get anyway a "doubled" lib.
On the other hand, these unstripped libs occupy a lot of space, and, if
we imagine that _all_ libs will have a dbg shared lib, then we should
consider to suggest users to keep dbg packages in .deb format on the
system, and install/disinstall as needed, as this could save a great
amount of disk space.
dpkg would handle greatly this job :-)
>> Anyway, you have not finished to comment on my proposal: what about
>> having the source?
>
> I'd like that, althought that would require all libraries to be
> re-build again. But for an "optional" policy I'd like it.
>
> One thing though: doesn't this require the source to be located
> in the same place during the building of the debugging library as
> it will be on the user-system? If so, that will make the building
> of the library one step more difficult (you'll not be able to build
> it from your homedir any more).
This was the most difficult part of my proposal, although more difficult
to explain than to do :-)
I have already posted a detailed explanation to this list (last sunday),
and also bug#16038 carries a discussion about this.
Considering that gdb searches sources also in the "build dir" that gcc
inserts in the object through a .stab asm instruction, then I think that
there are three alternative ways to get this "build dir" set to a
certain directory in the user's systems:
1) effectively use that path as the build place.
2) create a symlink from that wanted dir to the place where
effectively you're building the packages, and compile
through that symlink.
3) edit the asm source to change the .stab instruction.
Point one have the disadvantage to force use of a certain path to build
packages, and this could be unacceptable. Being that path under
/usr/src, the user need to be in group "src" or to gain privileges.
Pont two has the disadvantage of creating "something" outside the build
hierarchy, and this seems to be forbitten (apart making joey fall from
his chair :-). Also this needs user in "src" group, or chmod to
/usr/src .
Point three has the disadvantage of requiring the maintainer modify the
makefile to break the CC stage in two, and adding a sed line in between.
This require that the maintainer has GNU make skills.
Considering that the first two points are unacceptable, and that the
skill required by point three is already the _only_ requirement that we
put on maintainers, as they have to create and maintain debian/rules, as
well as modifying upstreams makefiles, then I'd use number 3 in the
proposal.
Proposal:
runtime packages:
As package name will use the word 'lib' followed by the library
name and its soname.
It will carry the shared library, stripped with --strip-unneeded
and compiled with -fPIC -D_REENTRANT , explicitly linked against
-lc and with -Wl,-shared.<soname> .
It will carry the symlink from <libname>.so.<soname> to the real
library file; this symlink have to be put in the package build
location after having copyed the real library in its proper
place, to let dpkg install them later exactly in this order.
This package will also install the shlibs file required by
dpkg-shlibdeps as well as a postinst issuing ldconfig.
This package will not carry manpages describing internals of the
library, nor will have any executable program that must be
included in a separate package.
development packages:
The same name of the runtime package followed by '-dev'.
Will carry the headers file needed by programs using the
library.
Will install all the manpages describing the internals of the
library, and other manpages not in section 1
Will install a symlink from <libname>.so to the real lib file,
and therefore this package must depend on the runtime package,
same version.
This package will install documentation and examples about the
use of the library, if supplied. It can use the same doc
directory of the runtime package; in that case it will have a
symlink from /usr/doc/<runtime>-dev to <runtime>.
debug packages:
The same name of the runtime package followed by '-dbg'.
It will carry a shared library, unstripped, compiled with
debugging options enabled ( -g -DDEBUG -UNDEBUG ), no
optimization, and linked with the same soname of the runtime
library. It will be installed using <libname>.so.<soname> as
filename, under /usr/lib/debug .
The package's scripts may NOT call ldconfig to add that pathname
to ld.so.conf, nor add the debug library name to ld.so.cache .
There is no need that this package depends on -dev package, but
if not, it must depend on the runtime package, same version.
This package will install each sorce file listed in the symbol
table in the directory /usr/src/<sourcename> , where
<sourcename> is the name-version of the source package.
To get this path go in the symbol table even when building the
package under a different path, the maintainer have to modify
the makefile to add an edit stage between compilation of sources
and assemblage. For example, if the makefile uses the implicit
rule to compile .cc sources, adding this to the makefile will
accomplish the task:
_SRCDIR_:
ln -sf . $@
%.o: %.cc _SRCDIR_
@echo "=== overwritten rule .o:.cc ($@: $^) ==="
${COMPILE.cc} -S _SRCDIR_/$< -o $*.ss
sed 's,^.stabs \"_SRCDIR_\/,.stabs \"${abs_src}/,' \
$*.ss > $*.s
${COMPILE.s} -o $@ $*.s
${RM} $*.ss $*.s
The maintainer may put this under conditional to restrict its
use to the compilation for debug packages only.
utilities package:
If the source contains utility programs they, as well as their
manpages, must be included in a separate package, named after
the libname adding '-util'. If these programs are small, and are
needed only for development, or by the sysadmin, then they could
be included in the -dev package.
Fabrizio
--
| fpolacco@icenet.fi fpolacco@debian.org fpolacco@pluto.linux.it
| Pluto Leader - Debian Developer & Happy Debian 1.3.1 User - vi-holic
| 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E
> more than 35 months are needed to get rid of the millennium. [me]
>If NT is your answer, means you didn't understand the question.[som1]
Reply to: