2015-06-11 17:52 GMT+02:00 Richard Hipp <d...@sqlite.org>:
> On 6/11/15, Michal Suchanek <hramr...@gmail.com> wrote:
>>
>> When you link dynamically with libssl then your distribution is
>> responsible for updating libssl in response to libssl vulnerabilities.
>>
>
> Yes. On the other hand, Fossil only uses libssl on the client side.
> And client-side SSL has far fewer and less severe vulnerabilities than
> server-side. So even if vulnerabilities are discovered and you do not
> update, you are probably still ok.
There are two more practical problems why fossil must link
with static libssl for the Linux downloadable executable.
1) A dynamic libssl will - in turn - be linked with a dynamic libz.
Because fossil includes a static libz as well, this opens the
hole of possible symbol conflicts. As long as the libz versions
are close enough (I think >=1.2.5 is OK) this wouldn't cause
problems, but internal changes in future libz versions could
easily break that. Conclusion: if fossil links with dynamic libssl,
it should link with dynamic libz as well.
2) Different linux distributions use a different library name for
libssl/libcrypto.
e.g. Fedora: libssl.so.10 -> libssl.so.1.0.2
Ubuntu: libssl.so.1 -> libssl.so.1.0.1
So it is impossible to build a fossil binary with works on both
Fedora and Ubuntu if libssl is linked dynamically.
I don't see any other solution than linking libssl statically. Of course,
Fedora and Ubuntu have the option to provide their own fossil binary,
which links with both libz and libssl dynamically. But such a
build will be Fedora/Ubuntu-specific, and is not guaranteed to
work on any other Linux distribution. I don't expect sqlite.org
to provide downloads for each and every Linux distribution .....
Regards,
Jan Nijtmans
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
