[Pkg-javascript-devel] Browserified copy and DFSG

[Michael Hudson-Doyle]

On Sun, 9 Sep 2018 at 04:52, Sean Whitton <spwhitton at spwhitton.name> wrote:

> Hello,
>
> On Sat 08 Sep 2018 at 10:02AM +0800, Paul Wise wrote:
>
> > On Fri, Sep 7, 2018 at 7:22 PM, Bastien ROUCARIES wrote:
> >
> >> Ok adding cc @security
> >>
> >> How will you handle security problem in static
> >> (browserified/webpacked) javascript library ?
> >
> > Same goes for the other languages that do static linking. It would be
> > great to have this wiki page updated with some realistic strategies:
> >
> > https://wiki.debian.org/StaticLinking
> >
> > IIRC the security team recently flagged Go packages as being
> > problematic for security support in the Debian buster release. I guess
> > the same will apply to Rust now that Firefox switched to it?
>
> Hmm, Go looks to be using Built-Using in a way that is not
> Policy-compliant.
>

I think it was compliant with policy as policy stood at the time it was
implemented :)


> The Haskell team uses virtual package names in the Provides: field,
> where these virtual package names contain a hash.  This hash encodes all
> the versions of the dependencies that this build of the binary package
> used.  The Depends: field of other libraries is populated with these
> virtual package names.  For example:
>
>     spwhitton at iris:~>apt show libghc-propellor-dev
>     [...]
>     Provides: libghc-propellor-dev-3.2.3-2bad6
>     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
>
> From this information it is possible to determine what needs rebuilding,
> and we have a script that does that.  I assume this approach could be
> extended to (e.g.) Go.
>

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).


> Unfortunately, all this is only for libraries; noticing that a binary
> package that installs something into /usr/bin needs rebuilding is
> manual.  I think it could be extended, but it all depends on cdbs, so
> no-one wants to touch it.
>

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.

Golang packaging could easily enough change to X-Go-Built-Using instead and
computing the required rebuilds for a fix would remain pretty trivial.

Cheers,
mwh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-javascript-devel/attachments/20180910/eddb7ec7/attachment.html>