Re: [Pkg-javascript-devel] Browserified copy and DFSG
On Mon, Sep 10, 2018 at 1:27 AM Sean Whitton wrote: > > Hello, > > On Mon 10 Sep 2018 at 11:00AM +1200, Michael Hudson-Doyle wrote: > > > 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). > > The Haskell team follows https://stackage.org/ for as many packages as > we can to try to reduce this churn. Does nothing like that exist for Go > yet? > > > 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. > > Ah, interesting, different indeed. jcristau by irc said that buidinfo could be used in order to trigger a rebuilt. May be it could add here more information, for archive sake.. Bastien > > -- > Sean Whitton -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Browserified copy and DFSG
On Sun, 9 Sep 2018 at 04:52, Sean Whitton 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@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 -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Browserified copy and DFSG
Hello, On Mon 10 Sep 2018 at 11:00AM +1200, Michael Hudson-Doyle wrote: > 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). The Haskell team follows https://stackage.org/ for as many packages as we can to try to reduce this churn. Does nothing like that exist for Go yet? > 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. Ah, interesting, different indeed. -- Sean Whitton signature.asc Description: PGP signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Browserified copy and DFSG
Hello, On Wed 05 Sep 2018 at 04:38PM +0200, Bastien ROUCARIES wrote: >> AFAIUI, Built-Using is solely to be used for compliance with licenses >> (GPL or GPL-like licenses). Are these node modules under GPL or a >> GPL-like license? If not, there should be no need for Built-Using. > > They are some module under GPL like license not yet pacakged. > > But I was thinking Built-Using may be used by security team in order > to trigger rebuild. Yes. Policy was changed to say that Built-Using should be used only for licensing issues. This was the release team's preference, and I believe they took the needs of the security team into account in coming to that preference. -- Sean Whitton signature.asc Description: PGP signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Browserified copy and DFSG
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. 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. 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. -- Sean Whitton signature.asc Description: PGP signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Browserified copy and DFSG
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? -- bye, pabs https://wiki.debian.org/PaulWise -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Browserified copy and DFSG
On Thu, Sep 6, 2018 at 10:41 PM Sean Whitton wrote: > > Hello, > > On Wed 05 Sep 2018 at 04:38PM +0200, Bastien ROUCARIES wrote: > > >> AFAIUI, Built-Using is solely to be used for compliance with licenses > >> (GPL or GPL-like licenses). Are these node modules under GPL or a > >> GPL-like license? If not, there should be no need for Built-Using. > > > > They are some module under GPL like license not yet pacakged. > > > > But I was thinking Built-Using may be used by security team in order > > to trigger rebuild. > > Yes. Policy was changed to say that Built-Using should be used only for > licensing issues. This was the release team's preference, and I believe > they took the needs of the security team into account in coming to that > preference. Ok adding cc @security How will you handle security problem in static (browserified/webpacked) javascript library ? Bastien > -- > Sean Whitton -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Browserified copy and DFSG
On 09/05/2018 04:38 PM, Bastien ROUCARIES wrote: >>> Browserify (or webpack) is a static compiler for javascript. I believe >>> that we must use built-using field in order to be policy compliant. >>> [...] > But I was thinking Built-Using may be used by security team in order > to trigger rebuild. > That should not be necessary. If we really needed that information (which seems unlikely to me), buildinfo files can provide it. Otherwise we'd set built-using to "everything in the build chroot" for every single package, and that doesn't seem like something we want or need to do. browserify doesn't seem to be that special, IMO. Cheers, Julien -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Browserified copy and DFSG
On Tue, Aug 7, 2018 at 12:43 AM Niels Thykier wrote: > > Bastien ROUCARIES: > > Hi, > > > > They are a few package that FTBFS due to lack of browserify under debian [1] > > > > The most significant point is to render javadoc FTBFS due to lack of > > browserified version of pako a port of zlib to javascript. > > > > I plan to upload browserify soon but browserify is blocked by: > > * node-insert-module-globals in NEWS (prod ftpmaster) > > * node-has-object-spread not yet packaged (i plan to do it) > > * node-has-template-literals not yet packaged (i plan to do it) Just packaged this three package > > > > Browserify (or webpack) is a static compiler for javascript. I believe > > that we must use built-using field in order to be policy compliant. > > > > I can output a list of javascript module (or file installed in the > > tree) but I lack the > > debhelper skill needed to output automatically built-using. > > > > Can somebody help me ? > > > > Bastien > > > > [1] For an approximation see > > https://lintian.debian.org/tags/source-contains-browserified-javascript.html > > that also include webpack > > > > AFAIUI, Built-Using is solely to be used for compliance with licenses > (GPL or GPL-like licenses). Are these node modules under GPL or a > GPL-like license? If not, there should be no need for Built-Using. They are some module under GPL like license not yet pacakged. But I was thinking Built-Using may be used by security team in order to trigger rebuild. Bastien > Thanks, > ~Niels -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Browserified copy and DFSG
Bastien ROUCARIES: > Hi, > > They are a few package that FTBFS due to lack of browserify under debian [1] > > The most significant point is to render javadoc FTBFS due to lack of > browserified version of pako a port of zlib to javascript. > > I plan to upload browserify soon but browserify is blocked by: > * node-insert-module-globals in NEWS (prod ftpmaster) > * node-has-object-spread not yet packaged (i plan to do it) > * node-has-template-literals not yet packaged (i plan to do it) > > Browserify (or webpack) is a static compiler for javascript. I believe > that we must use built-using field in order to be policy compliant. > > I can output a list of javascript module (or file installed in the > tree) but I lack the > debhelper skill needed to output automatically built-using. > > Can somebody help me ? > > Bastien > > [1] For an approximation see > https://lintian.debian.org/tags/source-contains-browserified-javascript.html > that also include webpack > AFAIUI, Built-Using is solely to be used for compliance with licenses (GPL or GPL-like licenses). Are these node modules under GPL or a GPL-like license? If not, there should be no need for Built-Using. Thanks, ~Niels -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Browserified copy and DFSG
Hi, They are a few package that FTBFS due to lack of browserify under debian [1] The most significant point is to render javadoc FTBFS due to lack of browserified version of pako a port of zlib to javascript. I plan to upload browserify soon but browserify is blocked by: * node-insert-module-globals in NEWS (prod ftpmaster) * node-has-object-spread not yet packaged (i plan to do it) * node-has-template-literals not yet packaged (i plan to do it) Browserify (or webpack) is a static compiler for javascript. I believe that we must use built-using field in order to be policy compliant. I can output a list of javascript module (or file installed in the tree) but I lack the debhelper skill needed to output automatically built-using. Can somebody help me ? Bastien [1] For an approximation see https://lintian.debian.org/tags/source-contains-browserified-javascript.html that also include webpack -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
