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.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers