<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">On Sun, 9 Sep 2018 at 04:52, Sean Whitton <<a href="mailto:spwhitton@spwhitton.name">spwhitton@spwhitton.name</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
On Sat 08 Sep 2018 at 10:02AM +0800, Paul Wise wrote:<br>
<br>
> On Fri, Sep 7, 2018 at 7:22 PM, Bastien ROUCARIES wrote:<br>
><br>
>> Ok adding cc @security<br>
>><br>
>> How will you handle security problem in static<br>
>> (browserified/webpacked) javascript library ?<br>
><br>
> Same goes for the other languages that do static linking. It would be<br>
> great to have this wiki page updated with some realistic strategies:<br>
><br>
> <a href="https://wiki.debian.org/StaticLinking" rel="noreferrer" target="_blank">https://wiki.debian.org/StaticLinking</a><br>
><br>
> IIRC the security team recently flagged Go packages as being<br>
> problematic for security support in the Debian buster release. I guess<br>
> the same will apply to Rust now that Firefox switched to it?<br>
<br>
Hmm, Go looks to be using Built-Using in a way that is not<br>
Policy-compliant.<br></blockquote><div><br></div><div>I think it was compliant with policy as policy stood at the time it was implemented :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The Haskell team uses virtual package names in the Provides: field,<br>
where these virtual package names contain a hash.  This hash encodes all<br>
the versions of the dependencies that this build of the binary package<br>
used.  The Depends: field of other libraries is populated with these<br>
virtual package names.  For example:<br>
<br>
    spwhitton@iris:~>apt show libghc-propellor-dev<br>
    [...]<br>
    Provides: libghc-propellor-dev-3.2.3-2bad6<br>
    Depends: libghc-ifelse-dev-0.85.0.0.1-44d2e, libghc-missingh-dev-1.4.0.1-3e847, libghc-ansi-terminal-dev-0.6.2.3-5aa2a, libghc-async-dev-2.1.0-c8d71, libghc-base-dev-4.9.0.0-5e731, libghc-bytestring-dev-0.10.8.1-58b19, libghc-containers-dev-0.5.7.1-8be09, libghc-directory-dev-1.2.6.2-958b8, libghc-exceptions-dev-0.8.3-5d23e, libghc-filepath-dev-1.4.1.0-6e799, libghc-hslogger-dev-1.2.10-8c36b, libghc-mtl-dev-2.2.1-3d1c9, libghc-network-dev-2.6.3.1-f63b0, libghc-process-dev-1.4.2.0-e39cb, libghc-stm-dev-2.4.4.1-99cba, libghc-text-dev-1.2.2.1-80edf, libghc-time-dev-1.6.0.1-6cdb6, libghc-transformers-dev-0.5.2.0-3446d, libghc-unix-dev-2.7.2.0-220bd, libghc-unix-compat-dev-0.4.2.0-bb71a, libc6 (>= 2.2.5), libgmp10<br>
<br>
>From this information it is possible to determine what needs rebuilding,<br>
and we have a script that does that.  I assume this approach could be<br>
extended to (e.g.) Go.<br></blockquote><div><br></div><div>I actually implemented something like this for Go in Ubuntu when we were looking at building Go shared libraries but we gave up on that whole approach (because even minor releases of Go upstream tend to break ABI and the churn becomes endless).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Unfortunately, all this is only for libraries; noticing that a binary<br>
package that installs something into /usr/bin needs rebuilding is<br>
manual.  I think it could be extended, but it all depends on cdbs, so<br>
no-one wants to touch it.<br></blockquote><div><br></div><div>It's not actually so bad with Go because the -dev packages ship source code only and so if a library package is updated, you only have to build the packages that install binaries that use that library package. You don't have this game of having to build all the rdeps recursively and in the right order.</div><div><br></div><div>Golang packaging could easily enough change to X-Go-Built-Using instead and computing the required rebuilds for a fix would remain pretty trivial.</div><div><br></div><div>Cheers,</div><div>mwh</div></div></div>