[pkg-golang-devel] [pkg-go] Security support for packages written in Go
onlyjob at debian.org
Tue Apr 5 23:24:20 UTC 2016
On Tuesday, 5 April 2016 9:27:27 AM AEST Florian Weimer wrote:
> we need to discuss how we can support applications written in Go for
> The most radical approach would be not to ship any Go applications in
> stretch, only the basic Go language implementations. This is probably
> not desirable.
Alternatively we could explicitly disclaim security support for Golang
IMHO Golang community abused almost as much as possible with static linking,
embedding resources to executables, not using versioning and breaking API at
any time, etc.
Even if we find effective technical solution to detect dependency chains
there is a problem of re-building ever growing number of all packages
indirectly depending on vulnerable package.
Golang is just too young, unstable and fragile. I have a feeling that few
upstream projects take security concerns seriously. Many upstream projects
have no concept of "stable" releases so I doubt it is practical to offer any
kind of security support for Golang when too many projects introduce new
dependencies with almost every new versioned release while old release is
abandoned as soon as new one becomes available.
Unless we can exclude Golang from security support I think we should not ship
any Golang applications with next stable release.
Unfortunately if we exclude Golang binaries from release Debian will not be
competitive in the enterprise sector: industry is rapidly developing Golang
tools for container solutions and they are crucial for Debian success.
To some extent we can compensate for absence of Golang binaries in stable
release if we continue developing in "testing" and make selected apps
available through stretch-backports suite.
> One approach would be to ship applications as source code only (just
> like libraries), and compile them locally upon installation. This is
> what Emacs and Common Lisp implementations already do. With the
> growth of Go compilation and link times, this seems less and less
> attractive, though.
This is a possible solution but with Golang it is not practical as building
some packages takes too much time and resources. Also we still need to build
packages on build servers to have tests coverage and build logs.
Unfortunately shipping Golang applications in sources only (no binaries) is
not an option...
All the best,
Good luck happens when preparedness meets opportunity.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: This is a digitally signed message part.
More information about the pkg-golang-devel