Merge bssl #94

bryce-shang · 2021-02-18T17:25:38Z

Issues:

Resolves CryptoAlg-612

Description of changes:

This PR merged latest code of BoringSSL master branch.

Call-outs:

N/A

Testing:

CI

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

These APIs were used by Chromium to control the carve-out for the TLS 1.3 downgrade signal. As of https://chromium-review.googlesource.com/c/chromium/src/+/2324170, Chromium no longer uses them. Update-Note: SSL_CTX_set_ignore_tls13_downgrade, SSL_set_ignore_tls13_downgrade, and SSL_is_tls13_downgrade now do nothing. Calls sites should be removed. (There are some copies of older Chromium lying around, so I haven't removed the functions yet.) The enforcement was already on by default, so this CL does not affect callers that don't use those functions. Change-Id: I016af8291cd92051472d239c4650602fe2a68f5b Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44124 Reviewed-by: Adam Langley <[email protected]>

It's not even accurate. The term "master key" dates to SSL 2, which we do not implement. (Starting SSL 3, "key" was replaced with "secret".) The field stores, at various points, the TLS 1.2 master secret, the TLS 1.3 resumption master secret, and the TLS 1.3 resumption PSK. Simply rename the field to 'secret', which is as descriptive of a name as we can get at this point. I've left SSL_SESSION_get_master_key alone for now, as it's there for OpenSSL compatibility, as well as references to the various TLS secrets since those refer to concepts in the spec. (When the dust settles a bit on rfc8446bis, we can fix those.) Change-Id: I3c1007eb7982788789cc5db851de8724c7f35baf Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44144 Reviewed-by: Adam Langley <[email protected]>

Change-Id: I08cc198f326f02b3f38234b938208ea49a13fab6 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44164 Commit-Queue: Adam Langley <[email protected]> Commit-Queue: David Benjamin <[email protected]> Reviewed-by: David Benjamin <[email protected]>

Change-Id: Ib5d69d82c4cfc8cc172bdb5d9a739af53f9d2899 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44165 Reviewed-by: David Benjamin <[email protected]> Commit-Queue: Adam Langley <[email protected]>

Almost everything in <openssl/asn1.h> uses ASN1_STRING, and there are a lot of unspoken assumptions in the library about the type field, so it needs quite a bit of text. Change-Id: Ied56c9428069477da8ecb17a174da4320e573fa1 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44184 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: Adam Langley <[email protected]>

This covers the use of EVP_sha256() added in 8846533. Change-Id: I8cd4c8e271de6a0b9a926e7186c7b24ffe849d67 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44224 Commit-Queue: Adam Langley <[email protected]> Commit-Queue: David Benjamin <[email protected]> Reviewed-by: David Benjamin <[email protected]>

…ignal The docs at os/signal.Notify warn about this signal delivery loss bug at https://golang.org/pkg/os/signal/#Notify, which says: Package signal will not block sending to c: the caller must ensure that c has sufficient buffer space to keep up with the expected signal rate. For a channel used for notification of just one signal value, a buffer of size 1 is sufficient. Discovered by one of Orijtech, Inc's internal static analyzers that will eventually be donated to the Go project, and will then be included when one runs: go test Change-Id: I5713f7087a195ac706240d32b53d2e4855d93a1c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44264 Reviewed-by: David Benjamin <[email protected]> Commit-Queue: David Benjamin <[email protected]>

Clarify that there are no truncation issues on targets where the range of |unsigned| is smaller than the range of |size_t|. Ensure that |poly1305_state| is (still) large enough. This is a good idea independently of this change, but is especially important because switching the fields to |size_t| might have enlarged the structures. Change-Id: I16e408229c28fcba6c3592603ddb9431cf1f142d Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44244 Commit-Queue: Adam Langley <[email protected]> Reviewed-by: Adam Langley <[email protected]>

No need to use |sk_new|, which allocates a buffer that will immediately be realloced. Change-Id: If0a787beac19933d93c5f9a3a8b560edd027c16c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44205 Reviewed-by: Adam Langley <[email protected]>

ARM Cortex-A57 and Cortex-A72 cores running in 32-bit mode are affected by silicon errata #1742098 [0] and #1655431 [1], respectively, where the second instruction of a AES instruction pair may execute twice if an interrupt is taken right after the first instruction consumes an input register of which a single 32-bit lane has been updated the last time it was modified. Shuffle the counter assignments around a bit so that the most recent updates when the AES instruction pair executes are 128-bit wide. [0] ARM-EPM-049219 v23 Cortex-A57 MPCore Software Developers Errata Notice [1] ARM-EPM-012079 v11.0 Cortex-A72 MPCore Software Developers Errata Notice (This is imported from upstream's 409c59e8f44ae56f2587cdd8a7ce611d0e3d91d9.) The change is applied to both 32-bit and 64-bit for simplicity, but there was no measurable performance difference, so leaving them aligned is easiest. Change-Id: Ic8e5f656f59ae8c2ecb2762a066c2c9064bb34c5 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44284 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: Adam Langley <[email protected]>

<openssl/base.h> checks for a supported platform, but we don't check endianness of ARM and MIPS, which are bi-endian. See https://crbug.com/1153312#c7. Switch this around. Documentation on which define is "official" is hard to come by, so I mostly mimicked Chromium. Chromium detects little-endian ARM and MIPS with __ARMEL__ and __MIPSEL__ respectively, without looking at __arm__ or __mips__. It uses __aarch64__ instead of __AARCH64EL__, but I think that's an oversight. I can get Clang to output for aarch64_be and that defines __aarch64__ with __AARCH64EB__. <openssl/arm_arch.h> (which we should simplify and align with base.h once this CL sticks) also normalizes to __ARMEL__ over __BYTE_ORDER__ and friends. Although, interestingly, arm_arch.h defines its own __ARMEL__ on GNUC aarch64, even though Clang does *not* define __ARMEL__ on aarch64. (I'm guessing this aligned for the benefit of the "armx" bi-arch asm files.) This value is based on __BYTE_ORDER__, not __ARMEL__, but it assumes GNUC arm always defines __ARMEL__, so I think it's reasonable to assume GNUC aarch64 always defines __AARCH64EL__. Given all this, probably the simplest thing that's most likely to work is to use __ARMEL__, __MIPSEL__, and __AARCH64EL__. Note this does not change the _M_* checks. _M_* are Windows's definitions, which I think we can reasonably assume come with an endianness opinion. (Windows' ARM and ARM64 ABIs mandate little-endian.) This aligns with Chromium. Update-Note: CPU processor defines are a mess. If a little-endian ARM or MIPS build breaks, some of the assumptions above may be wrong. In that case, the output $CC -dM -E - < /dev/null on the offending toolchain will be useful to fix it. If a big-endian ARM or MIPS build breaks, this is working as intended. Any resulting binaries weren't producing the right outputs. Change-Id: I2a9e662d09df119a71226e91716d84e7ac3792aa Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44324 Commit-Queue: Adam Langley <[email protected]> Reviewed-by: Adam Langley <[email protected]>

Change-Id: Iba527924a79733b28b12b65d8e1f613d7819eb34 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44345 Commit-Queue: Adam Langley <[email protected]> Commit-Queue: David Benjamin <[email protected]> Reviewed-by: David Benjamin <[email protected]>

Change-Id: I55ef8c4987c1205de9eb16243ffd4efc6aa1c5bd Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44344 Reviewed-by: Adam Langley <[email protected]> Commit-Queue: Adam Langley <[email protected]>

If I perturb kOrder in the malleability check, our and Wycheproof's tests don't easily notice. This adds some tests with s above and below the order. EdDSA hashes the public key with the message, which frustrates constructing actual boundary cases. Instead, these inputs were found by generating many signatures. This isn't ideal, but it is sensitive to the most significant 32 bits. Change-Id: I7fc03758ab97650d0e94478f355ea7085ae0559a Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44346 Commit-Queue: David Benjamin <[email protected]> Commit-Queue: Adam Langley <[email protected]> Reviewed-by: Adam Langley <[email protected]>

It's insufficient to signal an error when the PWCT fails. We additionally need to ensure that the invalid key material is not returned. Change-Id: Ic5ff719a688985a61c52540ce6d1ed279a493d27 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44306 Commit-Queue: Adam Langley <[email protected]> Reviewed-by: David Benjamin <[email protected]>

See also CVE-2020-1971, f960d81215ebf3f65e03d4d5d857fb9b666d6920, and aa0ad2011d3e7ad8a611da274ef7d9c7706e289b from upstream OpenSSL. Unlike upstream's version, this CL opts for a simpler edipartyname_cmp. GENERAL_NAME_cmp is already unsuitable for ordering, just equality, which means there's no need to preserve return values from ASN1_STRING_cmp. Additionally, the ASN.1 structure implies most fields cannot be NULL. (The change from other to x400Address is a no-op. They're the same type. Just x400Address is a little clearer. Historical quirks of the GENERAL_NAME structure.) Change-Id: I4b0ffe8e931c8ef916794a486e6a0d6d684c0cc1 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44404 Reviewed-by: Adam Langley <[email protected]>

Also make it a little shorter. Change-Id: I6ee9d7666e9cf622509c54966a88f899a1974f9f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44405 Reviewed-by: Adam Langley <[email protected]>

Change-Id: Ia3d98b00365ed92cbf7d02cdb55a1a16e431c4f4 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44384 Reviewed-by: David Benjamin <[email protected]>

This change tweaks our ACVP config to better match what BoringCrypto has previously tested with CAVP. Change-Id: I7d7ce5153a3eb7355ae1516f06ff591ee2c9d902 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44385 Reviewed-by: David Benjamin <[email protected]>

Change-Id: I4f4a89f97e2513d8b5b740620989b187a7b44a58 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44386 Commit-Queue: Adam Langley <[email protected]> Reviewed-by: David Benjamin <[email protected]>

Bug: 275 Change-Id: I4927c0886e3acf5b39104e3d89ed51d67520a343 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40204 Reviewed-by: David Benjamin <[email protected]> Commit-Queue: David Benjamin <[email protected]>

This imports 1ecc76f6746cefd502c7e9000bdfa4e5d7911386 and 41d62636fd996c031c0c7cef746476278583dc9e from upstream. These would have rejected the mistake in OpenSSL's EDIPartyName sturcture. Change-Id: I4eb218f9372bea0f7ff302321b9dc1992ef0c13a Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44424 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: Adam Langley <[email protected]>

This imports d741debb320bf54e8575d35603a44d4eb40fa1f9 from upstream. We've been managing the shared libraries already because our arm-xlate.pl automatically adds .hidden to .extern lines, but nice to reduce the diff. (This does result in some duplicate .hidden lines in the generated output, but we still want the arm-xlate.pl patch to automatically hide .globl.) Removing .comm lines does change the generated output, but having each asm file define its own copy of OPENSSL_armcap_P as a common symbol always seemed odd. I recall some weird issue where the armv4.pl files subtly rely on it for iOS's strange .indirect_symbol machinery. (Not actually because iOS wants a common symbol but because arm-xlate.pl repurposes .comm to trigger .indirect_symbol.) Fortunately, aarch64 is much better about PC-relative addressing, so it should be a no-op. The .comm lines have also previously caused weird issues (https://boringssl-review.googlesource.com/c/boringssl/+/32324), so it's generally nice to get rid of them. Update-Note: If aarch64 builds get some weird error about relocations, it's this CL's fault. Change-Id: I763ffa6cda750d99694ded8a5b68d7b27b09cfc9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44464 Reviewed-by: Adam Langley <[email protected]> Commit-Queue: David Benjamin <[email protected]>

Change-Id: Ida3ec65e81398881a71828dc1d51cf80be41bdbb Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44444 Commit-Queue: Adam Langley <[email protected]> Reviewed-by: David Benjamin <[email protected]>

8846533 added a “power-on” test for the TLS KDF, but omitted to add it to the documented list of these tests. Change-Id: I13dbad4b9359e7dae0938d02ac53e5e011f50824 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44505 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: David Benjamin <[email protected]>

This should fix the Chromium roll. Windows shared library builds are fussy about dllexport vs. dllimport in a way that's incompatible with external uses of the asn1t.h macros. The issue is the DECLARE_* macros will add dllexport vs. dllimport on the assumption the symbols are defined in libcrypto, but external definitions need a different selector. Rather than add more complex macros for this, just exclude those tests. Ideally we wouldn't supoport asn1t.h outside the library at all, if we can manage it, so no sense in trying to make it work. This excludes both the new and the old tests. Although this has been working thus far, it only works because we've been setting the BORINGSSL_IMPLEMENTATION symbol for test targets wrong in Chromium. I'm confused how that's been working at all (maybe dllexport vs. dllimport is more lax when it comes to functions rather than variables?), but when I do it correctly, the ASN1_LINKED_LIST template breaks too. Change-Id: I391edba1748f66c383ed55a9d23053674bbb876e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44484 Commit-Queue: Adam Langley <[email protected]> Reviewed-by: Adam Langley <[email protected]>

Rather than the FIPS module actively collecting entropy from the CPU or OS, this change configures Android FIPS to passively receive entropy. See FIPS IG 7.14 section two. Change-Id: Ibfc5c5042e560718474b89970199d35b67c21296 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44305 Commit-Queue: Adam Langley <[email protected]> Reviewed-by: David Benjamin <[email protected]>

As of https://chromium-review.googlesource.com/c/chromium/tools/build/+/2586225, we no longer test on Yasm. Yasm hasn't seen a release for over six years now and is missing support for newer x86 instructions. This removes the remnants of support for Yasm on the CI. It also removes the Yasm support we patched into x86nasm.pl, which removes a now unnecessary divergence from upstream. Update-Note: If a x86 Windows asm build breaks, switch from Yasm to NASM. We're also no longer testing NASM on x86_64 Windows, but there wasn't any patch to revert. Change-Id: I016bad8757fcc13240db9f56dd622be518e649d7 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44564 Reviewed-by: Adam Langley <[email protected]> Commit-Queue: David Benjamin <[email protected]>

Imported from upstream's 617b49db14fa4c1211bfc5d0e88294d0f159c9a9. Change-Id: I64349b7cbbda8fbacf1e20ca609081ed42f10550 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44565 Reviewed-by: Adam Langley <[email protected]> Commit-Queue: David Benjamin <[email protected]>

This change also drops ex_data from DH objects. The global would need special handling in the FIPS module, which isn't hard, but just dropping it saves some of the code-size costs of this change and I cannot find any signs of use of this functionality. Change-Id: I984bd70698c2ec329f340d294b3b9ec169cd0c4e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44524 Reviewed-by: David Benjamin <[email protected]>

torben-hansen · 2021-02-19T06:12:37Z

util/generate_build_files.py

@@ -37,6 +37,7 @@
    ('mac', 'x86_64', 'macosx', [], 'S'),
    ('win', 'x86', 'win32n', ['-DOPENSSL_IA32_SSE2'], 'asm'),
    ('win', 'x86_64', 'nasm', [], 'asm'),
+    ('win', 'aarch64', 'win64', [], 'S'),


Flagging this for Kaufman

This just means that we will have to re-run generate_build_files.py to generate the files for this newly added architecture. I will do this in another PR when I add a new test for ensuring that things stay in sync.

torben-hansen · 2021-02-19T06:19:46Z

crypto/x509v3/v3_genn.c

@@ -104,78 +105,54 @@ IMPLEMENT_ASN1_DUP_FUNCTION(GENERAL_NAME)

 static int edipartyname_cmp(const EDIPARTYNAME *a, const EDIPARTYNAME *b)
 {
-    int res = -1;
-
-    if ((a == NULL) || (b == NULL)) {


Why are we deleting these checks?

Additionally, the ASN.1 structure implies most fields cannot be NULL.

google/boringssl@aa4ecb4

In this asn1 mess I don't want to make all those assumptions. There is 0 downside to adding these checks.
What's the argument that these checks are not needed?

the ASN.1 structure implies most fields cannot be NULL.

Specifically, d type is union. It has been allocated automatically when the GENERAL_NAME is defined. So checking NULL is not necessary here.

edipartyname_cmp(a->d.ediPartyName, b->d.ediPartyName); union { ... EDIPARTYNAME *ediPartyName; ... } d;

In general, for this kind of code that is rarely used, there is not really any reason to make these assumptions. Just add the NULL check, and you can avoid any potential issues in the future. You might also avoid having false-positives in static analysis tools.

torben-hansen · 2021-02-19T06:25:12Z

crypto/x509/x509_cmp.c

@@ -83,36 +83,6 @@ int X509_issuer_and_serial_cmp(const X509 *a, const X509 *b)
    return (X509_NAME_cmp(ai->issuer, bi->issuer));
 }

-unsigned long X509_issuer_and_serial_hash(X509 *a)


Okay, we decided to remove this?

No usage.
ca2162d

i don't think you can use a 3rd party statement about no usage to conclude there are no usage internally.

I searched internal code base with the filter that excludes x509_cmp.c, x509.h and ssleay.txt.

That's better validation.

torben-hansen · 2021-02-19T06:30:19Z

crypto/fipsmodule/rand/rand.c

@@ -193,6 +273,7 @@ static void rand_get_seed(struct rand_thread_state *state,
    BORINGSSL_FIPS_abort();
  }

+  OPENSSL_STATIC_ASSERT(sizeof(entropy) % CRNGT_BLOCK_SIZE == 0, _);


Just using _ doesn't really give a useful error message. Shouldn't we be more descriptive?

No, original code is "". If more descriptive is needed, other places can also get tagged and then this PR scope becomes bigger.

It's just replacing a _ with something that actually makes sense?

I think this is over.

This PR is just to merge latest BoringSSL code and conform the limit of OPENSSL_STATIC_ASSERT, which is from #80.

Asserts with empty error messages can make sense when the condition is short (self-explained). More verbose info can be added but then the case may not be "just replacing" or be kind of duplicate.

Besides, if each assert requires a descriptive error msg, OPENSSL_STATIC_ASSERT may need to add the non empty validation on the error. But I don't think this is really necessary.

Each merging from BoringSSL will have OPENSSL_STATIC_ASSERT conflicts and then hit this argument.

torben-hansen · 2021-02-19T06:43:36Z

crypto/poly1305/poly1305_arm.c

  uint8_t key[16];
 };

+OPENSSL_STATIC_ASSERT(
+    sizeof(struct poly1305_state_st) + 63 <= sizeof(poly1305_state),
+    "poly1305_state isn't large enough to hold aligned poly1305_state_st.");


Second argument is not a token. How is this passing?

I don't plan to change this because no CI dimension can reach this code. Another thing is I prefer the original OPENSSL_STATIC_ASSERT, which allows passing string.

#if !defined(__ARM_ARCH__) # if defined(__CC_ARM) # define __ARM_ARCH__ __TARGET_ARCH_ARM # if defined(__BIG_ENDIAN) # define __ARMEB__ # else # define __ARMEL__ # endif # elif defined(__GNUC__) #elif defined(__ARMEL__) || defined(_M_ARM) #define OPENSSL_32_BIT #define OPENSSL_ARM #if defined(OPENSSL_ARM) && !defined(OPENSSL_NO_ASM) && !defined(OPENSSL_APPLE) #define OPENSSL_POLY1305_NEON

We can't make decisions based on what can currently be reached and what cannot. If OPENSSL_ARM is enabled then the build fails, which it might in the future, who knows.
I also prefer the original assert. But as you know, it was not C99 compliant.

Changed.

It's not easy to enable OPENSSL_ARM because OPENSSL_ARM relies on __ARMEL__ or _M_ARM, which depends on __CC_ARM. When CI adds this, the code change will be detected(validated).

crypto/blake2/blake2.c

torben-hansen · 2021-02-19T06:48:59Z

I think you can remove this block as well: https://github.com/awslabs/aws-lc/blob/6e2ef19b82911dadb34c0cb08ae2111b7a20961b/crypto/x509v3/v3name_test.cc#L581

bryce-shang · 2021-02-19T15:36:59Z

I think you can remove this block as well:

https://github.com/awslabs/aws-lc/blob/6e2ef19b82911dadb34c0cb08ae2111b7a20961b/crypto/x509v3/v3name_test.cc#L581

Addressed.

torben-hansen · 2021-02-22T18:44:14Z

crypto/x509/x509_cmp.c

@@ -83,36 +83,6 @@ int X509_issuer_and_serial_cmp(const X509 *a, const X509 *b)
    return (X509_NAME_cmp(ai->issuer, bi->issuer));
 }

-unsigned long X509_issuer_and_serial_hash(X509 *a)


That's better validation.

torben-hansen · 2021-02-22T18:46:38Z

crypto/x509v3/v3_genn.c

@@ -104,78 +105,54 @@ IMPLEMENT_ASN1_DUP_FUNCTION(GENERAL_NAME)

 static int edipartyname_cmp(const EDIPARTYNAME *a, const EDIPARTYNAME *b)
 {
-    int res = -1;
-
-    if ((a == NULL) || (b == NULL)) {


In general, for this kind of code that is rarely used, there is not really any reason to make these assumptions. Just add the NULL check, and you can avoid any potential issues in the future. You might also avoid having false-positives in static analysis tools.

This reverts commit 5ef51ca.

64-bit SIMD regs in ARM model, better BOUNDER_RULE, slow-ARM field optimizations s2n-bignum original commit: awslabs/s2n-bignum@06781d2

64-bit SIMD regs in ARM model, better BOUNDER_RULE, slow-ARM field optimizations s2n-bignum original commit: awslabs/s2n-bignum@06781d2 s2n-bignum original commit: awslabs/s2n-bignum@159ad31

64-bit SIMD regs in ARM model, better BOUNDER_RULE, slow-ARM field optimizations s2n-bignum original commit: awslabs/s2n-bignum@06781d2

64-bit SIMD regs in ARM model, better BOUNDER_RULE, slow-ARM field optimizations

64-bit SIMD regs in ARM model, better BOUNDER_RULE, slow-ARM field optimizations s2n-bignum original commit: awslabs/s2n-bignum@06781d2

davidben and others added 30 commits November 18, 2020 22:56

acvp: add SHA-512/256 support.

806c505

Change-Id: Ib5d69d82c4cfc8cc172bdb5d9a739af53f9d2899 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44165 Reviewed-by: David Benjamin <[email protected]> Commit-Queue: Adam Langley <[email protected]>

Improve sk_dup.

f8047e2

No need to use |sk_new|, which allocates a buffer that will immediately be realloced. Change-Id: If0a787beac19933d93c5f9a3a8b560edd027c16c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44205 Reviewed-by: Adam Langley <[email protected]>

draft-ietf-tls-certificate-compression is now RFC 8879.

41a1430

Change-Id: I55ef8c4987c1205de9eb16243ffd4efc6aa1c5bd Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44344 Reviewed-by: Adam Langley <[email protected]> Commit-Queue: Adam Langley <[email protected]>

Const-correct GENERAL_NAME_cmp.

225961d

Also make it a little shorter. Change-Id: I6ee9d7666e9cf622509c54966a88f899a1974f9f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44405 Reviewed-by: Adam Langley <[email protected]>

acvp: fix subprocess_test.go

329c0cb

Change-Id: Ia3d98b00365ed92cbf7d02cdb55a1a16e431c4f4 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44384 Reviewed-by: David Benjamin <[email protected]>

acvp: add TLS KDF support

f040001

Change-Id: I4f4a89f97e2513d8b5b740620989b187a7b44a58 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44386 Commit-Queue: Adam Langley <[email protected]> Reviewed-by: David Benjamin <[email protected]>

Implement GREASE for ECH (draft-ietf-tls-esni-08).

1920c6f

Bug: 275 Change-Id: I4927c0886e3acf5b39104e3d89ed51d67520a343 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40204 Reviewed-by: David Benjamin <[email protected]> Commit-Queue: David Benjamin <[email protected]>

acvp: add support for KAS

0898b07

Change-Id: Ida3ec65e81398881a71828dc1d51cf80be41bdbb Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44444 Commit-Queue: Adam Langley <[email protected]> Reviewed-by: David Benjamin <[email protected]>

bryce-shang force-pushed the merge-bssl branch from 6225e70 to 1cabb7d Compare February 18, 2021 18:04

Fixed build errors after merging bssl.

47c0fe5

bryce-shang force-pushed the merge-bssl branch from 1cabb7d to 47c0fe5 Compare February 18, 2021 22:29

bryce-shang added 2 commits February 18, 2021 16:48

Merge branch 'main' into merge-bssl

c3e7b34

Correct comments.

32577ae

bryce-shang requested review from andrew-kaufman and torben-hansen February 19, 2021 01:57

bryce-shang marked this pull request as ready for review February 19, 2021 02:11

torben-hansen reviewed Feb 19, 2021

View reviewed changes

Remove unused test data.

77b45e3

Replace string with token.

229ed4a

torben-hansen approved these changes Feb 22, 2021

View reviewed changes

andrew-kaufman approved these changes Feb 22, 2021

View reviewed changes

bryce-shang merged commit 5ef51ca into aws:main Feb 22, 2021

bryce-shang deleted the merge-bssl branch February 22, 2021 19:02

bryce-shang added a commit that referenced this pull request Feb 22, 2021

Revert "Merge bssl (#94)"

2ad3879

This reverts commit 5ef51ca.

bryce-shang mentioned this pull request Feb 22, 2021

Revert "Merge bssl" #96

Merged

bryce-shang restored the merge-bssl branch February 22, 2021 19:21

bryce-shang added a commit that referenced this pull request Feb 22, 2021

Revert "Merge bssl (#94)" (#96)

1f6ba82

This reverts commit 5ef51ca.

bryce-shang mentioned this pull request Feb 22, 2021

Merge bssl #97

Merged

torben-hansen pushed a commit to torben-hansen/aws-lc that referenced this pull request Nov 19, 2023

Merge pull request aws#94 from jargh/main

16779cd

64-bit SIMD regs in ARM model, better BOUNDER_RULE, slow-ARM field optimizations s2n-bignum original commit: awslabs/s2n-bignum@06781d2

aqjune-aws added a commit to aqjune-aws/aws-lc-public that referenced this pull request Mar 4, 2024

Merge pull request aws#94 from jargh/main

2df1938

64-bit SIMD regs in ARM model, better BOUNDER_RULE, slow-ARM field optimizations s2n-bignum original commit: awslabs/s2n-bignum@06781d2

dkostic pushed a commit to dkostic/aws-lc that referenced this pull request Jul 22, 2024

Merge pull request aws#94 from jargh/main

9f82fda

64-bit SIMD regs in ARM model, better BOUNDER_RULE, slow-ARM field optimizations s2n-bignum original commit: awslabs/s2n-bignum@06781d2

torben-hansen pushed a commit to torben-hansen/aws-lc that referenced this pull request Sep 18, 2024

Merge pull request aws#94 from jargh/main

159ad31

64-bit SIMD regs in ARM model, better BOUNDER_RULE, slow-ARM field optimizations s2n-bignum original commit: awslabs/s2n-bignum@06781d2

torben-hansen pushed a commit to torben-hansen/aws-lc that referenced this pull request Sep 19, 2024

Merge pull request aws#94 from jargh/main

b7e5131

64-bit SIMD regs in ARM model, better BOUNDER_RULE, slow-ARM field optimizations s2n-bignum original commit: awslabs/s2n-bignum@06781d2

dkostic pushed a commit to dkostic/aws-lc that referenced this pull request Dec 5, 2024

Merge pull request aws#94 from jargh/main

06781d2

64-bit SIMD regs in ARM model, better BOUNDER_RULE, slow-ARM field optimizations

dkostic pushed a commit to dkostic/aws-lc that referenced this pull request Dec 10, 2024

Merge pull request aws#94 from jargh/main

aa52f3f

64-bit SIMD regs in ARM model, better BOUNDER_RULE, slow-ARM field optimizations s2n-bignum original commit: awslabs/s2n-bignum@06781d2

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Merge bssl #94

Merge bssl #94

bryce-shang commented Feb 18, 2021 •

edited

Loading

torben-hansen Feb 19, 2021

andrew-kaufman Feb 22, 2021

torben-hansen Feb 19, 2021

bryce-shang Feb 19, 2021 •

edited

Loading

torben-hansen Feb 19, 2021

bryce-shang Feb 19, 2021

torben-hansen Feb 22, 2021

torben-hansen Feb 19, 2021

bryce-shang Feb 19, 2021 •

edited

Loading

torben-hansen Feb 19, 2021

bryce-shang Feb 19, 2021

torben-hansen Feb 22, 2021

torben-hansen Feb 19, 2021

bryce-shang Feb 19, 2021

torben-hansen Feb 19, 2021

bryce-shang Feb 19, 2021 •

edited

Loading

torben-hansen Feb 19, 2021

bryce-shang Feb 19, 2021 •

edited

Loading

torben-hansen Feb 19, 2021

bryce-shang Feb 19, 2021 •

edited

Loading

torben-hansen commented Feb 19, 2021

bryce-shang commented Feb 19, 2021

torben-hansen Feb 22, 2021

torben-hansen Feb 22, 2021

Merge bssl #94

Merge bssl #94

Conversation

bryce-shang commented Feb 18, 2021 • edited Loading

Issues:

Description of changes:

Call-outs:

Testing:

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bryce-shang Feb 19, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bryce-shang Feb 19, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bryce-shang Feb 19, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bryce-shang Feb 19, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bryce-shang Feb 19, 2021 • edited Loading

Choose a reason for hiding this comment

torben-hansen commented Feb 19, 2021

bryce-shang commented Feb 19, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bryce-shang commented Feb 18, 2021 •

edited

Loading

bryce-shang Feb 19, 2021 •

edited

Loading

bryce-shang Feb 19, 2021 •

edited

Loading

bryce-shang Feb 19, 2021 •

edited

Loading

bryce-shang Feb 19, 2021 •

edited

Loading

bryce-shang Feb 19, 2021 •

edited

Loading