libv8-3.14: multiple security issues

Debian Bug report logs - #773671
libv8-3.14: multiple security issues

Reply or subscribe to this bug.

Toggle useless messages

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

From: Michael Gilbert <mgilbert@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: libv8-3.14: multiple security issues

Date: Sun, 21 Dec 2014 15:19:42 -0500

package: src:libv8-3.14
severity: grave
tags: security

Hi,

the following vulnerabilities were published for libv8-3.14.

CVE-2013-2632[0]:
| Google V8 before 3.17.13, as used in Google Chrome before 27.0.1444.3,
| allows remote attackers to cause a denial of service (application
| crash) or possibly have unspecified other impact via crafted
| JavaScript code, as demonstrated by the Bejeweled game.

CVE-2013-2838[1]:
| Google V8, as used in Google Chrome before 27.0.1453.93, allows remote
| attackers to cause a denial of service (out-of-bounds read) via
| unspecified vectors.

CVE-2013-2882[2]:
| Google V8, as used in Google Chrome before 28.0.1500.95, allows remote
| attackers to cause a denial of service or possibly have unspecified
| other impact via vectors that leverage "type confusion."

CVE-2013-2919[3]:
| Google V8, as used in Google Chrome before 30.0.1599.66, allows remote
| attackers to cause a denial of service (memory corruption) or possibly
| have unspecified other impact via unknown vectors.

CVE-2013-6638[4]:
| Multiple buffer overflows in runtime.cc in Google V8 before 3.22.24.7,
| as used in Google Chrome before 31.0.1650.63, allow remote attackers
| to cause a denial of service or possibly have unspecified other impact
| via vectors that trigger a large typed array, related to the (1)
| Runtime_TypedArrayInitialize and (2)
| Runtime_TypedArrayInitializeFromArrayLike functions.

CVE-2013-6639[5]:
| The DehoistArrayIndex function in hydrogen-dehoist.cc (aka
| hydrogen.cc) in Google V8 before 3.22.24.7, as used in Google Chrome
| before 31.0.1650.63, allows remote attackers to cause a denial of
| service (out-of-bounds write) or possibly have unspecified other
| impact via JavaScript code that sets the value of an array element
| with a crafted index.

CVE-2013-6640[6]:
| The DehoistArrayIndex function in hydrogen-dehoist.cc (aka
| hydrogen.cc) in Google V8 before 3.22.24.7, as used in Google Chrome
| before 31.0.1650.63, allows remote attackers to cause a denial of
| service (out-of-bounds read) via JavaScript code that sets a variable
| to the value of an array element with a crafted index.

CVE-2013-6649[7]:
| Use-after-free vulnerability in the RenderSVGImage::paint function in
| core/rendering/svg/RenderSVGImage.cpp in Blink, as used in Google
| Chrome before 32.0.1700.102, allows remote attackers to cause a denial
| of service or possibly have unspecified other impact via vectors
| involving a zero-size SVG image.

CVE-2013-6650[8]:
| The StoreBuffer::ExemptPopularPages function in store-buffer.cc in
| Google V8 before 3.22.24.16, as used in Google Chrome before
| 32.0.1700.102, allows remote attackers to cause a denial of service
| (memory corruption) or possibly have unspecified other impact via
| vectors that trigger incorrect handling of "popular pages."

CVE-2013-6668[9]:
| Multiple unspecified vulnerabilities in Google V8 before 3.24.35.10,
| as used in Google Chrome before 33.0.1750.146, allow attackers to
| cause a denial of service or possibly have other impact via unknown
| vectors.

CVE-2014-1704[10]:
| Multiple unspecified vulnerabilities in Google V8 before 3.23.17.18,
| as used in Google Chrome before 33.0.1750.149, allow attackers to
| cause a denial of service or possibly have other impact via unknown
| vectors.

CVE-2014-1705[11]:
| Google V8, as used in Google Chrome before 33.0.1750.152 on OS X and
| Linux and before 33.0.1750.154 on Windows, allows remote attackers to
| cause a denial of service (memory corruption) or possibly have
| unspecified other impact via unknown vectors.

CVE-2014-1716[12]:
| Cross-site scripting (XSS) vulnerability in the Runtime_SetPrototype
| function in runtime.cc in Google V8, as used in Google Chrome before
| 34.0.1847.116, allows remote attackers to inject arbitrary web script
| or HTML via unspecified vectors, aka "Universal XSS (UXSS)."

CVE-2014-1717[13]:
| Google V8, as used in Google Chrome before 34.0.1847.116, does not
| properly use numeric casts during handling of typed arrays, which
| allows remote attackers to cause a denial of service (out-of-bounds
| array access) or possibly have unspecified other impact via crafted
| JavaScript code.

CVE-2014-1717[14]:
| Google V8, as used in Google Chrome before 34.0.1847.116, does not
| properly use numeric casts during handling of typed arrays, which
| allows remote attackers to cause a denial of service (out-of-bounds
| array access) or possibly have unspecified other impact via crafted
| JavaScript code.

CVE-2014-1729[15]:
| Multiple unspecified vulnerabilities in Google V8 before 3.24.35.22,
| as used in Google Chrome before 34.0.1847.116, allow attackers to
| cause a denial of service or possibly have other impact via unknown
| vectors.

CVE-2014-1730[16]:
| Google V8, as used in Google Chrome before 34.0.1847.131 on Windows
| and OS X and before 34.0.1847.132 on Linux, does not properly store
| internationalization metadata, which allows remote attackers to bypass
| intended access restrictions by leveraging "type confusion" and
| reading property values, related to i18n.js and runtime.cc.

CVE-2014-1735[17]:
| Multiple unspecified vulnerabilities in Google V8 before 3.24.35.33,
| as used in Google Chrome before 34.0.1847.131 on Windows and OS X and
| before 34.0.1847.132 on Linux, allow attackers to cause a denial of
| service or possibly have other impact via unknown vectors.

CVE-2014-1736[18]:
| Integer overflow in api.cc in Google V8, as used in Google Chrome
| before 34.0.1847.131 on Windows and OS X and before 34.0.1847.132 on
| Linux, allows remote attackers to cause a denial of service or
| possibly have unspecified other impact via a large length value.

CVE-2014-3152[19]:
| Integer underflow in the LCodeGen::PrepareKeyedOperand function in
| arm/lithium-codegen-arm.cc in Google V8 before 3.25.28.16, as used in
| Google Chrome before 35.0.1916.114, allows remote attackers to cause a
| denial of service or possibly have unspecified other impact via
| vectors that trigger a negative key value.

CVE-2014-3188[20]:
| Google Chrome before 38.0.2125.101 and Chrome OS before 38.0.2125.101
| do not properly handle the interaction of IPC and Google V8, which
| allows remote attackers to execute arbitrary code via vectors
| involving JSON data, related to improper parsing of an escaped index
| by ParseJsonObject in json-parser.h.

CVE-2014-3195[21]:
| Google V8, as used in Google Chrome before 38.0.2125.101, does not
| properly track JavaScript heap-memory allocations as allocations of
| uninitialized memory and does not properly concatenate arrays of
| double-precision floating-point numbers, which allows remote attackers
| to obtain sensitive information via crafted JavaScript code, related
| to the PagedSpace::AllocateRaw and NewSpace::AllocateRaw functions in
| heap/spaces-inl.h, the LargeObjectSpace::AllocateRaw function in
| heap/spaces.cc, and the Runtime_ArrayConcat function in runtime.cc.

CVE-2014-3199[22]:
| The wrap function in bindings/core/v8/custom/V8EventCustom.cpp in the
| V8 bindings in Blink, as used in Google Chrome before 38.0.2125.101,
| has an erroneous fallback outcome for wrapper-selection failures,
| which allows remote attackers to cause a denial of service via vectors
| that trigger stopping a worker process that had been handling an Event
| object.

CVE-2014-7967[23]:
| Multiple unspecified vulnerabilities in Google V8 before 3.28.71.15,
| as used in Google Chrome before 38.0.2125.101, allow attackers to
| cause a denial of service or possibly have other impact via unknown
| vectors.

These are basically untriaged since libv8 hasn't had security support
in the past.  It's up to you to get them triaged and fixed for that to
start.

If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2013-2632
[1] https://security-tracker.debian.org/tracker/CVE-2013-2838
[2] https://security-tracker.debian.org/tracker/CVE-2013-2882
[3] https://security-tracker.debian.org/tracker/CVE-2013-2919
[4] https://security-tracker.debian.org/tracker/CVE-2013-6638
[5] https://security-tracker.debian.org/tracker/CVE-2013-6639
[6] https://security-tracker.debian.org/tracker/CVE-2013-6640
[7] https://security-tracker.debian.org/tracker/CVE-2013-6649
[8] https://security-tracker.debian.org/tracker/CVE-2013-6650
[9] https://security-tracker.debian.org/tracker/CVE-2013-6668
[10] https://security-tracker.debian.org/tracker/CVE-2014-1704
[11] https://security-tracker.debian.org/tracker/CVE-2014-1705
[12] https://security-tracker.debian.org/tracker/CVE-2014-1716
[13] https://security-tracker.debian.org/tracker/CVE-2014-1717
[14] https://security-tracker.debian.org/tracker/CVE-2014-1717
[15] https://security-tracker.debian.org/tracker/CVE-2014-1729
[16] https://security-tracker.debian.org/tracker/CVE-2014-1730
[17] https://security-tracker.debian.org/tracker/CVE-2014-1735
[18] https://security-tracker.debian.org/tracker/CVE-2014-1736
[19] https://security-tracker.debian.org/tracker/CVE-2014-3152
[20] https://security-tracker.debian.org/tracker/CVE-2014-3188
[21] https://security-tracker.debian.org/tracker/CVE-2014-3195
[22] https://security-tracker.debian.org/tracker/CVE-2014-3199
[23] https://security-tracker.debian.org/tracker/CVE-2014-7967

Please adjust the affected versions in the BTS as needed.

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

From: Moritz Mühlenhoff <jmm@inutil.org>

To: 773671@bugs.debian.org

Cc: team@security.debian.org

Subject: Re: libv8-3.14: multiple security issues

Date: Mon, 29 Dec 2014 03:01:51 +0100

On Sun, Dec 21, 2014 at 03:19:42PM -0500, Michael Gilbert wrote:
> package: src:libv8-3.14
> severity: grave
> tags: security
> 
> Hi,
> 
> the following vulnerabilities were published for libv8-3.14.

So if I'm understanding the discussion on debian-devel correctly
the libv8 maintainers want to see this treated as an RC-bug.
Please clarify your intentions, do you

a) intent to fix these issues with patches and if that's not possible
remove libv8 along with its rev deps?

b) want to keep this with RC severity and tag it jessie-ignore.
I would consider that rather broken since foo-ignore is used for
issues which are ignored for once, but which will be addressed
in release+1. I don't see the libv8 situation change upstream...

c) plan something else I'm missing

Cheers,
        Moritz

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

From: Bálint Réczey <balint@balintreczey.hu>

To: Moritz Mühlenhoff <jmm@inutil.org>, 773671@bugs.debian.org

Cc: Debian Security Team <team@security.debian.org>

Subject: Re: [Pkg-javascript-devel] Bug#773671: libv8-3.14: multiple security issues

Date: Mon, 29 Dec 2014 12:28:30 +0100

Hi Moritz,

2014-12-29 3:01 GMT+01:00 Moritz Mühlenhoff <jmm@inutil.org>:
> On Sun, Dec 21, 2014 at 03:19:42PM -0500, Michael Gilbert wrote:
>> package: src:libv8-3.14
>> severity: grave
>> tags: security
>>
>> Hi,
>>
>> the following vulnerabilities were published for libv8-3.14.
>
> So if I'm understanding the discussion on debian-devel correctly
> the libv8 maintainers want to see this treated as an RC-bug.
> Please clarify your intentions, do you
>
> a) intent to fix these issues with patches and if that's not possible
> remove libv8 along with its rev deps?
>
> b) want to keep this with RC severity and tag it jessie-ignore.
> I would consider that rather broken since foo-ignore is used for
> issues which are ignored for once, but which will be addressed
> in release+1. I don't see the libv8 situation change upstream...
The rationale behind opening the RC bugs was improving transparency on
my side. I think more people follow bugs than the security tracker.
I think the call between a) and b) is up to release management, but my
interpretation for b) is a bit different.
There are RC bugs ignored for several releases thus I think foo-ignore
is not strictly for one-off issues and b) would be the proper way of
letting liv8 released with Jessie if the security issues stay open.

Cheers,
Balint



>
> c) plan something else I'm missing
>
> Cheers,
>         Moritz

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

From: Moritz Mühlenhoff <jmm@inutil.org>

To: Bálint Réczey <balint@balintreczey.hu>

Cc: 773671@bugs.debian.org, Debian Security Team <team@security.debian.org>

Subject: Re: [Pkg-javascript-devel] Bug#773671: libv8-3.14: multiple security issues

Date: Mon, 29 Dec 2014 22:04:31 +0100

On Mon, Dec 29, 2014 at 12:28:30PM +0100, Bálint Réczey wrote:
> Hi Moritz,
> 
> 2014-12-29 3:01 GMT+01:00 Moritz Mühlenhoff <jmm@inutil.org>:
> > On Sun, Dec 21, 2014 at 03:19:42PM -0500, Michael Gilbert wrote:
> >> package: src:libv8-3.14
> >> severity: grave
> >> tags: security
> >>
> >> Hi,
> >>
> >> the following vulnerabilities were published for libv8-3.14.
> >
> > So if I'm understanding the discussion on debian-devel correctly
> > the libv8 maintainers want to see this treated as an RC-bug.
> > Please clarify your intentions, do you
> >
> > a) intent to fix these issues with patches and if that's not possible
> > remove libv8 along with its rev deps?
> >
> > b) want to keep this with RC severity and tag it jessie-ignore.
> > I would consider that rather broken since foo-ignore is used for
> > issues which are ignored for once, but which will be addressed
> > in release+1. I don't see the libv8 situation change upstream...
> The rationale behind opening the RC bugs was improving transparency on
> my side. I think more people follow bugs than the security tracker.

Ok. In the past we didn't file bugs on libv8 since they were unlikely
to be dealt with anyway. We'll file bugs for any future libv8 issues.

Cheers,
        Moritz

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

From: Bálint Réczey <balint@balintreczey.hu>

To: Moritz Mühlenhoff <jmm@inutil.org>

Cc: 773671@bugs.debian.org, Debian Security Team <team@security.debian.org>, Jeroen Ooms <jeroen@berkeley.edu>

Subject: Re: [Pkg-javascript-devel] Bug#773671: libv8-3.14: multiple security issues

Date: Wed, 27 Jul 2016 11:29:16 +0200

Hi,

2014-12-29 22:04 GMT+01:00 Moritz Mühlenhoff <jmm@inutil.org>:
> On Mon, Dec 29, 2014 at 12:28:30PM +0100, Bálint Réczey wrote:
>> Hi Moritz,
>>
>> 2014-12-29 3:01 GMT+01:00 Moritz Mühlenhoff <jmm@inutil.org>:
>> > On Sun, Dec 21, 2014 at 03:19:42PM -0500, Michael Gilbert wrote:
>> >> package: src:libv8-3.14
>> >> severity: grave
>> >> tags: security
>> >>
>> >> Hi,
>> >>
>> >> the following vulnerabilities were published for libv8-3.14.
>> >
>> > So if I'm understanding the discussion on debian-devel correctly
>> > the libv8 maintainers want to see this treated as an RC-bug.
>> > Please clarify your intentions, do you
>> >
>> > a) intent to fix these issues with patches and if that's not possible
>> > remove libv8 along with its rev deps?
>> >
>> > b) want to keep this with RC severity and tag it jessie-ignore.
>> > I would consider that rather broken since foo-ignore is used for
>> > issues which are ignored for once, but which will be addressed
>> > in release+1. I don't see the libv8 situation change upstream...
>> The rationale behind opening the RC bugs was improving transparency on
>> my side. I think more people follow bugs than the security tracker.
>
> Ok. In the past we didn't file bugs on libv8 since they were unlikely
> to be dealt with anyway. We'll file bugs for any future libv8 issues.
>
> Cheers,
>         Moritz

There seem to be people working on the security backports which
may help in keeping libv8-3.14 in better shape:

---------- Forwarded message ----------
From: Jeroen Ooms <jeroen@berkeley.edu>
Date: 2016-07-25 14:01 GMT+02:00
Subject: libv8-3.14 patches
To: Jérémy Lal <kapouer@melix.org>, Jonas Smedegaard <dr@jones.dk>,
Balint Reczey <balint@balintreczey.hu>


Hi!

I am contacting you as maintainers of the libv8-3.14 Debian package.
Thank you for your work on this package.

We have recently backported important fixes and CVE's to the 3.14
branch of V8. This was mostly done by Tom Callaway from Redhat for the
new "v8-314" rpm package in Fedora.

 - https://bugzilla.redhat.com/show_bug.cgi?id=1344415
 - https://github.com/v8-314/v8
 - https://groups.google.com/forum/#!topic/v8-dev/qm8c3Hz43bI

I thought it might be useful to point this out, perhaps some fixes
could be adopted by Debian as well. We tried to persuade the v8
developers to do an official patch release on the 3.14 branch but they
don't seem to bother.

Some background: at UC Berkeley we have developed an extensive
scientific toolkit for geospatial analysis based on libv8 which is in
use by many scientists and ecologists. However because Google keeps
breaking the v8 API it is important to use that at least the
libv8-3.14 package will remain available on popular linux
distributions.

Thanks again,

Jeroen Ooms

----8<----

The .spec file linked from the Red Hat bugzilla lists CVE-s fixed:
https://spot.fedorapeople.org/v8-314.spec

Thanks to Jeroen for contacting us.

Cheers,
Balint

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

From: Jérémy Lal <kapouer@melix.org>

To: balint@balintreczey.hu, 773671@bugs.debian.org

Subject: Re: Bug#773671: [Pkg-javascript-devel] Bug#773671: libv8-3.14: multiple security issues

Date: Wed, 27 Jul 2016 12:14:02 +0200

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

2016-07-27 11:29 GMT+02:00 Bálint Réczey <balint@balintreczey.hu>:

> Hi,
>
> 2014-12-29 22:04 GMT+01:00 Moritz Mühlenhoff <jmm@inutil.org>:
> > On Mon, Dec 29, 2014 at 12:28:30PM +0100, Bálint Réczey wrote:
> >> Hi Moritz,
> >>
> >> 2014-12-29 3:01 GMT+01:00 Moritz Mühlenhoff <jmm@inutil.org>:
> >> > On Sun, Dec 21, 2014 at 03:19:42PM -0500, Michael Gilbert wrote:
> >> >> package: src:libv8-3.14
> >> >> severity: grave
> >> >> tags: security
> >> >>
> >> >> Hi,
> >> >>
> >> >> the following vulnerabilities were published for libv8-3.14.
> >> >
> >> > So if I'm understanding the discussion on debian-devel correctly
> >> > the libv8 maintainers want to see this treated as an RC-bug.
> >> > Please clarify your intentions, do you
> >> >
> >> > a) intent to fix these issues with patches and if that's not possible
> >> > remove libv8 along with its rev deps?
> >> >
> >> > b) want to keep this with RC severity and tag it jessie-ignore.
> >> > I would consider that rather broken since foo-ignore is used for
> >> > issues which are ignored for once, but which will be addressed
> >> > in release+1. I don't see the libv8 situation change upstream...
> >> The rationale behind opening the RC bugs was improving transparency on
> >> my side. I think more people follow bugs than the security tracker.
> >
> > Ok. In the past we didn't file bugs on libv8 since they were unlikely
> > to be dealt with anyway. We'll file bugs for any future libv8 issues.
> >
> > Cheers,
> >         Moritz
>
> There seem to be people working on the security backports which
> may help in keeping libv8-3.14 in better shape:
>
> ---------- Forwarded message ----------
> From: Jeroen Ooms <jeroen@berkeley.edu>
> Date: 2016-07-25 14:01 GMT+02:00
> Subject: libv8-3.14 patches
> To: Jérémy Lal <kapouer@melix.org>, Jonas Smedegaard <dr@jones.dk>,
> Balint Reczey <balint@balintreczey.hu>
>
>
> Hi!
>
> I am contacting you as maintainers of the libv8-3.14 Debian package.
> Thank you for your work on this package.
>
> We have recently backported important fixes and CVE's to the 3.14
> branch of V8. This was mostly done by Tom Callaway from Redhat for the
> new "v8-314" rpm package in Fedora.
>
>  - https://bugzilla.redhat.com/show_bug.cgi?id=1344415
>  - https://github.com/v8-314/v8
>  - https://groups.google.com/forum/#!topic/v8-dev/qm8c3Hz43bI
>
> I thought it might be useful to point this out, perhaps some fixes
> could be adopted by Debian as well. We tried to persuade the v8
> developers to do an official patch release on the 3.14 branch but they
> don't seem to bother.
>
> Some background: at UC Berkeley we have developed an extensive
> scientific toolkit for geospatial analysis based on libv8 which is in
> use by many scientists and ecologists. However because Google keeps
> breaking the v8 API it is important to use that at least the
> libv8-3.14 package will remain available on popular linux
> distributions.
>
> Thanks again,
>
> Jeroen Ooms
>
> ----8<----
>
> The .spec file linked from the Red Hat bugzilla lists CVE-s fixed:
> https://spot.fedorapeople.org/v8-314.spec
>
> Thanks to Jeroen for contacting us.
>
> Cheers,
> Balint
>
>

Yes, i'm busy right now, and am also currently writing a Request for Help
on solving different issues with v8/nodejs.

Jérémy

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

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

From: Jeroen Ooms <jeroen@berkeley.edu>

To: Bálint Réczey <balint@balintreczey.hu>

Cc: Moritz Mühlenhoff <jmm@inutil.org>, 773671@bugs.debian.org, Debian Security Team <team@security.debian.org>

Subject: Re: [Pkg-javascript-devel] Bug#773671: libv8-3.14: multiple security issues

Date: Sat, 30 Jul 2016 16:25:17 +0200

On Wed, Jul 27, 2016 at 11:29 AM, Bálint Réczey <balint@balintreczey.hu> wrote:
>
> The .spec file linked from the Red Hat bugzilla lists CVE-s fixed:
> https://spot.fedorapeople.org/v8-314.spec
>
> Thanks to Jeroen for contacting us.

Let us know if there is anything we can do to help keep libv8-3.14
supported in Debian. We have a many software packages and researchers
depending on this version at UC Berkeley.

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

From: Adrian Bunk <bunk@debian.org>

To: 760385@bugs.debian.org, 773623@bugs.debian.org, 773671@bugs.debian.org

Subject: Unfixed old CVEs should really be RC

Date: Tue, 28 Feb 2017 14:28:28 +0200

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 #49 received at 773671@bugs.debian.org (full text, mbox, reply):

From: Moritz Muehlenhoff <jmm@inutil.org>

To: Adrian Bunk <bunk@debian.org>

Cc: 760385@bugs.debian.org, 773623@bugs.debian.org, 773671@bugs.debian.org

Subject: Re: Unfixed old CVEs should really be RC

Date: Mon, 3 Apr 2017 20:03:16 +0200

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 #54 received at 773671@bugs.debian.org (full text, mbox, reply):

From: Adrian Bunk <bunk@debian.org>

To: Moritz Muehlenhoff <jmm@inutil.org>

Cc: 760385@bugs.debian.org, 773623@bugs.debian.org, 773671@bugs.debian.org

Subject: Re: Unfixed old CVEs should really be RC

Date: Mon, 3 Apr 2017 21:13:56 +0300

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 #59 received at 773671@bugs.debian.org (full text, mbox, reply):

From: Moritz Muehlenhoff <jmm@inutil.org>

To: Adrian Bunk <bunk@debian.org>

Cc: 760385@bugs.debian.org, 773623@bugs.debian.org, 773671@bugs.debian.org

Subject: Re: Unfixed old CVEs should really be RC

Date: Mon, 3 Apr 2017 21:01:34 +0200

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 #68 received at 773671@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <andreas@an3as.eu>

To: Debian Javascript Maintainers <pkg-javascript-devel@lists.alioth.debian.org>, Jérémy Lal <kapouer@melix.org>, Jonas Smedegaard <dr@jones.dk>, Balint Reczey <balint@balintreczey.hu>

Cc: 853512@bugs.debian.org, 760385@bugs.debian.org, 773623@bugs.debian.org, 773671@bugs.debian.org

Subject: Status of libv8?

Date: Fri, 18 Jan 2019 11:37:30 +0100

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 #73 received at 773671@bugs.debian.org (full text, mbox, reply):

From: Jérémy Lal <kapouer@melix.org>

To: Andreas Tille <andreas@an3as.eu>

Cc: Debian Javascript Maintainers <pkg-javascript-devel@lists.alioth.debian.org>, Jonas Smedegaard <dr@jones.dk>, Balint Reczey <balint@balintreczey.hu>, 853512@bugs.debian.org, 760385@bugs.debian.org, 773623@bugs.debian.org, 773671@bugs.debian.org

Subject: Re: Status of libv8?

Date: Fri, 18 Jan 2019 11:51:38 +0100

[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 #78 received at 773671@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <andreas@an3as.eu>

To: Jérémy Lal <kapouer@melix.org>

Cc: Debian Javascript Maintainers <pkg-javascript-devel@lists.alioth.debian.org>, Jonas Smedegaard <dr@jones.dk>, Balint Reczey <balint@balintreczey.hu>, 853512@bugs.debian.org, 760385@bugs.debian.org, 773623@bugs.debian.org, 773671@bugs.debian.org

Subject: Re: Status of libv8?

Date: Fri, 18 Jan 2019 13:04:30 +0100

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.