Chiebot-Mirror/boringssl - boringssl - Gitea: Git with a cup of tea

Author	SHA1	Message	Date
David Benjamin	4f1fae3043	Fix the easy -Wformat-signedness errors. GCC has a warning that complains about even more type mismatches in printf. Some of these are a bit messy and will be fixed in separate CLs. This covers the easy ones. The .*s stuff is unfortunate, but printf has no size_t-clean string printer. ALPN protocol lengths are bound by uint8_t, so it doesn't really matter. The IPv6 printing one is obnoxious and arguably a false positive. It's really a C language flaw: all types smaller than int get converted to int when you do arithmetic. So something like this first doesn't overflow the shift because it computes over int, but then the result overall is stored as an int. uint8_t a, b; (a << 8) \| b On the one hand, this fixes a "missing" cast to uint16_t before the shift. At the same time, the incorrect final type means passing it to %x, which expects unsigned int. The compiler has forgotten this value actually fits in uint16_t and flags a warning. Mitigate this by storing in a uint16_t first. The story doesn't quite end here. Arguments passed to variadic functions go through integer promotion[0], so the argument is still passed to snprintf as an int! But then va_arg allows for a signedness mismatch[1], provided the value is representable in both types. The combination means that %x, though actually paired with unsigned, also accept uint8_t and uint16_t, because those are guaranteed to promote to an int that meets [1]. GCC recognizes [1] applies here. (There's also PRI16x, but that's a bit tedious to use and, in glibc, is defined as plain "x" anyway.) [0] https://en.cppreference.com/w/c/language/conversion#Default_argument_promotions [1] https://en.cppreference.com/w/c/variadic/va_arg Bug: 450 Change-Id: Ic1d41356755a18ab922956dd2e07b560470341f4 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50765 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>	3 years ago
David Benjamin	3a036c76eb	Add SSL_ech_accepted API and ech_is_required alerts. The first thing any deployment will want to monitor is whether ECH was actually used. Also it's useful if the command-line tool can output this. (The alert is how the client signals it discarded the connection due to ECH reject.) This also disables ECH with the handoff mechanism for now. (The immediate cause being that ech_accept isn't serialized.) We'll probably need to make some decisions around the ordering here, since ECH affects where the true ClientHello is available. Bug: 275 Change-Id: Ie4559733290e653a514fcd94431090bf86bc3172 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47911 Reviewed-by: Adam Langley <agl@google.com>	4 years ago
David Benjamin	571c3e78bf	Use gai_strerrorA on Windows. gai_strerror is one of the Windows functions which behaves differently whether UNICODE is defined. See https://docs.microsoft.com/en-us/windows/win32/intl/conventions-for-function-prototypes Call gai_strerrorA so that we behave consistently in both modes. This fixes the build failure in https://chromium-review.googlesource.com/c/chromium/src/+/2613519. It also fixes a type error in the connect BIO (built but not used in Chromium), which wasn't noticed because ERR_add_error_data is a variadic function and untyped. (The type error won't go out of bounds because we're interpreting a NUL-terminated WCHAR* as a NUL-terminated char. The string will be misinterpreted, but it still will be terminated either at the NUL WCHAR or, more likely, the upper zero byte of the first Latin-1 character in the string.) The ERR_add_error_data call raises the question of which of our char strings are UTF-8 and which are the POSIX locale / Windows code page (when those are not also UTF-8). This CL doesn't address this and only fixes the character width error. Realistically, calling code tosses char* to printf so often that non-UTF-8 locales are probably a lost cause. (Although right now we do not transform any OS error strings, so tossing them to printf works fine. The outputs of functions like ASN1_STRING_to_UTF8, not so much.) Change-Id: Ie789730658829bde90022605ade2c86b8a65c3de Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44964 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>	4 years ago
Adam Langley	fb0c05cac2	acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>	5 years ago