Since X509Name is more complex than a single value (it's a a sequence
of entries) it's useful to be able to serialise/deserialise to/from
flat data, and DER is a natural form for this.
So add a {i2d,d2i}_X509_NAME -sys functions, and to_der/from_der
wrappers in X509NameRef and X509Name respectively.
Originally added in https://github.com/sfackler/rust-openssl/pull/1534
Sometimes google replies with 302 to redirect to another Google website
with a country-specific TLD. We don't actually care which status code
is returned, just that we successfully connect to google.com with
the HTTPS connector.
According to [the docs](https://doc.rust-lang.org/stable/std/mem/fn.uninitialized.html),
> Calling this when the content is not yet fully initialized causes immediate undefined behavior.
> it [is] undefined behavior to have uninitialized data in a variable even if that variable has an integer type.
Using MaybeUninit instead, as recommended by the official documentation, avoids undefined behavior by not creating a `&mut` reference to uninitialized data.
Cross-compiling to AArch64 Linux can be done with a CMake toolchain
file, along with setting the correct compiler and include paths in the
environment.
Cross-compiling from X64 Windows to ARM64 Windows doesn't look at the
toolchain at all, because CMake + Visual Studio can already
cross-compile. Unfortunately, the Visual Studio CMake generator
doesn't set CMAKE_SYSTEM_PROCESSOR, which is what the BoringSSL
CMakeLists.txt is looking at to choose the architecture. For now,
disable the use of assembly when cross-compiling on Windows (assuming
that the Visual Studio generator will be used there).
While it's possible to build Rust tests into an iOS app, start up
a simulator instance, upload the tests there, and launch them --
that's a bit involved process. For now, just check that BoringSSL
compiles for the specified target. Use "--all-targets" to check
all targets, including the unit tests.
Even if "cargo test --target ${arch}-apple-ios" cross-compiles tests,
it's not possible to actually run them on the host macOS, as that's
a different execution environment.
Although, I guess, we could try only building tests with "--no-run",
GitHub Actions do not make it easy to construct command lines based
on matrix parameters. Thus it's easier to disable these steps, and
the following commit adds a "--no-run" step with "--target".
As pointed out in the comment, bindgen generates tests that cause
compiler warnings about misaligned references. bindgen people are
aware of the issue, but we have to deal with our warnings that are
treated as errors. For the time being, suppress alignment tests
on platforms that are known to be triggering UB.
I suspect that other non-x86 platforms are affected as well, but I can't
get the tests to compile for those tests at the moment, so I'm not sure.
Dealing with the issues one platform at a time.
cfg!() is evaluated for the host OS executing build.rs script.
What we need here is to look whether we are building *for* macOS.
Otherwise, for example, builds for iOS on macOS will try to add this
flag, causing warnings since rustc does not build cdylibs on iOS.
When bindgen generates bindings for iOS, it must be told to use iOS
sysroot with all the standard C headers. Otherwise it tries using
the host macOS headers and fails miserably.
The architecture alone is not enough. aarch64-apple-ios and
aarch-apple-ios-sim are both building for aarch64, but they need
slightly different CMake flags.
Wrap BN_bn2bin_padded() which comes useful for exporting fixed-length
BIGNUMs, more efficient than padding result of to_vec() afterwards.
Note that in OpenSSL the function is called BN_bn2binpad() and has
a different order of arguments. BoringSSL's BN_bn2bin_padded() also
takes the desired length as "size_t".
Anthony Ramine