nodejs: CVE-2014-5256

Debian Bug report logs - #760385
nodejs: CVE-2014-5256

Reply or subscribe to this bug.

Toggle useless messages

---

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Package: nodejs
Version: 0.10.29~dfsg-1
Severity: important
Tags: security, fixed-upstream

Hi,

the following vulnerability has been fixed in nodejs v.0.10.30

http://blog.nodejs.org/2014/07/31/v8-memory-corruption-stack-overflow/

---
Henri Salo

[signature.asc (application/pgp-signature, inline)]

---

Message #18 received at 760385@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hello,
We added upstream patch provided from [1] during Debian BSP in Paris.

Package build went well, even if we face an error during tests.
This error is referenced and has been commented in bug #766484 and is
related to libssl-dev version.

Please find patch attached.

Regards,
Jean Baptiste

[1] http://blog.nodejs.org/2014/07/31/v8-memory-corruption-stack-overflow/

[nodejs_0.10.29~dfsg-1.1.diff (text/x-patch, attachment)]

[signature.asc (application/pgp-signature, attachment)]

---

Message #23 received at 760385@bugs.debian.org (full text, mbox, reply):

reassign 760385 libv8-3.14
thanks

The problem with that patch is that i can't tell if libv8-3.14 ABI
changes with it or not.
I had plans to use abi-compliance-checker in debian/rules, unfortunately
i need to spend my time on the paid job if i want to heat my house this
winter :(

Jérémy.


Le samedi 15 novembre 2014 à 13:15 +0100, Jean Baptiste Favre a écrit :
> Hello,
> We added upstream patch provided from [1] during Debian BSP in Paris.
> 
> Package build went well, even if we face an error during tests.
> This error is referenced and has been commented in bug #766484 and is
> related to libssl-dev version.
> 
> Please find patch attached.
> 
> Regards,
> Jean Baptiste
> 
> [1] http://blog.nodejs.org/2014/07/31/v8-memory-corruption-stack-overflow/

---

Message #32 received at 760385@bugs.debian.org (full text, mbox, reply):

Maybe I can help to check wether ABI changed or not.
How can I check that ?

Regards,
Jean Baptiste

On 15/11/2014 14:44, Jérémy Lal wrote:
> reassign 760385 libv8-3.14
> thanks
>
> The problem with that patch is that i can't tell if libv8-3.14 ABI
> changes with it or not.
> I had plans to use abi-compliance-checker in debian/rules, unfortunately
> i need to spend my time on the paid job if i want to heat my house this
> winter :(
>
> Jérémy.
>
>
> Le samedi 15 novembre 2014 à 13:15 +0100, Jean Baptiste Favre a écrit :
> > Hello,
> > We added upstream patch provided from [1] during Debian BSP in Paris.
> >
> > Package build went well, even if we face an error during tests.
> > This error is referenced and has been commented in bug #766484 and is
> > related to libssl-dev version.
> >
> > Please find patch attached.
> >
> > Regards,
> > Jean Baptiste
> >
> > [1] http://blog.nodejs.org/2014/07/31/v8-memory-corruption-stack-overflow/

---

Message #37 received at 760385@bugs.debian.org (full text, mbox, reply):

Yes i think you can,
you have to build the package, run abi-compliance-checker,
patch, rebuild, rerun a-c-c and compare.

To run a-c-c you might find some example config at:
http://upstream.rosalinux.ru/versions/v8.html
(click [show log])


Le samedi 15 novembre 2014 à 15:50 +0100, Jean Baptiste Favre a écrit :
> Maybe I can help to check wether ABI changed or not.
> How can I check that ?
> 
> Regards,
> Jean Baptiste
> 
> On 15/11/2014 14:44, Jérémy Lal wrote:
> > reassign 760385 libv8-3.14
> > thanks
> >
> > The problem with that patch is that i can't tell if libv8-3.14 ABI
> > changes with it or not.
> > I had plans to use abi-compliance-checker in debian/rules, unfortunately
> > i need to spend my time on the paid job if i want to heat my house this
> > winter :(
> >
> > Jérémy.
> >
> >
> > Le samedi 15 novembre 2014 à 13:15 +0100, Jean Baptiste Favre a écrit :
> > > Hello,
> > > We added upstream patch provided from [1] during Debian BSP in Paris.
> > >
> > > Package build went well, even if we face an error during tests.
> > > This error is referenced and has been commented in bug #766484 and is
> > > related to libssl-dev version.
> > >
> > > Please find patch attached.
> > >
> > > Regards,
> > > Jean Baptiste
> > >
> > > [1] http://blog.nodejs.org/2014/07/31/v8-memory-corruption-stack-overflow/

---

Message #42 received at 760385@bugs.debian.org (full text, mbox, reply):

Hi Jean Baptiste,

thank you for looking into this.
Note that the changelog entries for nodejs 0.10.31 and .32 include
  v8: backport CVE-2013-6668
  v8: fix a crash introduced by previous release
If libv8 in Debian is affected by those, you might also consider also 
backporting those fixes when preparing a new v8 package.

(Elsewhere in NodeJS .33 there is "crypto: Disable autonegotiation for 
SSLv2/3 by default", not sure whether the release team would let 
something like that through.)

Best regards

Thomas

---

Message #47 received at 760385@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hello Thomas,
Thanks for your update.

I decided to have a look on this bug because it seemed quite easy to fix
it: upstream patch was available and small anough for me.
Unfortunatly, I'm sure I'll be able to deal with lib8-3.14. The more I
dig into, the less I understand (more or less) :)

I'll try anyway,
Regards,
Jean Baptiste

On 15/11/2014 20:44, Thomas Viehmann wrote:
> Hi Jean Baptiste,
>
> thank you for looking into this.
> Note that the changelog entries for nodejs 0.10.31 and .32 include
>   v8: backport CVE-2013-6668
>   v8: fix a crash introduced by previous release
> If libv8 in Debian is affected by those, you might also consider also
> backporting those fixes when preparing a new v8 package.
>
> (Elsewhere in NodeJS .33 there is "crypto: Disable autonegotiation for
> SSLv2/3 by default", not sure whether the release team would let
> something like that through.)
>
> Best regards
>
> Thomas

[signature.asc (application/pgp-signature, attachment)]

---

Message #52 received at 760385@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

I meant "I'm *not* sure I'll be able to deal with lib8-3.14

Sorry,
Jean Baptiste

On 15/11/2014 21:28, Jean Baptiste Favre wrote:
> Hello Thomas,
> Thanks for your update.
> 
> I decided to have a look on this bug because it seemed quite easy to fix
> it: upstream patch was available and small anough for me.
> Unfortunatly, I'm sure I'll be able to deal with lib8-3.14. The more I
> dig into, the less I understand (more or less) :)
> 
> I'll try anyway,
> Regards,
> Jean Baptiste
> 
> On 15/11/2014 20:44, Thomas Viehmann wrote:
>> Hi Jean Baptiste,
>>
>> thank you for looking into this.
>> Note that the changelog entries for nodejs 0.10.31 and .32 include
>>   v8: backport CVE-2013-6668
>>   v8: fix a crash introduced by previous release
>> If libv8 in Debian is affected by those, you might also consider also
>> backporting those fixes when preparing a new v8 package.
>>
>> (Elsewhere in NodeJS .33 there is "crypto: Disable autonegotiation for
>> SSLv2/3 by default", not sure whether the release team would let
>> something like that through.)
>>
>> Best regards
>>
>> Thomas
> 

[signature.asc (application/pgp-signature, attachment)]

---

Message #57 received at 760385@bugs.debian.org (full text, mbox, reply):

control: severity -1 important

There is no security support for libv8 in jessie, so security issues aren't RC.

Best wishes,
Mike

---

Message #64 received at 760385@bugs.debian.org (full text, mbox, reply):

Hi Mike,

On Fri, 19 Dec 2014 21:11:10 -0500 Michael Gilbert <mgilbert@debian.org>
wrote:
> control: severity -1 important
> 
> There is no security support for libv8 in jessie, so security issues aren't RC.
Could you please add some links to explain that?
I was about to fix this issue in an NMU after double-checking the fix.

Cheers,
Balint

---

Message #69 received at 760385@bugs.debian.org (full text, mbox, reply):

On Sat, Dec 20, 2014 at 4:59 AM, Balint Reczey wrote:
> Hi Mike,
>
> On Fri, 19 Dec 2014 21:11:10 -0500 Michael Gilbert
> wrote:
>> control: severity -1 important
>>
>> There is no security support for libv8 in jessie, so security issues aren't RC.
> Could you please add some links to explain that?
> I was about to fix this issue in an NMU after double-checking the fix.

Severity doesn't say anything about whether or not a bugs can be
fixed, so you can still do that.  Anyway it was decided recently on
the security team ml.

Best wishes,
Mike

---

Message #74 received at 760385@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Quoting Michael Gilbert (2014-12-20 03:11:10)
> control: severity -1 important
> 
> There is no security support for libv8 in jessie, so security issues aren't RC.

Lack of support do not change severity.  Seems more appropriate to then 
tag as *-ignore instead.

 - 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 (application/pgp-signature, inline)]

---

Message #79 received at 760385@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Quoting Michael Gilbert (2014-12-20 11:06:47)
> On Sat, Dec 20, 2014 at 4:59 AM, Balint Reczey wrote:
>> On Fri, 19 Dec 2014 21:11:10 -0500 Michael Gilbert wrote:
>>> control: severity -1 important
>>>
>>> There is no security support for libv8 in jessie, so security issues 
>>> aren't RC.
>> Could you please add some links to explain that?
>> I was about to fix this issue in an NMU after double-checking the 
>> fix.
>
> Severity doesn't say anything about whether or not a bugs can be 
> fixed, so you can still do that.  Anyway it was decided recently on 
> the security team ml.

I find it sensible for the security team to give up on maintaining some 
packages - and I find it great to try communicate that to our users by 
use of the debian-security-support package.

Just now I learned from above bugreport that the security team also 
actively *lower* bugreports to avoid them being treated as release 
candidate, for packages not maintained by the security team.  That I 
find a horrible approach: Severity of a bug is independent on whether it 
will be fixed or not.  The more proper tag to use is *-ignore, IMO.

Please let us not hide problems!


 - 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 (application/pgp-signature, inline)]

---

Message #84 received at 760385@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

[sent again, cc correct list address this time]

Quoting Michael Gilbert (2014-12-20 11:06:47)
> On Sat, Dec 20, 2014 at 4:59 AM, Balint Reczey wrote:
>> On Fri, 19 Dec 2014 21:11:10 -0500 Michael Gilbert wrote:
>>> control: severity -1 important
>>>
>>> There is no security support for libv8 in jessie, so security issues 
>>> aren't RC.
>> Could you please add some links to explain that?
>> I was about to fix this issue in an NMU after double-checking the 
>> fix.
>
> Severity doesn't say anything about whether or not a bugs can be 
> fixed, so you can still do that.  Anyway it was decided recently on 
> the security team ml.

I find it sensible for the security team to give up on maintaining some 
packages - and I find it great to try communicate that to our users by 
use of the debian-security-support package.

Just now I learned from above bugreport that the security team also 
actively *lower* bugreports to avoid them being treated as release 
candidate, for packages not maintained by the security team.  That I 
find a horrible approach: Severity of a bug is independent on whether it 
will be fixed or not.  The more proper tag to use is *-ignore, IMO.

Please let us not hide problems!


 - 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 (application/pgp-signature, inline)]

---

Message #89 received at 760385@bugs.debian.org (full text, mbox, reply):

On Sat, 2014-12-20 at 11:48 +0100, Jonas Smedegaard wrote:
> [sent again, cc correct list address this time]
> 
> Quoting Michael Gilbert (2014-12-20 11:06:47)
> > On Sat, Dec 20, 2014 at 4:59 AM, Balint Reczey wrote:
> >> On Fri, 19 Dec 2014 21:11:10 -0500 Michael Gilbert wrote:
> >>> control: severity -1 important
> >>>
> >>> There is no security support for libv8 in jessie, so security issues 
> >>> aren't RC.
> >> Could you please add some links to explain that?
> >> I was about to fix this issue in an NMU after double-checking the 
> >> fix.
> >
> > Severity doesn't say anything about whether or not a bugs can be 
> > fixed, so you can still do that.  Anyway it was decided recently on 
> > the security team ml.

I'm not aware of it having been decided that the security team were the
arbiters of release criticality in such situations.

> I find it sensible for the security team to give up on maintaining some 
> packages - and I find it great to try communicate that to our users by 
> use of the debian-security-support package.
> 
> Just now I learned from above bugreport that the security team also 
> actively *lower* bugreports to avoid them being treated as release 
> candidate, for packages not maintained by the security team.  That I 
> find a horrible approach: Severity of a bug is independent on whether it 
> will be fixed or not.  The more proper tag to use is *-ignore, IMO.

The setting of -ignore by people other the Release Team (or those who
have previously discussed doing so, e.g. for certain classes of bug in
stable) is still wrong.

Regards,

Adam

---

Message #94 received at 760385@bugs.debian.org (full text, mbox, reply):

Hi Mike,

On Sat, 20 Dec 2014 05:06:47 -0500 Michael Gilbert <mgilbert@debian.org>
wrote:
> On Sat, Dec 20, 2014 at 4:59 AM, Balint Reczey wrote:
> > Hi Mike,
> >
> > On Fri, 19 Dec 2014 21:11:10 -0500 Michael Gilbert
> > wrote:
> >> control: severity -1 important
> >>
> >> There is no security support for libv8 in jessie, so security issues aren't RC.
> > Could you please add some links to explain that?
> > I was about to fix this issue in an NMU after double-checking the fix.
> 
> Severity doesn't say anything about whether or not a bugs can be
> fixed, so you can still do that.  Anyway it was decided recently on
I beg to disagree here. According to freeze policy [1] only targeted
fixes for RC bugs are considered to be accepted without pre-approval to
testing now. Fixes to unstable which won't be accepted to testing are
also discouraged during the freeze.
Those implies that decreasing the severity _does_ affect if a bug should
be fixed.

Please restore the severity of this bug since it is about security flaw
and let the Release Team decide if they want to see a vulnerable libv8
in Jessie.

BTW the fix seems to be trivial and since I'm in the JavaScript team I
can actually fix it in a normal maintainer upload.

> the security team ml.
Please provide a link to a public resource to let others understand the
reasoning.

Thanks,
Balint

[1] https://release.debian.org/jessie/freeze_policy.html

---

Message #99 received at 760385@bugs.debian.org (full text, mbox, reply):

On Sat, Dec 20, 2014 at 6:15 AM, Adam D. Barratt wrote:
> On Sat, 2014-12-20 at 11:48 +0100, Jonas Smedegaard wrote:
>> [sent again, cc correct list address this time]
>>
>> Quoting Michael Gilbert (2014-12-20 11:06:47)
>> > On Sat, Dec 20, 2014 at 4:59 AM, Balint Reczey wrote:
>> >> On Fri, 19 Dec 2014 21:11:10 -0500 Michael Gilbert wrote:
>> >>> control: severity -1 important
>> >>>
>> >>> There is no security support for libv8 in jessie, so security issues
>> >>> aren't RC.
>> >> Could you please add some links to explain that?
>> >> I was about to fix this issue in an NMU after double-checking the
>> >> fix.
>> >
>> > Severity doesn't say anything about whether or not a bugs can be
>> > fixed, so you can still do that.  Anyway it was decided recently on
>> > the security team ml.
>
> I'm not aware of it having been decided that the security team were the
> arbiters of release criticality in such situations.

The severity was bumped to grave by Moritz about a month ago, likely
to get the libv8 maintainers to actually pay attention to their vast
volume of unaddressed security issues.

Now that it's been decided that libv8 won't get security support in
jessie, it seems perfectly reasonable to move back to the original
severity, which is important.

>> I find it sensible for the security team to give up on maintaining some
>> packages - and I find it great to try communicate that to our users by
>> use of the debian-security-support package.
>>
>> Just now I learned from above bugreport that the security team also
>> actively *lower* bugreports to avoid them being treated as release
>> candidate, for packages not maintained by the security team.  That I
>> find a horrible approach: Severity of a bug is independent on whether it
>> will be fixed or not.  The more proper tag to use is *-ignore, IMO.

The release team will still consider important bug fixes, you just
need to ask for
 a pre-unblock.

Best wishes,
Mike

---

Message #104 received at 760385@bugs.debian.org (full text, mbox, reply):

Control: severity -1 grave

Hi Mike,

2014-12-20 20:57 GMT+01:00 Michael Gilbert <mgilbert@debian.org>:
> On Sat, Dec 20, 2014 at 6:15 AM, Adam D. Barratt wrote:
>> On Sat, 2014-12-20 at 11:48 +0100, Jonas Smedegaard wrote:
>>> [sent again, cc correct list address this time]
>>>
>>> Quoting Michael Gilbert (2014-12-20 11:06:47)
>>> > On Sat, Dec 20, 2014 at 4:59 AM, Balint Reczey wrote:
>>> >> On Fri, 19 Dec 2014 21:11:10 -0500 Michael Gilbert wrote:
>>> >>> control: severity -1 important
>>> >>>
>>> >>> There is no security support for libv8 in jessie, so security issues
>>> >>> aren't RC.
>>> >> Could you please add some links to explain that?
>>> >> I was about to fix this issue in an NMU after double-checking the
>>> >> fix.
>>> >
>>> > Severity doesn't say anything about whether or not a bugs can be
>>> > fixed, so you can still do that.  Anyway it was decided recently on
>>> > the security team ml.
>>
>> I'm not aware of it having been decided that the security team were the
>> arbiters of release criticality in such situations.
>
> The severity was bumped to grave by Moritz about a month ago, likely
> to get the libv8 maintainers to actually pay attention to their vast
> volume of unaddressed security issues.
>
> Now that it's been decided that libv8 won't get security support in
> jessie, it seems perfectly reasonable to move back to the original
> severity, which is important.
The proper severity of this bug is grave as set by Moritz IMO. I'm
restoring it wearing my maintainer hat.
I have also checked if the fix changed the ABI using objdump (did not
change it) and uploaded a fixed version to DELAYED/2.
The fix can be found in the usual packaging repository.

Cheers,
Balint

---

Message #111 received at 760385@bugs.debian.org (full text, mbox, reply):

On Sat, Dec 20, 2014 at 7:52 PM, Bálint Réczey wrote:
> The proper severity of this bug is grave as set by Moritz IMO. I'm
> restoring it wearing my maintainer hat.

It's not really constructive arguing over severity, so that's fine.
You've saved yourself from needing to write an unblock request.

The problem still remains that the backlog of libv8 security issues
never get fixed (except for a new upstream every now and then), so
treating this one as RC but not the others is rather inconsistent:
https://security-tracker.debian.org/tracker/source-package/libv8
https://security-tracker.debian.org/tracker/source-package/libv8-3.14

Note that unimportant there indicates lack of security support for the package.

If there is interest in security support for libv8, that is a good
thing, but a lot more needs to be done for that to be true.

Best wishes,
Mike

---

Message #116 received at 760385@bugs.debian.org (full text, mbox, reply):

Hi Mike,

First, I had to cancel the upload because of too strict reverse
dependencies. Dear fellow JavaScript maintainers please figure out a
less strict dependency graph because every otherwise fully compatible
libv8 update would break several packages.

2014-12-21 2:13 GMT+01:00 Michael Gilbert <mgilbert@debian.org>:
> On Sat, Dec 20, 2014 at 7:52 PM, Bálint Réczey wrote:
>> The proper severity of this bug is grave as set by Moritz IMO. I'm
>> restoring it wearing my maintainer hat.
>
> It's not really constructive arguing over severity, so that's fine.
I appreciate the work done by the Security Team but to work together
we have to know what actions can be taken by the Security Team.
Increasing severity of bugs is business as usual and perfectly
reasonable, but _decreasing_ the severity _based on the availability
of security support_ was crossing a line IMO. It seems the line was
there based on Jonas' and Adam's email.
To clarify my position the Security Team can and is expected to
decrease the severity in case a security bug's impact turns out to be
less than originally expected but in this particular case this rule
does not seem to be applicable.

> You've saved yourself from needing to write an unblock request.
>
> The problem still remains that the backlog of libv8 security issues
> never get fixed (except for a new upstream every now and then), so
> treating this one as RC but not the others is rather inconsistent:
> https://security-tracker.debian.org/tracker/source-package/libv8
> https://security-tracker.debian.org/tracker/source-package/libv8-3.14
If there were bugs opened for those CVE-s those should have been
opened with grave severity, too.

>
> Note that unimportant there indicates lack of security support for the package.
This is confusing. Please don't mark them as unimportant because in
this context unimportant is defined differently.

https://security-tracker.debian.org/tracker/status/unimportant :
"This page lists packages that are affected by issues that are
considered unimportant from a security perspective. These issues are
thought to be unexploitable or uneffective in most situations (for
example, browser denial-of-services)."

>
> If there is interest in security support for libv8, that is a good
> thing, but a lot more needs to be done for that to be true.
Well, there is a long way to go, I agree.

Thank you for helping the Security Team and keeping the bugs and CVE-s updated.

Cheers,
Balint

---

Message #121 received at 760385@bugs.debian.org (full text, mbox, reply):

On Sun, Dec 21, 2014 at 9:11 AM, Bálint Réczey wrote:
>> The problem still remains that the backlog of libv8 security issues
>> never get fixed (except for a new upstream every now and then), so
>> treating this one as RC but not the others is rather inconsistent:
>> https://security-tracker.debian.org/tracker/source-package/libv8
>> https://security-tracker.debian.org/tracker/source-package/libv8-3.14
>
> If there were bugs opened for those CVE-s those should have been
> opened with grave severity, too.

Here you go:
http://bugs.debian.org/773671

Good luck!

Best wishes,
Mike

---

Message #128 received at 760385@bugs.debian.org (full text, mbox, reply):

Control: severity -1 serious

Dozens of unfixed CVEs, the oldest unfixed CVEs will be more than
4 years old when stretch gets released.

In the current state the package is really too buggy for shipping
in a new stable release.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

---

Message #135 received at 760385@bugs.debian.org (full text, mbox, reply):

On Tue, Feb 28, 2017 at 02:28:28PM +0200, Adrian Bunk wrote:
> Control: severity -1 serious
> 
> Dozens of unfixed CVEs, the oldest unfixed CVEs will be more than
> 4 years old when stretch gets released.
> 
> In the current state the package is really too buggy for shipping
> in a new stable release.

Note that nodejs will not be covered by security support in stretch (as it was
done for jessie already). We had initially considered it, but with
nodejs 6 not having it made into stretch, that's not realistic.

So these can be downgraded to non-RC (or if the release team thinks
nodejs should rather be remove from testing, removal is also an option
of course).

Cheers,
        Moritz

---

Message #140 received at 760385@bugs.debian.org (full text, mbox, reply):

On Mon, Apr 03, 2017 at 08:03:16PM +0200, Moritz Muehlenhoff wrote:
> On Tue, Feb 28, 2017 at 02:28:28PM +0200, Adrian Bunk wrote:
> > Control: severity -1 serious
> > 
> > Dozens of unfixed CVEs, the oldest unfixed CVEs will be more than
> > 4 years old when stretch gets released.
> > 
> > In the current state the package is really too buggy for shipping
> > in a new stable release.
> 
> Note that nodejs will not be covered by security support in stretch (as it was
> done for jessie already). We had initially considered it, but with
> nodejs 6 not having it made into stretch, that's not realistic.
> 
> So these can be downgraded to non-RC (or if the release team thinks
> nodejs should rather be remove from testing, removal is also an option
> of course).

This is not even the normal Node.js, this is a version of V8 from an 
upstream branch that is dead for 4 years already.

> Cheers,
>         Moritz

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

---

Message #145 received at 760385@bugs.debian.org (full text, mbox, reply):

On Mon, Apr 03, 2017 at 09:13:56PM +0300, Adrian Bunk wrote:
> On Mon, Apr 03, 2017 at 08:03:16PM +0200, Moritz Muehlenhoff wrote:
> > On Tue, Feb 28, 2017 at 02:28:28PM +0200, Adrian Bunk wrote:
> > > Control: severity -1 serious
> > > 
> > > Dozens of unfixed CVEs, the oldest unfixed CVEs will be more than
> > > 4 years old when stretch gets released.
> > > 
> > > In the current state the package is really too buggy for shipping
> > > in a new stable release.
> > 
> > Note that nodejs will not be covered by security support in stretch (as it was
> > done for jessie already). We had initially considered it, but with
> > nodejs 6 not having it made into stretch, that's not realistic.
> > 
> > So these can be downgraded to non-RC (or if the release team thinks
> > nodejs should rather be remove from testing, removal is also an option
> > of course).
> 
> This is not even the normal Node.js, this is a version of V8 from an 
> upstream branch that is dead for 4 years already.

Right. Initially there was some plan to provide a supported libv8
from src:nodejs, though.

libv8 has never been covered by security support in any Debian release
so far, upstream does no real security support apart from what lands
in Chrome.

Cheers,
        Moritz

---

Message #154 received at 760385@bugs.debian.org (full text, mbox, reply):

Hi,

I just realised that one of my packages does not migrate to testing due
to its dependency from r-cran-v8 and in turn from libv8-devel.  I
realised that while libv8 has 3 security bugs which are set to
stretch-ignore (#760385, #773623, #773671 - should this somehow also be
set to buster-ignore??? - I had no idea that we ignore CVEs at all but
anyway) it probably can not migrate to testing since it does not even
build:

   #853512 libv8-3.14: ftbfs with GCC-7

This bug is RC since 6 months but there is no response from any
uploader.  So I tried to clone the repository from Salsa and realised
that there is none at the place I would have expected
(https://salsa.debian.org/js-team/libv8).  Is there any other place
(besides digging into Alioth archives where I could find the
repository?)  I admit I'm not motivated to find out how to restore
old repositories but would rather use

   gbp import-dscs --ignore-repo-config --debsnap --pristine-tar libv8

instead.  Any information about the status of this package would be
really welcome.

However, when reading

   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773671#59

it might rather the best idea to remove this lib from Debian at all and
I need to see how I can avoid depending from this package.

Kind regards

       Andreas.

PS: Please CC me.  I'm not subscribed to this list.

-- 
http://fam-tille.de

---

Message #159 received at 760385@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Le ven. 18 janv. 2019 à 11:37, Andreas Tille <andreas@an3as.eu> a écrit :

> Hi,
>
> I just realised that one of my packages does not migrate to testing due
> to its dependency from r-cran-v8 and in turn from libv8-devel.  I
> realised that while libv8 has 3 security bugs which are set to
> stretch-ignore (#760385, #773623, #773671 - should this somehow also be
> set to buster-ignore??? - I had no idea that we ignore CVEs at all but
> anyway) it probably can not migrate to testing since it does not even
> build:
>
>    #853512 libv8-3.14: ftbfs with GCC-7
>
> This bug is RC since 6 months but there is no response from any
> uploader.  So I tried to clone the repository from Salsa and realised
> that there is none at the place I would have expected
> (https://salsa.debian.org/js-team/libv8).  Is there any other place
> (besides digging into Alioth archives where I could find the
> repository?)  I admit I'm not motivated to find out how to restore
> old repositories but would rather use
>
>    gbp import-dscs --ignore-repo-config --debsnap --pristine-tar libv8
>
> instead.  Any information about the status of this package would be
> really welcome.
>
> However, when reading
>
>    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773671#59
>
> it might rather the best idea to remove this lib from Debian at all and
> I need to see how I can avoid depending from this package.
>

Indeed, i am sorry for this bad state of things; i thought i could handle
it,
but obviously i couldn't.

Possible solutions (besides not using it at all):
- bundle it - nodejs bundles it
- change nodejs to build its v8 as a shared lib, and provide it
it makes sense because upstream nodejs do all the work of keeping ABI
stability,
backporting security fixes, choosing the right version, and so on.
- take over maintenance and distribute it independently of nodejs

Jérémy

[Message part 2 (text/html, inline)]

---

Message #164 received at 760385@bugs.debian.org (full text, mbox, reply):

Hi Jérémy,

On Fri, Jan 18, 2019 at 11:51:38AM +0100, Jérémy Lal wrote:
> > However, when reading
> >
> >    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773671#59
> >
> > it might rather the best idea to remove this lib from Debian at all and
> > I need to see how I can avoid depending from this package.
> 
> Indeed, i am sorry for this bad state of things; i thought i could handle
> it,
> but obviously i couldn't.
> 
> Possible solutions (besides not using it at all):
> - bundle it - nodejs bundles it
> - change nodejs to build its v8 as a shared lib, and provide it
> it makes sense because upstream nodejs do all the work of keeping ABI
> stability,
> backporting security fixes, choosing the right version, and so on.
> - take over maintenance and distribute it independently of nodejs

This sounds like a pretty sensible solution.  I see you and Jonas are
also uploaders for nodejs.  It would be really great if you could do
this.

Kind regards

       Andreas.

-- 
http://fam-tille.de

---

Send a report that this bug log contains spam.

---

Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Wed Jun 19 16:22:22 2019; Machine Name: beach

Debian Bug tracking system

Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other contributors.