FAQ
You mean 81 applications will break when the behavior of the DLL changes?
Or, probably more likely, 3 will break in immediately obvious ways, and 20
will break in subtle ways that aren't readily apparent, and will bite you
in the butt just when it is most painful.

I understand the solution of "rebuilding" does not always apply - if
there's a bug in 3rd party software, you can't rebuild their software. But
by the same token, replacing code their software depends on is just asking
for trouble. You can't know if the new DLL will break their code. It's
like replacing the basement of a house you don't live in and expecting the
occupants not to notice their washing machine got moved.
On Wednesday, January 30, 2013 6:53:21 AM UTC-5, Damian Gryski wrote:

Le mercredi 30 janvier 2013 11:39:37 UTC+1, Damian Gryski a écrit :
His example is if a security problem with a shared library (say,
openssl) is discovered, only a single package (the vulnerable ssl lib)
needs to be upgraded. If a problem with Go's SSL implementation is
discovered, every Go application that might use that library needs to be
rebuilt, and for packages without source code you'd never know which ones
include the vulnerable code. He does, however, agree that the 'single
binary' deployment is an improvement over fighting with multitudes of Perl
or Python modules.

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).

Damian
--
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

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 11 of 20 | next ›
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJan 30, '13 at 10:39a
activeJan 30, '13 at 5:51p
posts20
users13
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase