`timezone` variable contains the difference, in seconds, between UTC and
local standard time (see `man 3 localtime` on Solaris).
Call to `tzset` is required to apply contents of `TZ` variable to
`timezone` variable.
BUG=v8:2064
Review URL: https://chromiumcodereview.appspot.com/10967066
Patch from Maciej Małecki <me@mmalecki.com>.
This is a back-port of upstream commit r12802.
This reverts commit 1c88c3b3b5.
It breaks the "read a password from stdin" functionality that OpenSSL provides.
Fixes#4059, #4143.
Conflicts:
deps/openssl/openssl.gyp
When perlasm generates MASM code it sets the assembler target to 468.
In this mode MASM refuses to assemble the CPUID instruction. Bumping
the target to 586 solves this problem.
These patches were provided by Android and Chromium. In this form they
are not useful. The ones that we need are landed as separate commits.
As of openssl 1.0.1c, three of them made it upstream:
* npn.patch (Next Protocol Negotiation support)
* tls_exporter.patch (RFC 5705 Keying Material Exporters for TLS)
* openssl_no_dtls1.patch (minor bugfix)
Use a empty implementation for function OPENSSL_cpuid_setup to resolve link
error. We should figure out how to geenrate platform specific implementation
of OPENSSL_cpuid_setup by leveraging crypto/*cpuid.pl.
This patch is taken from Chromium.
ASN1_STRING_to_UTF8() passes an ASN1_STRING to ASN1_STRING_set() but
forgot to initialize the `length` field.
Fixes the following valgrind error:
$ valgrind -q --track-origins=yes --num-callers=19 \
out/Debug/node test/simple/test-tls-client-abort.js
==2690== Conditional jump or move depends on uninitialised value(s)
==2690== at 0x784B69: ASN1_STRING_set (asn1_lib.c:382)
==2690== by 0x809564: ASN1_mbstring_ncopy (a_mbstr.c:204)
==2690== by 0x8090F0: ASN1_mbstring_copy (a_mbstr.c:86)
==2690== by 0x782F1F: ASN1_STRING_to_UTF8 (a_strex.c:570)
==2690== by 0x78F090: asn1_string_canon (x_name.c:409)
==2690== by 0x78EF17: x509_name_canon (x_name.c:354)
==2690== by 0x78EA7D: x509_name_ex_d2i (x_name.c:210)
==2690== by 0x788058: ASN1_item_ex_d2i (tasn_dec.c:239)
==2690== by 0x7890D4: asn1_template_noexp_d2i (tasn_dec.c:746)
==2690== by 0x788CB6: asn1_template_ex_d2i (tasn_dec.c:607)
==2690== by 0x78877A: ASN1_item_ex_d2i (tasn_dec.c:448)
==2690== by 0x7890D4: asn1_template_noexp_d2i (tasn_dec.c:746)
==2690== by 0x788CB6: asn1_template_ex_d2i (tasn_dec.c:607)
==2690== by 0x78877A: ASN1_item_ex_d2i (tasn_dec.c:448)
==2690== by 0x787C93: ASN1_item_d2i (tasn_dec.c:136)
==2690== by 0x78F5E4: d2i_X509 (x_x509.c:141)
==2690== by 0x7C9B91: PEM_ASN1_read_bio (pem_oth.c:81)
==2690== by 0x7CA506: PEM_read_bio_X509 (pem_x509.c:67)
==2690== by 0x703C9A: node::crypto::SecureContext::AddRootCerts(v8::Arguments const&) (node_crypto.cc:497)
==2690== Uninitialised value was created by a stack allocation
==2690== at 0x782E89: ASN1_STRING_to_UTF8 (a_strex.c:560)
There are many symbolic links under /etc/ssl/certs created by using hash of
the pem certificates in order for OpenSSL to find those certificate.
Openssl has a tool to help you create hash symbolic links. (See tools/c_rehash)
However the new openssl changed the hash algorithm, Unless you compile/install
the latest openssl library and re-create all related symbolic links, the new
openssl can not find some certificates because the links of those certificates
were created by using old hash algorithm, which causes some tests failed.
This patch gives a way to find a certificate according to its hash by using both
new algorithm and old algorithm.
crbug.com/111045 is used to track this issue.
This patch is taken from the Chromium project.