On Wed, Jan 30, 2013 at 10:53 PM, Damian Gryski wrote:

I want to clarify the problem here. People are talking about
"recompling the application and redeploy". However, the objection is at
the _system_ level. So, on one of our servers there are 81 binaries in
/usr/bin linked against libssl.so . All 81 applications will be updated
against a security vulnerability by updating _one_ shared library. The
objection (from the sysadmin team) is that with static linking you now need
to recompile and deploy 81 packages (or however many rpms they actually
come from).
First, how come you have the source for the library, so you can patch it
and recompile, but don't have the source for the applications that use the
library? How does dynamic linking help you if you have a vulnerable library
that you can't recompile?

In terms of having applications that you don't have source for, these
generally come from some vendor that is going to statically link them(or
provide their own copy of the library) anyway because they don't want to
deal with the problems of support software using dependencies that they
can't test with. The vendor is then responsible for patching their program.

In the case that you have the source,
Sure 81 binaries need to be reinstalled, but your package management
software takes care of that. It knows which binaries need updates and
updates them, it also knows which binaries use libssl but don't use the
part of it that was patched and thus don't need to be updated. From the
perspective of systems management static linking is more reliable and any
pain is hidden by your package management system.


You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 12 of 20 | next ›
Discussion Overview
groupgolang-nuts @
postedJan 30, '13 at 10:39a
activeJan 30, '13 at 5:51p



site design / logo © 2021 Grokbase