Can you give some pointers as to how one would go about developing a solution to this?
I.e., can one set up the archive locally, or is there a test instance, or how would one go about that? Also, are we looking to develop a separate tool, or a feature integrated into some existing tool? (dak?) Have you had a chance to look at the Built-Using query by ansgar which I referenced upthread? That should reliably figure out the affected packages. On Wed, Sep 5, 2018 at 10:56 PM, Moritz Muehlenhoff <[email protected]> wrote: > On Wed, Sep 05, 2018 at 08:34:10PM +0200, Florian Weimer wrote: > > * Michael Stapelberg: > > > > > I thought haskell was in a similar boat? They have tooling to schedule > > > binNMUs for affected packages. > > > > My understanding is that you can't simply schedule binNMUs on the > > security archive because the security archive does not have the > > sources until the first upload of the package. (But I'm a bit out of > > touch; this may have changed.) > > Indeed. There's two problems we need to solve: > > 1. Find a reliable mechanism if/which packages need to be rebuild. I guess > typical use cases are > * Vulnerability issue in Golang itself > * Vulnerability in some golang-foo package which is used in build > dependencies > (and transitive ones). Let's say some crypto libs need to be fixed. > > 2. Once we have a list of affected packages needing a rebuild, there's the > issue of actually building them. Due to some underlying complexities > the security > archive and the main archive are separate. Ideally that would be > resolved > in general, but I have no idea how hard it is and there's very little > people > involved in dak development. So for all practical purpose this will need > a solution kludging around it: If package foo is to be updated > in bar-security, the first upload of bar needs to include source (-sa > option in dpkg-buildpackage). That's annoying, and still manageable for > single packages, but doesn't scale for rebuilding statically linked > applications. > So we need a reliable mechanism which imports the list of affected > packages > derived in 1.) and triggers binNMUs for them along with an automated > source > import to the security archive. > > As for Michael's earlier question wrt Haskell, it's true that this also > affects > Haskell, but it hasn't been a practical issue (while in buster we'll have > applications like Prometheus or Docker which will definitely need updates > across > the lifetime of buster). Ideally whatever it being done for Go is generic > enough > to also cater for Haskell if we ever need it (or for Rust when it becomes > more > prevalent). > > Cheers, > Moritz > -- Best regards, Michael
_______________________________________________ Pkg-go-maintainers mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
