Currently when configuring --without-ssl the following warning is
displayed:
WARNING: openssl_no_asm is enabled due to missed or old assembler.
Please refer BUILDING.md
This commit adds a check of options.without_ssl to avoid this warning
when --without-ssl is used.
PR-URL: https://github.com/nodejs/node/pull/19934
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
- For Windows, nasm is new build requirements and openssl_no_asm is
set to 1 with warning if it is not installed.
- For use of openssl assemble codes, either gas_version >= 2.23,
xcode_version >= 5.0 ,llvm_version >= 3.3 or nasm_version >= 2.10 is
needed. Otherwise, openssl_no_asm is set to 1 with warning.
- FIPS is not supported in OpenSSL-1.1.0 so that it leads an error
when openssl_fips options is enabled in configure.
Fixes: https://github.com/nodejs/node/issues/4270
PR-URL: https://github.com/nodejs/node/pull/19794
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rod Vagg <rod@vagg.org>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
The version of nghttp2 in deps/ does not build on CloudABI, even though
the official version does. Though this is an issue on its own that needs
to be resolved, it is currently a bit hard to work around this. There is
no switch to link against an external version of nghttp2, even though we
do provide this option for other libraries.
This change adds configure flags, similar to the ones we have for
OpenSSL, zlib, http_parser, libuv, etc. and makes the dependency on
deps/nghttp2 optional.
PR-URL: https://github.com/nodejs/node/pull/16788
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Refael Ackermann <refack@gmail.com>
The motivation for this commit is that we need to specify system CA
certificates when building node. While we are aware of the environment
variable NODE_EXTRA_CA_CERTS this is not a great solution as we build
an RPM and we also don't want users to be able to unset them.
The suggestion is to add a configure time property like this:
--openssl-system-ca-path=OPENSSL_SYSTEM_CA_PATH
Use the specified path to system CA (PEM format) in
addition to the OpenSSL supplied CA store or compiled-
in Mozilla CA copy.
Usage example:
$ ./configure --openssl-system-ca-path=/etc/pki/tls/certs/ca-bundle.crt
This would add the specified CA certificates in addition to the ones
already being used.
PR-URL: https://github.com/nodejs/node/pull/16790
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
CloudABI is a compact POSIX-like runtime that makes use of
capability-based security. More details:
https://github.com/NuxiNL/cloudlibc
* src: Disable use of pwd.h, grp.h and get*uid() on CloudABI.
As CloudABI is intended to run applications in cluster contexts (e.g.,
on Kubernetes), they are oblivious of UNIX credentials. Extend the
existing preprocessor checks to disable any use of these interfaces,
just like on Windows, Android, etc.
* src: Explicitly include <netdb.h>.
cares_wrap.cc calls into functions like getnameinfo() and getaddrinfo().
These functions tend to be available implicitly through <uv.h>, but we'd
better still include this header explicitly.
On CloudABI, we make use of a custom implementation of libuv that does
not implicitly include header files like <netdb.h>.
PR-URL: https://github.com/nodejs/node/pull/16612
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Currently the help message when using --with-lttng looks like this:
$ ./configure --help | grep 'with-lttng'
--with-lttng build with Lttng (Only available to Linux)
This commit makes the help message consistent with the error message
that is raised if --with-lttng is used on a non-Linux operating
system:
$ ./configure --help | grep 'with-lttng'
--with-lttng build with Lttng (Only available on Linux)
PR-URL: https://github.com/nodejs/node/pull/16101
Reviewed-By: Lance Ball <lball@redhat.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Currently the options available for HTTP2 are not displayed when running
configure --help.
This commit enables the following HTTP2 section to be included in the
help output:
HTTP2:
Flags that allows you to control HTTP2 features in Node.js
--debug-http2 build with http2 debug statements on (default is
false)
--debug-nghttp2 build nghttp2 with DEBUGBUILD (default is false)
PR-URL: https://github.com/nodejs/node/pull/15198
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Evan Lucas <evanlucas@me.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Currently when building with --enable-static and running the test target
the following error will be reported:
Building addon
/node/test/addons/01_function_arguments/
env: ./node: No such file or directory
make[1]: *** [test/addons/.buildstamp] Error 1
Note that this is with a clean build where no prior node executable was
built.
This commit suggests only running the cctest target when --enable-static
is specified.
PR-URL: https://github.com/nodejs/node/pull/14892
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Lance Ball <lball@redhat.com>
Improve support for systems where `python` is actually `python3`.
Not all systems have a `python2` binary, so simply updating the shebang
won't work.
What we can do is apply some cleverness: start life as a shell script,
locate the python binary, then re-execute the script but this time as
python code.
Special care is taken to ensure that spaces in arguments are passed on
verbatim.
PR-URL: https://github.com/nodejs/node/pull/14737
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
At long last: The initial *experimental* implementation of HTTP/2.
This is an accumulation of the work that has been done in the nodejs/http2
repository, squashed down to a couple of commits. The original commit
history has been preserved in the nodejs/http2 repository.
This PR introduces the nghttp2 C library as a new dependency. This library
provides the majority of the HTTP/2 protocol implementation, with the rest
of the code here providing the mapping of the library into a usable JS API.
Within src, a handful of new node_http2_*.c and node_http2_*.h files are
introduced. These provide the internal mechanisms that interface with nghttp
and define the `process.binding('http2')` interface.
The JS API is defined within `internal/http2/*.js`.
There are two APIs provided: Core and Compat.
The Core API is HTTP/2 specific and is designed to be as minimal and as
efficient as possible.
The Compat API is intended to be as close to the existing HTTP/1 API as
possible, with some exceptions.
Tests, documentation and initial benchmarks are included.
The `http2` module is gated by a new `--expose-http2` command line flag.
When used, `require('http2')` will be exposed to users. Note that there
is an existing `http2` module on npm that would be impacted by the introduction
of this module, which is the main reason for gating this behind a flag.
When using `require('http2')` the first time, a process warning will be
emitted indicating that an experimental feature is being used.
To run the benchmarks, the `h2load` tool (part of the nghttp project) is
required: `./node benchmarks/http2/simple.js benchmarker=h2load`. Only
two benchmarks are currently available.
Additional configuration options to enable verbose debugging are provided:
```
$ ./configure --debug-http2 --debug-nghttp2
$ NODE_DEBUG=http2 ./node
```
The `--debug-http2` configuration option enables verbose debug statements
from the `src/node_http2_*` files. The `--debug-nghttp2` enables the nghttp
library's own verbose debug output. The `NODE_DEBUG=http2` enables JS-level
debug output.
The following illustrates as simple HTTP/2 server and client interaction:
(The HTTP/2 client and server support both plain text and TLS connections)
```jt client = http2.connect('http://localhost:80');
const req = client.request({ ':path': '/some/path' });
req.on('data', (chunk) => { /* do something with the data */ });
req.on('end', () => {
client.destroy();
});
// Plain text (non-TLS server)
const server = http2.createServer();
server.on('stream', (stream, requestHeaders) => {
stream.respond({ ':status': 200 });
stream.write('hello ');
stream.end('world');
});
server.listen(80);
```
```js
const http2 = require('http2');
const client = http2.connect('http://localhost');
```
Author: Anna Henningsen <anna@addaleax.net>
Author: Colin Ihrig <cjihrig@gmail.com>
Author: Daniel Bevenius <daniel.bevenius@gmail.com>
Author: James M Snell <jasnell@gmail.com>
Author: Jun Mukai
Author: Kelvin Jin
Author: Matteo Collina <matteo.collina@gmail.com>
Author: Robert Kowalski <rok@kowalski.gd>
Author: Santiago Gimeno <santiago.gimeno@gmail.com>
Author: Sebastiaan Deckers <sebdeckers83@gmail.com>
Author: Yosuke Furukawa <yosuke.furukawa@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/14239
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
The ability to set the link rule is used for FIPS, and needs to set
both the `ld =` and `ldxx =` variables in the ninja build file to link
c++ (node) and c (openssl-cli, etc.) executables.
URL: https://github.com/nodejs/node/pull/14227
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Currently when configuring the project using --openssl-fips a gyp
include file name config_fips.gypi will be created. If the project is
later configured but without the --openssl-fips flag an error will
occur. For example:
$ ./configure --openssl-fips=bogus
$ ./configure && make -j8
...
/node/deps/openssl/fips/fipsld:
line 8: /bin/fipsld: No such file or directory
Error 127
This commit suggests removing the generate config_fips.gypi when the
--openssl-fips flag is not give on the command line.
PR-URL: https://github.com/nodejs/node/pull/13837
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Promises do not have any internal fields by default. V8 recently added
the capability of configuring the number of internal fields on promises.
This change adds an internal field to promises allowing promises to be
wrapped directly by the PromiseWrap object. In addition to cleaner code
this avoids an extra object allocation per promise and speeds up promise
creation with async_hooks enabled by ~2x.
PR-URL: https://github.com/nodejs/node/pull/13242
Ref: https://github.com/nodejs/node/pull/13224
Reviewed-By: Andreas Madsen <amwebdk@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Not all CLI options are supported, those that are problematic from a
security or implementation point of view are disallowed, as are ones
that are inappropriate (for example, -e, -p, --i), or that only make
sense when changed with code changes (such as options that change the
javascript syntax or add new APIs).
PR-URL: https://github.com/nodejs/node/pull/12028
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: Bradley Farias <bradley.meck@gmail.com>
Currently it is possible to configure using --without-ssl and
--shared-openssl/--openssl-no-asm/openssl-fips without an error
occuring.
The commit add check for these combinations:
$ ./configure --without-ssl --shared-openssl
Error: --without-ssl is incompatible with --shared-openssl
$ ./configure --without-ssl --openssl-no-asm
Error: --without-ssl is incompatible with --openssl-no-asm
$ ./configure --without-ssl --openssl-fips=dummy
Error: --without-ssl is incompatible with --openssl-fips
PR-URL: https://github.com/nodejs/node/pull/12175
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
