Bug#963764: [Pkg-javascript-devel] Bug#963764: Bug#963764: node-node-sass: uses embedded old security-buggy libsass
Hello, On 2020-07-08 18:46, Jonas Smedegaard wrote: > I don't want packages removed either - and for this one specifically, I > very much look forward to having mermaid in Debian - cool stuff!) I also would be unhappy to see node-node-sass removed from Debian, but I subscribe to Jonas's opinion that this package should be treated equally as others. Thus I would be willing to remove the embedded source of libsass and see what happens in future releases. Best wishes, Andrius signature.asc Description: OpenPGP digital signature
Bug#963764: [Pkg-javascript-devel] Bug#963764: Bug#963764: node-node-sass: uses embedded old security-buggy libsass
Quoting Nilesh Patra (2020-07-08 17:13:49) > On Wed, 8 Jul 2020, 20:38 Jonas Smedegaard, wrote: > > If we expect this package to evolve badly, then we should *not* keep > > an embedded copy of libsass, but instead remove this package and all > > its reverse dependencies, because libsass has been proven insecure > > if left unmaintained, > > > It has a few reverse dependencies - I mainly packaged this for getting > node-mermaid to Debian which is still in NEW, and hopefully will be > accepted. I am interested in maintaining mermaid and hence do not want > to remove node-node-sass. I don't want packages removed either - and for this one specifically, I very much look forward to having mermaid in Debian - cool stuff!) My point was that it is not a viable path forward to expect upstream code to evolve badly: Either there is some expectancy of healthy maintenance upstream, or it is unsuitable for inclusion in Debian - there is no third option of (...or we stuff the package with dead code to keep it limping). - 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
Bug#963764: [Pkg-javascript-devel] Bug#963764: Bug#963764: node-node-sass: uses embedded old security-buggy libsass
On Wed, 8 Jul 2020, 20:38 Jonas Smedegaard, wrote: > Quoting Nilesh Patra (2020-07-08 17:00:01) > > On Wed, 8 Jul 2020, 20:22 Jonas Smedegaard, wrote: > > > > > Quoting Nilesh Patra (2020-07-08 16:26:34) > > > > On Wed, 8 Jul 2020, 19:30 Jonas Smedegaard, wrote: > > > > > Please strongly consider to not only make the package link with > > > > > system-shared libsass, but also repackage upstream tarball with > > > > > embedded code copy removed, to ensure not accidentally using that > > > > > code (and to lighten the size of what gets distributed in Debian > and > > > > > simplify copyright tracking and ease security tracking). > > > > > > > > > > > > @Jonas: > > > > I considered the same approach after the first source-only-upload was > > > done. > > > > However, it might so happen that going forward the version of sass is > > > > updated to a newer upstream, and Debian adapts to that particular > > > release, > > > > but the node-sass upstream might only have support for libsass 3.6.3 > - > > > > considering that upstream of node-node-sass is slower to adapt to > > > changes. > > > > > > > > This would cause node-node-sass to FTBFS. > > > > > > Yes. That is how Debian generally works. > > > > > > Please explain why this package needs exceptional handling. > > > > > > The upstream for node-node-sass took a considerable amount of time to > > switch to libsass 3.6.3, and there is still no official upstream release > > yet. > > > > The same situation may arise in future, and it might take many months for > > upstream to adapt. > > > > Hence I considered it _might_ be sensible to keep the copy. > > > > However, I admit that your reasoning is right here - this probably > doesn't > > need exceptional handling. > > None of us can predict the future. But we can choose to assume that > this package will evolve badly in the future or that it will evolve > well. > Correct. > If we expect this package to evolve badly, then we should *not* keep an > embedded copy of libsass, but instead remove this package and all its > reverse dependencies, because libsass has been proven insecure if left > unmaintained, It has a few reverse dependencies - I mainly packaged this for getting node-mermaid to Debian which is still in NEW, and hopefully will be accepted. I am interested in maintaining mermaid and hence do not want to remove node-node-sass. Maybe I'll keep nagging the upstream for evolving this properly time and again ;-) Kind regards, Nilesh
Bug#963764: [Pkg-javascript-devel] Bug#963764: Bug#963764: node-node-sass: uses embedded old security-buggy libsass
Quoting Nilesh Patra (2020-07-08 17:00:01) > On Wed, 8 Jul 2020, 20:22 Jonas Smedegaard, wrote: > > > Quoting Nilesh Patra (2020-07-08 16:26:34) > > > On Wed, 8 Jul 2020, 19:30 Jonas Smedegaard, wrote: > > > > Please strongly consider to not only make the package link with > > > > system-shared libsass, but also repackage upstream tarball with > > > > embedded code copy removed, to ensure not accidentally using that > > > > code (and to lighten the size of what gets distributed in Debian and > > > > simplify copyright tracking and ease security tracking). > > > > > > > > > @Jonas: > > > I considered the same approach after the first source-only-upload was > > done. > > > However, it might so happen that going forward the version of sass is > > > updated to a newer upstream, and Debian adapts to that particular > > release, > > > but the node-sass upstream might only have support for libsass 3.6.3 - > > > considering that upstream of node-node-sass is slower to adapt to > > changes. > > > > > > This would cause node-node-sass to FTBFS. > > > > Yes. That is how Debian generally works. > > > > Please explain why this package needs exceptional handling. > > > The upstream for node-node-sass took a considerable amount of time to > switch to libsass 3.6.3, and there is still no official upstream release > yet. > > The same situation may arise in future, and it might take many months for > upstream to adapt. > > Hence I considered it _might_ be sensible to keep the copy. > > However, I admit that your reasoning is right here - this probably doesn't > need exceptional handling. None of us can predict the future. But we can choose to assume that this package will evolve badly in the future or that it will evolve well. If we expect this package to evolve badly, then we should *not* keep an embedded copy of libsass, but instead remove this package and all its reverse dependencies, because libsass has been proven insecure if left unmaintained, - 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
Bug#963764: [Pkg-javascript-devel] Bug#963764: Bug#963764: node-node-sass: uses embedded old security-buggy libsass
On Wed, 8 Jul 2020, 20:22 Jonas Smedegaard, wrote: > Quoting Nilesh Patra (2020-07-08 16:26:34) > > On Wed, 8 Jul 2020, 19:30 Jonas Smedegaard, wrote: > > > Please strongly consider to not only make the package link with > > > system-shared libsass, but also repackage upstream tarball with > > > embedded code copy removed, to ensure not accidentally using that > > > code (and to lighten the size of what gets distributed in Debian and > > > simplify copyright tracking and ease security tracking). > > > > > > @Jonas: > > I considered the same approach after the first source-only-upload was > done. > > However, it might so happen that going forward the version of sass is > > updated to a newer upstream, and Debian adapts to that particular > release, > > but the node-sass upstream might only have support for libsass 3.6.3 - > > considering that upstream of node-node-sass is slower to adapt to > changes. > > > > This would cause node-node-sass to FTBFS. > > Yes. That is how Debian generally works. > > Please explain why this package needs exceptional handling. The upstream for node-node-sass took a considerable amount of time to switch to libsass 3.6.3, and there is still no official upstream release yet. The same situation may arise in future, and it might take many months for upstream to adapt. Hence I considered it _might_ be sensible to keep the copy. However, I admit that your reasoning is right here - this probably doesn't need exceptional handling. Kind regards, Nilesh
Bug#963764: [Pkg-javascript-devel] Bug#963764: Bug#963764: node-node-sass: uses embedded old security-buggy libsass
Quoting Nilesh Patra (2020-07-08 16:26:34) > On Wed, 8 Jul 2020, 19:30 Jonas Smedegaard, wrote: > > Please strongly consider to not only make the package link with > > system-shared libsass, but also repackage upstream tarball with > > embedded code copy removed, to ensure not accidentally using that > > code (and to lighten the size of what gets distributed in Debian and > > simplify copyright tracking and ease security tracking). > > > @Jonas: > I considered the same approach after the first source-only-upload was done. > However, it might so happen that going forward the version of sass is > updated to a newer upstream, and Debian adapts to that particular release, > but the node-sass upstream might only have support for libsass 3.6.3 - > considering that upstream of node-node-sass is slower to adapt to changes. > > This would cause node-node-sass to FTBFS. Yes. That is how Debian generally works. Please explain why this package needs exceptional handling. - 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
Bug#963764: [Pkg-javascript-devel] Bug#963764: Bug#963764: node-node-sass: uses embedded old security-buggy libsass
Hi, On Wed, 8 Jul 2020, 19:30 Jonas Smedegaard, wrote: > Quoting mer...@debian.org (2020-07-08 15:13:06) > > The upstream has updated the libsass support to 3.6.3 [1], it's just > > not released yet. I have successfully used head of their git > > repository to build node-node-sass without the embedded libsass copy > > (there were a couple of failing mocha tests, however). > @Andrius: Thanks a lot for your work on this :-) > Thanks for looking into this issue! > > Please strongly consider to not only make the package link with > system-shared libsass, but also repackage upstream tarball with embedded > code copy removed, to ensure not accidentally using that code (and to > lighten the size of what gets distributed in Debian and simplify > copyright tracking and ease security tracking). @Jonas: I considered the same approach after the first source-only-upload was done. However, it might so happen that going forward the version of sass is updated to a newer upstream, and Debian adapts to that particular release, but the node-sass upstream might only have support for libsass 3.6.3 - considering that upstream of node-node-sass is slower to adapt to changes. This would cause node-node-sass to FTBFS. Hence, I wish to keep the embedded copy of libsass if such a situation arises. The package built with the libsass in the archive earlier - when it started to FTBFS, a flag was appended for it to build with the embedded version of libsass. On reverting the commit[1], it'd again start building with the libsass in the archive. I'd wish to keep the same approach. _Please let me know_ if this doesn't sound good to you and if you'd prefer embedded libsass to be stripped entirely. [1]: https://salsa.debian.org/js-team/node-node-sass/-/commit/bb9e5ede14253ecc02140f9a5e946b580afed3d4 Kind Regards, Nilesh
