June 2018 - tor-commits - lists.torproject.org

[tor/master] Bug 26121: Improve BUILDTIMEOUT_SET accuracy.
by nickm＠torproject.org 02 Jun '18

02 Jun '18

commit fe5764012a05e5d9382e1a59d015ff6ca0bd804b Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Wed May 16 06:42:41 2018 +0000 Bug 26121: Improve BUILDTIMEOUT_SET accuracy. We were miscounting the total number of circuits for the TIMEOUT_RATE and CLOSE_RATE fields of this event. --- changes/bug26121 | 6 ++++++ src/or/circuitstats.c | 15 +++++++++++---- 2 files changed, 17 insertions(+), 4 deletions(-) diff --git a/changes/bug26121 b/changes/bug26121 new file mode 100644 index 000000000..5f734dd56 --- /dev/null +++ b/changes/bug26121 @@ -0,0 +1,6 @@ + o Minor bugfixes (controller): + - Improve accuracy of the BUILDTIMEOUT_SET control port event's + TIMEOUT_RATE and CLOSE_RATE fields. (We were previously miscounting + the total number of circuits for these field values.) Fixes bug + 26121; bugfix on 0.3.3.1-alpha. + diff --git a/src/or/circuitstats.c b/src/or/circuitstats.c index f87bbd822..f06c2e5e3 100644 --- a/src/or/circuitstats.c +++ b/src/or/circuitstats.c @@ -1908,13 +1908,20 @@ cbt_control_event_buildtimeout_set(const circuit_build_times_t *cbt, /* The timeout rate is the ratio of the timeout count over * the total number of circuits attempted. The total number of - * circuits is (timeouts+succeeded+closed), since a circuit can - * either timeout, close, or succeed. We cast the denominator + * circuits is (timeouts+succeeded), since every circuit + * either succeeds, or times out. "Closed" circuits are + * MEASURE_TIMEOUT circuits whose measurement period expired. + * All MEASURE_TIMEOUT circuits are counted in the timeouts stat + * before transitioning to MEASURE_TIMEOUT (in + * circuit_build_times_mark_circ_as_measurement_only()). + * MEASURE_TIMEOUT circuits that succeed are *not* counted as + * "succeeded". See circuit_build_times_handle_completed_hop(). + * + * We cast the denominator * to promote it to double before the addition, to avoid int32 * overflow. */ const double total_circuits = - ((double)cbt->num_circ_timeouts) + cbt->num_circ_succeeded - + cbt->num_circ_closed; + ((double)cbt->num_circ_timeouts) + cbt->num_circ_succeeded; if (total_circuits >= 1.0) { timeout_rate = cbt->num_circ_timeouts / total_circuits; close_rate = cbt->num_circ_closed / total_circuits;

1 0

[tor/master] hs-v3: Build onion address before registering ephemeral service
by nickm＠torproject.org 02 Jun '18

02 Jun '18

commit 66e76066e0ae61b6a22eccc238b5ed75d705547f Author: David Goulet <dgoulet(a)torproject.org> Date: Wed May 23 11:49:02 2018 -0400 hs-v3: Build onion address before registering ephemeral service With the work on #25500 (reducing CPU client usage), the HS service main loop callback is enabled as soon as the HS service map changes which happens when registering a new service. Unfortunately, for an ephemeral service, we were building the onion address *after* the registration leading to the "service->onion_address` to be an empty string. This broke the "HS_DESC CREATED" event which had no onion address in it. And also, we were logging an empty onion address for that service. Fixes #25939 Signed-off-by: David Goulet <dgoulet(a)torproject.org> --- changes/bug25939 | 3 +++ src/or/hs_service.c | 14 ++++++++------ 2 files changed, 11 insertions(+), 6 deletions(-) diff --git a/changes/bug25939 b/changes/bug25939 new file mode 100644 index 000000000..a11c73ad0 --- /dev/null +++ b/changes/bug25939 @@ -0,0 +1,3 @@ + o Minor bugfixes (onion services): + - Fix a bug that blocked the creation of ephemeral v3 onion services. Fixes + bug 25939; bugfix on 0.3.4.1-alpha. diff --git a/src/or/hs_service.c b/src/or/hs_service.c index 9001a521a..f1f26954a 100644 --- a/src/or/hs_service.c +++ b/src/or/hs_service.c @@ -3062,6 +3062,12 @@ hs_service_add_ephemeral(ed25519_secret_key_t *sk, smartlist_t *ports, goto err; } + /* Build the onion address for logging purposes but also the control port + * uses it for the HS_DESC event. */ + hs_build_address(&service->keys.identity_pk, + (uint8_t) service->config.version, + service->onion_address); + /* The only way the registration can fail is if the service public key * already exists. */ if (BUG(register_service(hs_service_map, service) < 0)) { @@ -3071,14 +3077,10 @@ hs_service_add_ephemeral(ed25519_secret_key_t *sk, smartlist_t *ports, goto err; } - /* Last step is to build the onion address. */ - hs_build_address(&service->keys.identity_pk, - (uint8_t) service->config.version, - service->onion_address); - *address_out = tor_strdup(service->onion_address); - log_info(LD_CONFIG, "Added ephemeral v3 onion service: %s", safe_str_client(service->onion_address)); + + *address_out = tor_strdup(service->onion_address); ret = RSAE_OKAY; goto end;

1 0

[tor/master] Merge branch 'bug26121-033-squashed' into maint-0.3.3
by nickm＠torproject.org 02 Jun '18

02 Jun '18

commit f15f90e2cac50154c761da94eb9fd642890f2777 Merge: fa1890e97 fe5764012 Author: Nick Mathewson <nickm(a)torproject.org> Date: Sat Jun 2 10:36:44 2018 -0700 Merge branch 'bug26121-033-squashed' into maint-0.3.3 changes/bug26121 | 6 ++++++ src/or/circuitstats.c | 15 +++++++++++---- 2 files changed, 17 insertions(+), 4 deletions(-)

1 0

[tor/master] Merge branch 'maint-0.3.3'
by nickm＠torproject.org 02 Jun '18

02 Jun '18

commit 9f884a38e37ffa62eaaf73699e364b1e37935ea2 Merge: 00e150a0e f15f90e2c Author: Nick Mathewson <nickm(a)torproject.org> Date: Sat Jun 2 10:36:49 2018 -0700 Merge branch 'maint-0.3.3' changes/bug26121 | 6 ++++++ src/or/circuitstats.c | 15 +++++++++++---- 2 files changed, 17 insertions(+), 4 deletions(-)

1 0

[torspec/master] Merge branch 'tls13'
by isis＠torproject.org 01 Jun '18

01 Jun '18

commit bbd9567db9f75d78f2f54e575509c2cadaa699d6 Merge: a323d84 fc561d2 Author: Isis Lovecruft <isis(a)torproject.org> Date: Fri Jun 1 22:02:02 2018 +0000 Merge branch 'tls13' proposals/xxx-tls-1.3.txt | 336 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 336 insertions(+)

1 0

[torspec/master] WIP Migration to TLS 1.3 proposal.
by isis＠torproject.org 01 Jun '18

01 Jun '18

commit fc561d2bb586141320306a86f17db9dac6ed0ce8 Author: Isis Lovecruft <isis(a)torproject.org> Date: Tue Jan 23 00:51:09 2018 +0000 WIP Migration to TLS 1.3 proposal. --- proposals/xxx-tls-1.3.txt | 336 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 336 insertions(+) diff --git a/proposals/xxx-tls-1.3.txt b/proposals/xxx-tls-1.3.txt new file mode 100644 index 0000000..e89cf9f --- /dev/null +++ b/proposals/xxx-tls-1.3.txt @@ -0,0 +1,336 @@ +Filename: xxx-tls-1.3.txt +Title: TLS 1.3 Migration +Authors: Isis Lovecruft +Created: 11 December 2017 +Updated: 23 January 2018 +Status: Needs Research + +1. Motivation + + TLS 1.3 is a substantial redesign over previous versions of TLS, with several + significant protocol changes which should likely provide Tor implementations + with not only greater security but an improved ability to blend into "normal" + TLS traffic on the internet, due to its improvements in encrypting more + portions of the handshake. + + Tor implementations may utilise the new TLS 1.3 EncryptedExtensions feature + to define arbitrary encrypted TLS extensions to encompass our less standard + (ab)uses of TLS. Additionally, several new Elliptic Curve (EC) based + signature algorithms, including Ed25519 and Ed448, are included within the + base specification including a single specification for EC point compression + for each supported curve, further decreasing our reliance on + Tor-protocol-specific uses and extensions (and implementation details). + + Other new features which Tor implementations might take advantage of include + improved (server-side) stateless session resumption, which might be usable + for OPs to resume sessions with their guards, for example after network + disconnection or router IP address reassignment. + +2. Summary + + Everything that's currently TLS 1.2: make it use TLS 1.3. KABLAM. DONE. + + For an excellent summary of differences between TLS 1.2 and TLS 1.3, see + [TLS-1.3-DIFFERENCES]. + +3. Specification + +3.1. Link Subprotocol 4 + + (We call it "Link v4" here, but reserve whichever is the subsequently + available subprotocol version at the time.) + +3.2. TLS Session Resumption & Compression + + As before, implementations MUST NOT allow TLS session resumption. In the + event that it might be decided in the future that OR implementations would + benefit from 0-RTT, we can re-evaluate this decision and its security + considerations in a separate proposal. + + Compression has been removed from TLS in version 1.3, so we no longer need to + make recommendations against its usage. + +3.3. Handshake Protocol + +3.3.1. Negotiation + + The initiator sends the following four sets of options, as defined in §4.1.1 + of [TLS-1.3-NEGOTIATION]: + > + > - A list of cipher suites which indicates the AEAD algorithm/HKDF hash + > pairs which the client supports. + > - A “supported_groups” (Section 4.2.7) extension which indicates the + > (EC)DHE groups which the client supports and a “key_share” (Section 4.2.8) + > extension which contains (EC)DHE shares for some or all of these groups. + > - A “signature_algorithms” (Section 4.2.3) extension which indicates the + > signature algorithms which the client can accept. + > - A “pre_shared_key” (Section 4.2.11) extension which contains a list of + > symmetric key identities known to the client and a “psk_key_exchange_modes” + > (Section 4.2.9) extension which indicates the key exchange modes that may be + > used with PSKs. + + In our case, the initiator MUST leaave the PSK section blank and MUST include + the "key_share" extension, and the responder proceeds to select a ECDHE + group, including its "key_share" in the response ServerHello. + +3.3.2. ClientHello + + To initiate a v4 handshake, the client sends a TLS1.3 ClientHello with the + following options: + + - The "legacy_version" field MUST be set to "TLS 1.2 (0x0303)". TLS 1.3 + REQUIRES this. (Actual version negotiation is done via the + "supported_versions" extension. See §5.1 of this proposal for details of + the case where a TLS-1.3 capable initiator finds themself talking to a + node which does not support TLS 1.3 and/or doesn't support v4.) + + - The "random" field MUST be filled with 32 bytes of securely generated + randomness. + + - The "legacy_session_id" MUST be set to a new pseudorandom value each + time, regardless of whether the initiator has previously opened either a + TLS1.2 or TLS1.3 connection to the other side. + + - The "legacy_compression_methods" MUST be set to a single null byte, + indicating no compression is supported. (This is the only valid setting + for this field in TLS1.3, since there is no longer any compression + support.) + + - The "cipher_suites" should be set to + "TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384:" + This is the DEFAULT cipher suite list for OpenSSL 1.1.1. While an + argument could be made for customisation to remove the AES-128 option, we + choose to attempt to blend in which the majority of other TLS-1.3 + clients, since this portion of the handshake is unencrypted. + (If the initiator actually means to begin a v3 protocol connection, they + send these ciphersuites anyway, cf. §5.2 of this proposal.) + + - The "supported_groups" MUST include "X25519" and SHOULD NOT include any + of the NIST P-* groups. + + - The "signature_algorithms" MUST include "ed25519 (0x0807)". + Implementations MAY advertise support for other signature schemes, + including "ed448 (0x0808)", however they MUST NOT advertise support for + ECDSA schemes due to the perils of secure implementation. + + The initiator MUST NOT send any "pre_shared_key" or "psk_key_exchange_modes" + extensions. + + The details of the "signature_algorithms" choice depends upon the final + standardisation of PKIX. [IETF-PKIX] + +3.3.2.1. ClientHello Extensions + + From [TLS-1.3_SIGNATURE_ALGOS]: + > + > The “signature_algorithms_cert” extension was added to allow implementatations + > which supported different sets of algorithms for certificates and in TLS itself + > to clearly signal their capabilities. TLS 1.2 implementations SHOULD also + > process this extension. + + In order to support cross-certification, the initiator's ClientHello MUST + include the "signature_algorithms_cert" extension, in order to signal that + some certificate chains (one in particular) will include a certificate signed + using RSA-PKCSv1-SHA1: + + - The "signature_algorithms_cert" MUST include the legacy algorithm + "rsa_pkcs1_sha1(0x0201)". + +3.3.3. ServerHello + + To respond to a TLS 1.3 ClientHello which supports the v4 link handshake + protocol, the responder sends a ServerHello with the following options: + + - The "legacy_version" field MUST be set to "TLS 1.2 (0x0303)". TLS 1.3 + REQUIRES this. (Actual version negotiation is done via the + "supported_versions" extension. See §5.1 of this proposal for details of + the case where a TLS-1.3 capable initiator finds themself talking to a + node which does not support TLS 1.3 and/or doesn't support v4.) + + - The "random" field MUST be filled with 32 bytes of securely generated + randomness. + + - The "legacy_session_id_echo" field MUST be filled with the contents of + the "legacy_session_id" from the initiator's ClientHello. + + - The "cipher_suite" field MUST be set to "TLS13-CHACHA20-POLY1305-SHA256". + + - The "legacy_compression_method" MUST be set to a single null byte, + indicating no compression is supported. (This is the only valid setting + for this field in TLS1.3, since there is no longer any compression + support.) + + XXX structure and "key_share" response (XXX can we pre-generate a cache of + XXX key_shares?) + +3.3.3.1 ServerHello Extensions + + XXX what extensions do we need? + +4. Implementation Details + +4.1. Certificate Chains and Cross-Certifications + + TLS 1.3 specifies that a certificate in a chain SHOULD be directly certified by + the preceding certificate in the chain. This seems to imply that OR + implementations SHOULD NOT do the DAG-like construction normally implied by + cross-certification between the master Ed25519 identity key and the master + RSA-1024 identity key. + + Instead, since certificate chains are expected to be linear, we'll need three + certificate chains included in the same handshake: + + 1. EdMaster->EdSigning, EdSigning->Link + 2. EdMaster->RSALegacy + 3. RSALegacy->EdMaster + + where A->B denotes that the certificate containing B has been signed with key A. + +4.2. Removal of AUTHENTICATE, CLIENT_AUTHENTICATE, and CERTS cells + + XXX see prop#224 and RFC5705 and compare + + XXX when can we remove our "renegotiation" handshake completely? + +5. Compatibility + +5.1. TLS 1.2 version negotiation + + From [TLS-1.3-DIFFERENCES]: + > + > The “supported_versions” ClientHello extension can be used to + > negotiate the version of TLS to use, in preference to the + > legacy_version field of the ClientHello. + + If an OR does not receive a ClientHello with a "supported_versions" + extenstion, it MUST fallback to using the Tor Link subprotocols v3. That is, + the OR MUST immediately fallback to TLS 1.2 (or v3 with TLS 1.3, cf. the next + section) and, following both Tor's "renegotiation" and "in-protocol" version + negotiation mechanisms, immediately send a VERSIONS cell. + + Otherwise, upon seeing a "supported_versions" in the ClientHello set to + 0x0304, the OR should procede with Tor's Link subprotocol 4. + +5.2. Preparing Tor's v3 Link Subprotocol for TLS 1.3 + + Some changes to the current v3 Link protocol are required, and these MUST + be backported, since implementations which are currently compiled against + TLS1.3-supporting OpenSSLs fail to establish any connections due to: + + - failing to include any ciphersuite candidates which are TLS1.3 compatible + + This is likely to be accomplished by: + + 1. Prefacing our v3 ciphersuite lists with + TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384: + (We could also retroactively change our custom cipher suite list to be + the HIGH cipher suites, since this includes all TLS 1.3 suites.) + 2. Calling SSL_CTX_set1_groups() to set the supported groups (should be set + to "X25519:P-256"). [TLS-1.3_SET1_GROUPS] + 3. Taking care that older OpenSSLs, which instead have the concept of + "curves" not groups, should have their equivalent TLS context settings + in place. [TLS-1.3_SET1_GROUPS] mentions that "The curve functions were + first added to OpenSSL 1.0.2. The equivalent group functions were first + added to OpenSSL 1.1.1". + + However more steps may need to be taken. + + [XXX are there any more steps necessary? —isis] + +6. Security Implications + + XXX evaluate the static RSA attack and its effects on TLS1.2/TLS1.3 + XXX dual-operable protocols and determine if they apply + XXX + XXX Jager, T., Schwenk, J. and J. Somorovsky, "On the Security + XXX of TLS 1.3 and QUIC Against Weaknesses in PKCS#1 v1.5 Encryption", + XXX Proceedings of ACM CCS 2015 , 2015. + XXX https://www.nds.rub.de/media/nds/veroeffentlichungen/2015/08/21/Tls13QuicAt… + +7. Performance and Scalability + +8. Availability and External Deployment + +8.1. OpenSSL Availability and Interoperability + + Implementation should be delayed until the stable release of OpenSSL 1.1.1. + + OpenSSL 1.1.1 will be binary and API compatible with OpenSSL 1.1.0, so in + preparation we might wish to revise our current usage to OpenSSL 1.1.0 to be + prepared. + + From Matt Caswell in [OPENSSL-BLOG-TLS-1.3]: + > + > OpenSSL 1.1.1 will not be released until (at least) TLSv1.3 is + > finalised. In the meantime the OpenSSL git master branch contains + > our development TLSv1.3 code which can be used for testing purposes + > (i.e. it is not for production use). You can check which draft + > TLSv1.3 version is implemented in any particular OpenSSL checkout + > by examining the value of the TLS1_3_VERSION_DRAFT_TXT macro in the + > tls1.h header file. This macro will be removed when the final + > version of the standard is released. + > + > In order to compile OpenSSL with TLSv1.3 support you must use the + > “enable-tls1_3” option to “config” or “Configure”. + > + > Currently OpenSSL has implemented the “draft-20” version of + > TLSv1.3. Many other libraries are still using older draft versions in + > their implementations. Notably many popular browsers are using + > “draft-18”. This is a common source of interoperability + > problems. Interoperability of the draft-18 version has been tested + > with BoringSSL, NSS and picotls. + > + > Within the OpenSSL git source code repository there are two branches: + > “tls1.3-draft-18” and “tls1.3-draft-19”, which implement the older + > TLSv1.3 draft versions. In order to test interoperability with other + > TLSv1.3 implementations you may need to use one of those + > branches. Note that those branches are considered temporary and are + > likely to be removed in the future when they are no longer needed. + + At the time of its release, we may wish to test interoperability with other + implementation(s). + +9. Future Directions + + The implementation of this proposal would greatly ease the + implementation difficulty and maintenance requirements for some + other possible future beneficial areas of work. + +9.1. TLS Handshake Composability + + Handshake composition (i.e. hybrid handshakes) in TLS 1.3 is incredibly + straightforward. + + For example, provided we had a Supersingular Isogeny Diffie-Hellman (SIDH) + based implementation with a sane API, composition of Elliptic Curve + Diffie-Hellman (ECDH) and SIDH handshakes would be a trivial codebase + addition (~10-20 lines of code, for others who have implemented this). + + Our current circuit-layer protocol safeguards the majority of our security + and anonymity guarantees, while our TLS layer has historically been either a + stop-gap and/or an attempted (albeit usually not-so-successful) obfuscation + mechanism. However, our TLS usage has, in many cases, successfully, through + combination with the circuit layer cryptography, prevented more then a few + otherwise horrendous bugs. After our circuit-layer protocol is upgraded to a + hybrid post-quantum secure protocol (prop#269 and prop#XXX), and in order to + ensure that our TLS layer continues to act in this manner as a stop gap — + including within threat models which include adversaries capable of recording + traffic now and decrypting with a potential quantum computer in the future — + our TLS layer should also provide safety against such a quantum-capable + adversary. + + +A. References + +[TLS-1.3-DIFFERENCES]: + https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#rfc.section.1.3 +[OPENSSL-BLOG-TLS-1.3]: + https://www.openssl.org/blog/blog/2017/05/04/tlsv1.3/ +[TLS-1.3-NEGOTIATION]: + https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#rfc.section.4.… +[IETF-PKIX]: + https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ +[TLS-1.3_SET1_GROUPS]: + https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set1_groups.html +[TLS-1.3_SIGNATURE_ALGOS]: + https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#signature-algo…

1 0

[torspec/master] Add work-in-progress TLS 1.3 proposal as a draft with number 294.
by isis＠torproject.org 01 Jun '18

01 Jun '18

commit 14cd5da191992645715a74307260059382396ce9 Author: Isis Lovecruft <isis(a)torproject.org> Date: Fri Jun 1 22:07:55 2018 +0000 Add work-in-progress TLS 1.3 proposal as a draft with number 294. --- proposals/000-index.txt | 2 ++ proposals/{xxx-tls-1.3.txt => 294-tls-1.3.txt} | 8 ++++++-- proposals/proposal-status.txt | 6 ++++++ 3 files changed, 14 insertions(+), 2 deletions(-) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 2d7a595..3170365 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -214,6 +214,7 @@ Proposals by number: 291 The move to two guard nodes [OPEN] 292 Mesh-based vanguards [OPEN] 293 Other ways for relays to know when to publish [OPEN] +294 TLS 1.3 Migration [DRAFT] Proposals by status: @@ -237,6 +238,7 @@ Proposals by status: 279 A Name System API for Tor Onion Services 281 Downloading microdescriptors in bulk 288 Privacy-Preserving Statistics with Privcount in Tor (Shamir version) + 294 TLS 1.3 Migration NEEDS-REVISION: 190 Bridge Client Authorization Based on a Shared Secret NEEDS-RESEARCH: diff --git a/proposals/xxx-tls-1.3.txt b/proposals/294-tls-1.3.txt similarity index 98% rename from proposals/xxx-tls-1.3.txt rename to proposals/294-tls-1.3.txt index e89cf9f..c9bae79 100644 --- a/proposals/xxx-tls-1.3.txt +++ b/proposals/294-tls-1.3.txt @@ -1,9 +1,13 @@ -Filename: xxx-tls-1.3.txt +Filename: 294-tls-1.3.txt Title: TLS 1.3 Migration Authors: Isis Lovecruft Created: 11 December 2017 Updated: 23 January 2018 -Status: Needs Research +Status: Draft + +This proposal is currently in draft state and should be periodically +revised as we research how much of our idiosyncratic older TLS uses +can be removed. 1. Motivation diff --git a/proposals/proposal-status.txt b/proposals/proposal-status.txt index f9cf218..8a709bc 100644 --- a/proposals/proposal-status.txt +++ b/proposals/proposal-status.txt @@ -546,4 +546,10 @@ again to remind me! The proposal specifies a modular system for integrating naming systems (GNS, Namecoin, etc.) with Tor onion services. +294 TLS 1.3 Migration [DRAFT] + + A work-in-progress draft proposal detailing the process of + migrating to TLS 1.3 (which is not yet finalised at the time of + this writing) and which parts of our current, more idiosyncratic, + uses of TLS can be removed.

1 0

[tor-browser-build/master] Merge remote-tracking branch 'gk/bug_9711_v2'
by boklm＠torproject.org 01 Jun '18

01 Jun '18

commit 966c55d754aaf7d181e85d73474d4014eb72a6ac Merge: ef90f3c 94b31b1 Author: Nicolas Vigier <boklm(a)torproject.org> Date: Fri Jun 1 12:51:24 2018 +0200 Merge remote-tracking branch 'gk/bug_9711_v2' projects/cctools/build | 24 ++++++++++++++++++++++++ projects/cctools/config | 16 ++++++++++++++++ 2 files changed, 40 insertions(+)

1 0

[tor-browser-build/master] Bug 9711: Build own cctools for macOS cross-compilation
by boklm＠torproject.org 01 Jun '18

01 Jun '18

commit 94b31b1822961b25fec66078bcf48a279d6e9aa6 Author: Georg Koppen <gk(a)torproject.org> Date: Mon May 21 14:13:40 2018 +0000 Bug 9711: Build own cctools for macOS cross-compilation --- projects/cctools/build | 24 ++++++++++++++++++++++++ projects/cctools/config | 16 ++++++++++++++++ 2 files changed, 40 insertions(+) diff --git a/projects/cctools/build b/projects/cctools/build new file mode 100644 index 0000000..cad9e3a --- /dev/null +++ b/projects/cctools/build @@ -0,0 +1,24 @@ +#!/bin/bash +[% c("var/set_default_env") -%] +distdir=/var/tmp/dist/[% project %] +mkdir -p /var/tmp/dist +tar -C /var/tmp/dist -xf [% c('input_files_by_name/llvm') %] +export PATH="/var/tmp/dist/llvm/bin:$PATH" +mkdir -p /var/tmp/build +tar -C /var/tmp/build -xf [% project %]-[% c('version') %].tar.gz +cd /var/tmp/build/[% project %]-[% c('version') %]/cctools + +export CC=clang +export CXX=clang++ +./autogen.sh +./configure --prefix=$distdir --target=x86_64-apple-darwin11 --with-llvm-config=llvm-config +export LDFLAGS=-lpthread + +make -j[% c("buildconf/num_procs") %] install + +cd /var/tmp/dist +[% c('tar', { + tar_src => [ project ], + tar_args => '-czf ' _ dest_dir _ '/' _ c('filename'), + }) %] + diff --git a/projects/cctools/config b/projects/cctools/config new file mode 100644 index 0000000..cb84ec4 --- /dev/null +++ b/projects/cctools/config @@ -0,0 +1,16 @@ +# vim: filetype=yaml sw=2 +filename: '[% project %]-[% c("version") %]-[% c("var/build_id") %].tar.gz' +version: '[% c("abbrev") %]' +# This can be found in +# browser/config/tooltool-manifest/macosx64/clang.manifest +git_hash: 8e9c3f2506b51cf56725eaa60b6e90e240e249ca +git_url: https://github.com/tpoechtrager/cctools-port + +var: + container: + use_container: 1 + +input_files: + - project: container-image + - name: llvm + project: llvm

1 0

[tor-browser-build/master] Bug 26249: Update libevent to fix macOS cross-compilation
by boklm＠torproject.org 01 Jun '18

01 Jun '18

commit ef90f3c7881467df0500674dae84d44e247d459c Author: Georg Koppen <gk(a)torproject.org> Date: Thu May 31 15:34:56 2018 +0000 Bug 26249: Update libevent to fix macOS cross-compilation --- keyring/libevent.gpg | Bin 61408 -> 1782 bytes projects/libevent/autotools-openssl-mac.patch | 26 ++++++++++++++++++++++++++ projects/libevent/build | 3 +++ projects/libevent/config | 4 +++- projects/tor/build | 2 +- 5 files changed, 33 insertions(+), 2 deletions(-) diff --git a/keyring/libevent.gpg b/keyring/libevent.gpg index ca92300..b287e04 100644 Binary files a/keyring/libevent.gpg and b/keyring/libevent.gpg differ diff --git a/projects/libevent/autotools-openssl-mac.patch b/projects/libevent/autotools-openssl-mac.patch new file mode 100644 index 0000000..1ee2964 --- /dev/null +++ b/projects/libevent/autotools-openssl-mac.patch @@ -0,0 +1,26 @@ +From 506df426dbeb0187bbd3654bd286b4100628fb16 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Carlo=20Marcelo=20Arenas=20Bel=C3=B3n?= <carenas(a)gmail.com> +Date: Tue, 29 Aug 2017 00:44:57 -0700 +Subject: [PATCH] autotools: confirm openssl is working before using + +latest versions of macOS provide pkg-config and libraries for an ancient +version of openssl as part of the system, but no headers + +diff --git a/m4/libevent_openssl.m4 b/m4/libevent_openssl.m4 +index c2040595..7b458134 100644 +--- a/m4/libevent_openssl.m4 ++++ b/m4/libevent_openssl.m4 +@@ -39,6 +39,10 @@ case "$enable_openssl" in + done + ;; + esac ++ CPPFLAGS_SAVE=$CPPFLAGS ++ CPPFLAGS+=$OPENSSL_INCS ++ AC_CHECK_HEADERS([openssl/ssl.h], [], [have_openssl=no]) ++ CPPFLAGS=$CPPFLAGS_SAVE + AC_SUBST(OPENSSL_INCS) + AC_SUBST(OPENSSL_LIBS) + case "$have_openssl" in +-- +2.17.0 + diff --git a/projects/libevent/build b/projects/libevent/build index a38422a..00ee78c 100644 --- a/projects/libevent/build +++ b/projects/libevent/build @@ -5,6 +5,9 @@ distdir=/var/tmp/dist/[% project %] mkdir -p /var/tmp/build tar -C /var/tmp/build -xf [% project %]-[% c('version') %].tar.gz cd /var/tmp/build/[% project %]-[% c('version') %] +[% IF c("var/osx") -%] + patch -p1 < $rootdir/autotools-openssl-mac.patch +[% END -%] ./autogen.sh ./configure --disable-static [% c("var/configure_opt") %] --prefix=$distdir [% IF c("var/osx") -%] diff --git a/projects/libevent/config b/projects/libevent/config index 46cbb7e..386f746 100644 --- a/projects/libevent/config +++ b/projects/libevent/config @@ -1,5 +1,5 @@ # vim: filetype=yaml sw=2 -version: 2.0.22 +version: 2.1.8 git_url: https://github.com/libevent/libevent.git git_hash: 'release-[% c("version") %]-stable' tag_gpg_id: 1 @@ -20,3 +20,5 @@ input_files: - project: container-image - name: '[% c("var/compiler") %]' project: '[% c("var/compiler") %]' + - filename: autotools-openssl-mac.patch + enable: '[% c("var/osx") %]' diff --git a/projects/tor/build b/projects/tor/build index bf7db83..c6d9895 100644 --- a/projects/tor/build +++ b/projects/tor/build @@ -39,7 +39,7 @@ openssldir=/var/tmp/dist/openssl mkdir -p "$distdir/Debug/Tor" cp $openssldir/lib/libssl.so.1.0.0 "$distdir/Tor/" cp $openssldir/lib/libcrypto.so.1.0.0 "$distdir/Tor/" - cp $libeventdir/lib/libevent-2.0.so.5 "$distdir/Tor/" + cp $libeventdir/lib/libevent-2.1.so.6 "$distdir/Tor/" # We need to copy the libstdc++.so.6 for Tor Browser on older Linux distros. # Copying it into /Browser, which feels more natural, and amending # LD_LIBRARY_PATH breaks updates from a Tor Browser with the old

1 0