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@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