Re: [Pkg-javascript-devel] dh-sequence-nodejs improvements
On Fri, Feb 04, 2022 at 11:06:53AM +0100, Yadd wrote: > > Thanks for your work! > > I had a question: wouldn't that be a violation of the policy? > > Since at the same link you passed, it says: > > > > | This field should be used only when there are license or DFSG > > requirements to > > | retain the referenced source packages. It should not be added solely > > as a way > > | to locate packages that need to be rebuilt against newer versions of > > their build dependencies. > > You're right, it's probably not the good field. Yes, Built-Using has a specific goal and it affects how dak retains source packages even when no binaries are coming from them. Don't add such field needlessly. > > Although the goal here is to track CVE's, but it does not seem to do > > much with licenses. > > > > Actually, even golang team uses something similar (not exactly same); > > please consider to look at this link[2] > > and they were thinking of doing > > it on something on the lines of the rust team, i.e. introducing a > > XS--Built-Using or something similar; > > do you think using a XS-javascript-Built-Using could be a more sensible > > option on our side? > > > > Let me know. > > Or X-Javascript-Built-Using ? You'd likely need to use XB- so that it gets into the binary packages and then in the Packages index file (I think). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- 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] dh-sequence-nodejs improvements
On 04/02/2022 10:27, Yadd wrote:
Hi all,
when dh-sequence-nodejs (0.11.9, better with 0.11.10) detects a
"maybe-bundled-package" (ie webpack/browserify/rollup), it:
* generates some pkgjs-lock.json files
* generates a ${nodejs:BuiltUsing} variable usable in debian/control
(see [1])
The goal here is to be able to launch a transition is case of CVE in a
source of a bundled package.
To use ${nodejs:BuiltUsing}, simply add:
Package: node-foo
Built-Using: ${nodejs:BuiltUsing}
pkgjs-lock files are also used by pkgjs-audit: this tool launches a `npm
audit` using Debian dependencies, not dependencies found in package.json.
$ pkgjs-audit @babel/core
found 0 vulnerabilities
Notes:
* pkgjs-lock.json contains all module+version used, including those
existing in a node_modules dir (and declared in package.json)
* there is one pkgjs-lock.json in each installed module
* ${nodejs:BuildUsing} contains only Debian packages + versions.
Cheers,
Yadd
[1]:
https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using)
pkgjs-audit found this (maybe false positive since it doesn't read
debian/patches). I'm going to build a new check in lintian pkg-js-extra
profile.
eslint-config-eslint 5.0.1
Severity: critical
Malicious Package in eslint-scope -
https://github.com/advisories/GHSA-hxxf-q3w9-4xgw
node-fetch <2.6.7
Severity: high
node-fetch is vulnerable to Exposure of Sensitive Information to an
Unauthorized Actor - https://github.com/advisories/GHSA-r683-j2x4-v87g
trim-newlines <3.0.1
Severity: high
Regular Expression Denial of Service in trim-newlines -
https://github.com/advisories/GHSA-7p7h-4mm5-852v
nth-check <2.0.1
Severity: moderate
Inefficient Regular Expression Complexity in nth-check -
https://github.com/advisories/GHSA-rp65-9cf3-cjxr
--
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] dh-sequence-nodejs improvements
On 4 February 2022 3:36:53 pm IST, Yadd wrote: >On 04/02/2022 10:50, Nilesh Patra wrote: >> Actually, even golang team uses something similar (not exactly same); please >> consider to look at this link[2] >> and they were thinking of doing >> it on something on the lines of the rust team, i.e. introducing a >> XS--Built-Using or something similar; >> do you think using a XS-javascript-Built-Using could be a more sensible >> option on our side? >> >> Let me know. > >Or X-Javascript-Built-Using ? Yep, makes sense, XS was cut-and-paste error at my end. We will probably need to adapt the rust team code for adding/using this field. Thanks for replying! Nilesh >>> [1]: >>> https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using >>> >> [2]: >> https://wiki.debian.org/Teams/DebianGoTeam/2020/GoEcosystemIssues#unstable-.3Etesting_migration >> -- 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] dh-sequence-nodejs improvements
On 04/02/2022 10:50, Nilesh Patra wrote:
Hi Yadd,
On 2/4/22 2:57 PM, Yadd wrote:
Hi all,
when dh-sequence-nodejs (0.11.9, better with 0.11.10) detects a
"maybe-bundled-package" (ie webpack/browserify/rollup), it:
* generates some pkgjs-lock.json files
* generates a ${nodejs:BuiltUsing} variable usable in debian/control
(see [1])
The goal here is to be able to launch a transition is case of CVE in a
source of a bundled package.
To use ${nodejs:BuiltUsing}, simply add:
Thanks for your work!
I had a question: wouldn't that be a violation of the policy?
Since at the same link you passed, it says:
| This field should be used only when there are license or DFSG
requirements to
| retain the referenced source packages. It should not be added solely
as a way
| to locate packages that need to be rebuilt against newer versions of
their build dependencies.
You're right, it's probably not the good field.
Although the goal here is to track CVE's, but it does not seem to do
much with licenses.
Actually, even golang team uses something similar (not exactly same);
please consider to look at this link[2]
and they were thinking of doing
it on something on the lines of the rust team, i.e. introducing a
XS--Built-Using or something similar;
do you think using a XS-javascript-Built-Using could be a more sensible
option on our side?
Let me know.
Or X-Javascript-Built-Using ?
[1]:
https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using
[2]:
https://wiki.debian.org/Teams/DebianGoTeam/2020/GoEcosystemIssues#unstable-.3Etesting_migration
Regards,
Nilesh
--
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] dh-sequence-nodejs improvements
Hi Yadd,
On 2/4/22 2:57 PM, Yadd wrote:
Hi all,
when dh-sequence-nodejs (0.11.9, better with 0.11.10) detects a
"maybe-bundled-package" (ie webpack/browserify/rollup), it:
* generates some pkgjs-lock.json files
* generates a ${nodejs:BuiltUsing} variable usable in debian/control
(see [1])
The goal here is to be able to launch a transition is case of CVE in a source
of a bundled package.
To use ${nodejs:BuiltUsing}, simply add:
Thanks for your work!
I had a question: wouldn't that be a violation of the policy?
Since at the same link you passed, it says:
| This field should be used only when there are license or DFSG requirements to
| retain the referenced source packages. It should not be added solely as a way
| to locate packages that need to be rebuilt against newer versions of their
build dependencies.
Although the goal here is to track CVE's, but it does not seem to do much with
licenses.
Actually, even golang team uses something similar (not exactly same); please
consider to look at this link[2]
and they were thinking of doing
it on something on the lines of the rust team, i.e. introducing a
XS--Built-Using or something similar;
do you think using a XS-javascript-Built-Using could be a more sensible option
on our side?
Let me know.
[1]:
https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using
[2]:
https://wiki.debian.org/Teams/DebianGoTeam/2020/GoEcosystemIssues#unstable-.3Etesting_migration
Regards,
Nilesh
OpenPGP_signature
Description: OpenPGP digital 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] dh-sequence-nodejs improvements
Quoting Yadd (2022-02-04 10:27:02)
> when dh-sequence-nodejs (0.11.9, better with 0.11.10) detects a
> "maybe-bundled-package" (ie webpack/browserify/rollup), it:
> * generates some pkgjs-lock.json files
> * generates a ${nodejs:BuiltUsing} variable usable in debian/control
> (see [1])
>
> The goal here is to be able to launch a transition is case of CVE in a
> source of a bundled package.
>
> To use ${nodejs:BuiltUsing}, simply add:
>
>Package: node-foo
>Built-Using: ${nodejs:BuiltUsing}
>
> pkgjs-lock files are also used by pkgjs-audit: this tool launches a `npm
> audit` using Debian dependencies, not dependencies found in package.json.
>
>$ pkgjs-audit @babel/core
>found 0 vulnerabilities
>
> Notes:
> * pkgjs-lock.json contains all module+version used, including those
> existing in a node_modules dir (and declared in package.json)
> * there is one pkgjs-lock.json in each installed module
> * ${nodejs:BuildUsing} contains only Debian packages + versions.
That's really cool!
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: 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
