<div dir="ltr">Can you give some pointers as to how one would go about developing a solution to this?<div><br></div><div>I.e., can one set up the archive locally, or is there a test instance, or how would one go about that?</div><div><br></div><div>Also, are we looking to develop a separate tool, or a feature integrated into some existing tool? (dak?)</div><div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 5, 2018 at 10:56 PM, Moritz Muehlenhoff <span dir="ltr"><<a href="mailto:jmm@inutil.org" target="_blank">jmm@inutil.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, Sep 05, 2018 at 08:34:10PM +0200, Florian Weimer wrote:<br>
> * Michael Stapelberg:<br>
> <br>
> > I thought haskell was in a similar boat? They have tooling to schedule<br>
> > binNMUs for affected packages.<br>
> <br>
> My understanding is that you can't simply schedule binNMUs on the<br>
> security archive because the security archive does not have the<br>
> sources until the first upload of the package.  (But I'm a bit out of<br>
> touch; this may have changed.)<br>
<br>
</div></div>Indeed. There's two problems we need to solve:<br>
<br>
1. Find a reliable mechanism if/which packages need to be rebuild. I guess<br>
   typical use cases are<br>
   * Vulnerability issue in Golang itself<br>
   * Vulnerability in some golang-foo package which is used in build dependencies<br>
     (and transitive ones). Let's say some crypto libs need to be fixed.<br>
<br>
2. Once we have a list of affected packages needing a rebuild, there's the<br>
   issue of actually building them. Due to some underlying complexities the security<br>
   archive and the main archive are separate. Ideally that would be resolved<br>
   in general, but I have no idea how hard it is and there's very little people<br>
   involved in dak development. So for all practical purpose this will need<br>
   a solution kludging around it: If package foo is to be updated<br>
   in bar-security, the first upload of bar needs to include source (-sa<br>
   option in dpkg-buildpackage). That's annoying, and still manageable for<br>
   single packages, but doesn't scale for rebuilding statically linked applications.<br>
   So we need a reliable mechanism which imports the list of affected packages<br>
   derived in 1.) and triggers binNMUs for them along with an automated source<br>
   import to the security archive.<br>
<br>
As for Michael's earlier question wrt Haskell, it's true that this also affects<br>
Haskell, but it hasn't been a practical issue (while in buster we'll have<br>
applications like Prometheus or Docker which will definitely need updates across<br>
the lifetime of buster). Ideally whatever it being done for Go is generic enough<br>
to also cater for Haskell if we ever need it (or for Rust when it becomes more<br>
prevalent).<br>
<br>
Cheers,<br>
        Moritz<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Best regards,<br>Michael</div>
</div>