[pkg-go] Security support for packages written in Go

[Dmitry Smirnov]

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
> stretch.
> 
> 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 
applications.
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,
 Dmitry Smirnov.

---

Good luck happens when preparedness meets opportunity.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-go-maintainers/attachments/20160406/ba194f03/attachment.sig>