j.w.r.degoede@xxxxxx (Hans de Goede) writes:
>>> Why? Because static linking is BAD for lots of reasons,
>> Please tell me, why static linking is BAD in *this* case.
>
> I just did a quick grep for your email in owners.list and I'm amazed by
> the fact that someone who maintains as many security related packages
> as you needs to ask.
Perhaps because I understand the reasons behind dynamic linking instead
of repeating things blindly without knowing why they are there?
Ok, let's look at 'ipsvd'; when linking the 'tcpsvd' program dynamically
(a '--without dietlibc' rpm switch should do it), we create a binary
which imports
| __errno_location
| __fxstat
| __gmon_start__
| __libc_start_main
| __xstat
| _exit
| accept
| bind
| close
| connect
| execve
| fcntl
| fork
| free
| getgrnam
| gethostname
| getpeername
| getpid
| getppid
| getpwnam
| getservbyname
| getsockname
| gettimeofday
| listen
| lseek
| malloc
| mmap
| munmap
| open
| poll
| read
| recv
| send
| setgid
| setgroups
| setsockopt
| setuid
| sigaction
| sigaddset
| sigemptyset
| sigprocmask
| sigsuspend
| socket
| time
| unlink
| unlink
| waitpid
| write
[The static linked dietlibc version will not use more of these functions.]
'malloc' and 'free' are the only higher level functions, all other
functions are simple syscall wrappers and ARE implemented unexploitable
(the related code are perhaps 20 assembly lines). It is right that the
dietlibc 'malloc(3)' implementation suffered the known integer overflow
some time ago. But in the meantime, the related 162 lines of code in
dietlibc have been reviewed several times so it can be assumed as
error-free.
So the when-static-library-contains-flaw-we-have-to-rebuild-everything
argument does not hold because the "when-static-library-contains-flaw"
condition can never occur in *this* case.
I admit that there are problems in dietlibc but none of them are
interesting in *this* case.
> Even in glibc which is widely used and audited security holes turn up
> quite regular, so this will most probably happen for dietlibc atleast
> as often as for glibc. When this happens we don't want to have to track
> which packages all are staticly linked against it. With the SSL stuff
> in ipvsd chances for holes are even bigger, so I would not only like to
> argue that ipvsd should not staticly link against dietlibc,
1. package can not be shipped with 'matrixssl' due to licensing issues;
therefore, 'matrixssl' has nothing todo with the *current* issue.
2. 'ipvsd' supports only static linking of 'matrixssl'
>>> many the same reasons why the packaging guidelines state that
>>> packages should not compile and (staticly) link against their own
>>> version fo system libs,
>> The "should" in the packaging guidelines was intentionally. It leaves
>> room to link statically when this is the better choice and in this case,
>> dietlibc is the better choice.
>>
>
> Not when this is a better choice, it doesn't say when this is a better
> choice anywhere, it says "Static libraries should only be included in
> exceptional circumstances."
This sentence means packaging of %_libdir/*.a files but NOT linking
against static libraries.
> I guess I can come up with a zillion more small programs which will be
> smaller and faster with dietlibc, thats not what this is about, the
> should is there in case its impossible to avoid this without tons of
> work.
It really depends. It's hard to find a reason to link programs like
| int main() { write(1, "Hello world\n", 12); }
dynamically against glibc instead of using dietlibc. But I would not
write a bugreport only because of this inefficiency.
>>> that is exactly what you're doing now linking against an own version
>>> of system libs.
>> ??? I do not see where 'ipvsd' links against a "local copy of a
>> library that exists on the system".
>>
>
> Its staticly linked, this it gets its own private copy hardcoded into
> the binary.
"local copy" in this sentence means a library which is both shipped in
the package and exists in the system already. 'matrixssl' might be an
example in this case when it would exist in FE already.
>>> is the exception that confirms the rule. Also notice:
>>> "Static libraries should only be included in exceptional circumstances."
>> 'ipvsd' does not provide static libraries.
>
> Nor should it use them,
That is not stated there and was never an intention of this paragraph
which covers packages shipping libraries only. 'ipvsd' is not such a
package.
>> when there are ways to make things work better, these ways should be
>> gone. Again: linking against 'dietlibc' has only advantages for
>> 'ipvsd'.
>
> When the tradeof is a small gain in speed and footprint versus
> maintainability and security then the disadvantages of your choice
> outway the advantages.
I do not see how this is related to *this* case and do not know what you
mean with "maintainablility". The "security" argument was disproved
above.
> So saying that there are only advantages is false as there are clear
> disadvantages.
Please tell me the disadvantages in *this* case.
> But this entire discussion is mood anyways. We have clear guidelines and
> you are in clear (and unnescesarry) violation of the guidelines.
Where does 'ipvsd' violate the guidelines?
Enrico
Attachment:
pgpqxexASVXrY.pgp
Description: PGP signature
-- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
