Our out-of-tree patch from 2b6bb9f588 ("deps: c-ares float, win ipv6 bad
fec0 prefix") should no longer be necessary, c-ares now blacklists such
addresses itself.
PR-URL: https://github.com/nodejs/node/pull/23854
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Remove leftover files that were added in commit 58e4edaf68 from 2013
to help with standalone builds of the c-ares fork that we maintained
at the time.
PR-URL: https://github.com/nodejs/node/pull/23854
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
This file was left out of the c-ares 1.14.0 update.
PR-URL: https://github.com/nodejs/node/pull/23682
Fixes: https://github.com/nodejs/node/issues/23681
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Denys Otrishko <shishugi@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
c-ares switched to using ares_ssize_t for platform-independent ssize_t,
our GYP usage to include config/<platform>/ares_config.h causes problems
when including gyp as a library in core, i.e. in env.h and cares_wrap.h,
where the defines don't get pulled in properly. This, so far, is the
easiest approach to just making it work nicely--explicitly defining
ares_ssize_t for the different Windows variants and ssize_t for
non-Windows where we don't have a configured type from an ares_config.h.
In all of our non-Windows platforms it is ssize_t anyway so this is
safe.
PR-URL: https://github.com/nodejs/node/pull/15378
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
PR-URL: https://github.com/nodejs/node/pull/19939
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
* Fix patch for CVE-2017-1000381 to not be overly aggressive.
* win32: Preserve DNS server order returned by Windows when sorting and
exclude DNS servers in legacy subnets.
* win32: Support most recent Visual Studio 2017.
* gethostbyaddr should fail with ECANCELLED not ENOTFOUND when
ares_cancel is called.
* win32: Exclude legacy ipv6 subnets.
* android: Applications compiled for Oreo can no longer use
__system_property_get and must use Java calls to retrieve DNS
servers.
* win32: Force use of ANSI functions.
* CMake minimum version is now 3.1.
* ares_gethostbyname.3: fix callback status values.
* docs: Document WSAStartup requirement.
* Fix a typo in init_by_resolv_conf.
* Android JNI code leaks local references in some cases.
* Force using the ANSI versions of WinAPI functions.
The most important changes have already been included via
* 50e580df21 deps: cherry-pick 0ef4a0c64b6 from c-ares upstream
* 9a0631dffe deps: cherry-pick 18ea996 from c-ares upstream
PR-URL: https://github.com/nodejs/node/pull/19939
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Original commit message:
gethostbyaddr: fail with `ECANCELLED` for `ares_cancel()`
When `ares_cancel()` was invoked, `ares_gethostbyaddr()`
queries would fail with `ENOTFOUND` instead of `ECANCELLED`.
It seems appropriate to treat `ares_cancel()` like `ares_destroy()`,
but I would appreciate review of the correctness of this change.
Ref: https://github.com/nodejs/node/issues/14814
Fixes: https://github.com/nodejs/node/issues/14814
PR-URL: https://github.com/nodejs/node/pull/15023
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Original commit message:
ares_parse_naptr_reply: make buffer length check more accurate
9478908a490a6bf009ba58d81de8c1d06d50a117 introduced a length check
for records parsed by `ares_parse_naptr_reply()`. However, that
function is designed to parse replies which also contain non-NAPTR
records; for A records, the `rr_len > 7` check will fail as there
are only 4 bytes of payload.
In particular, parsing ANY replies for NAPTR records was broken
by that patch.
Fix that by moving the check into the case in which it is already
known that the record is a NAPTR record.
Ref: 18ea99693d
PR-URL: https://github.com/nodejs/node/pull/13883
Reviewed-By: James M Snell <jasnell@gmail.com>
c-ares switched to using ares_ssize_t for platform-independent ssize_t,
our GYP usage to include config/<platform>/ares_config.h causes problems
when including gyp as a library in core, i.e. in env.h and cares_wrap.h,
where the defines don't get pulled in properly. This, so far, is the
easiest approach to just making it work nicely--explicitly defining
ares_ssize_t for the different Windows variants and ssize_t for
non-Windows where we don't have a configured type from an ares_config.h.
In all of our non-Windows platforms it is ssize_t anyway so this is
safe.
PR-URL: https://github.com/nodejs/node/pull/15378
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Updated with manual config for Android
Updated with automatic for sunos, *bsd, darwin, linux, aix
PR-URL: https://github.com/nodejs/node/pull/15378
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Original commit message:
gethostbyaddr: fail with `ECANCELLED` for `ares_cancel()`
When `ares_cancel()` was invoked, `ares_gethostbyaddr()`
queries would fail with `ENOTFOUND` instead of `ECANCELLED`.
It seems appropriate to treat `ares_cancel()` like `ares_destroy()`,
but I would appreciate review of the correctness of this change.
Ref: https://github.com/nodejs/node/issues/14814
Fixes: https://github.com/nodejs/node/issues/14814
PR-URL: https://github.com/nodejs/node/pull/15023
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Original commit message:
ares_parse_naptr_reply: make buffer length check more accurate
9478908a490a6bf009ba58d81de8c1d06d50a117 introduced a length check
for records parsed by `ares_parse_naptr_reply()`. However, that
function is designed to parse replies which also contain non-NAPTR
records; for A records, the `rr_len > 7` check will fail as there
are only 4 bytes of payload.
In particular, parsing ANY replies for NAPTR records was broken
by that patch.
Fix that by moving the check into the case in which it is already
known that the record is a NAPTR record.
Ref: 18ea99693d
PR-URL: https://github.com/nodejs/node/pull/13883
Reviewed-By: James M Snell <jasnell@gmail.com>
Original commit message:
ares_parse_naptr_reply: check sufficient data
Check that there is enough data for the required elements
of an NAPTR record (2 int16, 3 bytes for string lengths)
before processing a record.
This patch fixes CVE-2017-1000381
The c-ares function ares_parse_naptr_reply(), which is used for
parsing NAPTR responses, could be triggered to read memory outside
of the given input buffer if the passed in DNS response packet was
crafted in a particular way.
Refs: https://c-ares.haxx.se/adv_20170620.html
Refs: https://c-ares.haxx.se/CVE-2017-1000381.patch
PR-URL: https://github.com/nodejs/node-private/pull/88
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Depend on include/ares_rules.h, src/ares_rules.h does not exist.
The typo didn't break the build but it made some of the gyp-based
tooling complain.
PR-URL: https://github.com/nodejs/node/pull/7945
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Evan Lucas <evanlucas@me.com>
Many places in cares library, when the stream data arrives
from the network with respect to dns and reverse dns
resolution, they are populated into data structures created
dymaically based on the size of the data. Malloc is heavily
used for such cases.
Often, based on the data length, malloc(0) is invoked. Linux
behavior on zero byte allocation is to return a valid pointer
where in AIX, it always return NULL.
This manifestst as test failure of test/internet/test-dns.js
Solution is to build cares with Linux compatible malloc behavior
PR-URL: https://github.com/nodejs/node/pull/6305
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-by: Michael Dawson <michael_dawson@ca.ibm.com>
On Windows, when compiling with `UNICODE` defined, `LoadLibrary` becomes
`LoadLibraryW`. When an ASCII string is passed to that function it
crashes.
PR-URL: https://github.com/iojs/io.js/pull/226
Reviewed-By: Bert Belder <bertbelder@gmail.com>
These are the core changes that allow AIX to compile. There
are still some test failures as there are some patches needed for
libuv and npm that we'll need to contribute through those
communities but this set allows node to be built on AIX and
pass most of the core tests
The change in js2c is because AIX does not support $ in
identifier names. See the discussion/agreement in
https://github.com/nodejs/node/issues/2272
PR-URL: https://github.com/nodejs/node/pull/2364
Reviewed-By: Ben Noordhuis <ben@strongloop.com>
Reviewed-By: Rod Vagg <r@va.gg>
On Windows, when compiling with `UNICODE` defined, `LoadLibrary` becomes
`LoadLibraryW`. When an ASCII string is passed to that function it
crashes.
PR-URL: https://github.com/iojs/io.js/pull/226
Reviewed-By: Bert Belder <bertbelder@gmail.com>
On Windows, when compiling with `UNICODE` defined, `LoadLibrary` becomes
`LoadLibraryW`. When an ASCII string is passed to that function it
crashes.
PR-URL: https://github.com/iojs/io.js/pull/226
Reviewed-By: Bert Belder <bertbelder@gmail.com>
