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


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 | 8 of 20 | next ›
Discussion Overview
groupgolang-nuts @
postedJan 30, '13 at 10:39a
activeJan 30, '13 at 5:51p



site design / logo © 2021 Grokbase