# Motivation
BoringSSL exposes AES-GCM-SIV algorithms which are in general useful to have and provide a nonce-misuse resistant mode of AES-GCM. Since, `CryptoKit` is not exposing AES-GCM-SIV we need to add this to `_CryptoExtras`
# Modification
Exposes `AES-GCM-SIV` through `_CryptoExtras`.
# Result
We can now use `AES-GCM-SIV` through `_CryptoExtras`.
* Make BoringSSL wrapper match CryptoKit behaviour when working with x963 representation
* Revert Package.swift changes
* Fix Signing tests and add test cases for invalid key lengths
* Bring over API files from macOS Ventura
* Implement the new API surface
This patch implements the new API surface, and removes anything that's
no longer compatible with the expected API surface from CryptoKit
Without the explicit typing, the build fails with recent toolchain
builds expecting the type to conform to an incorrect type. This
repairs the build.
Co-authored-by: Cory Benfield <lukasa@apple.com>
When contentLength is greater than 8 bits, i.e., greater than UInt8.max, the original implementation crashes.
To work around this, use UInt8.init(truncatingIfNeeded:) to truncate only the lower 8 bits.
Motivation:
When using only the CryptoKit API on Apple platforms we have always
thunked through to the CryptoKit interface and implementation. However,
we didn't do a thorough job of preventing the BoringSSL target from
getting compiled and linked.
We can do a better job now, which will save compile times and binary
sizes in many cases.
Modifications:
- Change Package.swift to express a target specific dependency in most
cases.
- Preserve a development mode which overrides that target specific
dependency.
- Add the missing compile guards.
Results:
Smaller binaries and faster compiles on Apple platforms.
Motivation:
CryptoKit supports the compressed key format: we should as well.
Modifications:
Extend the constructors of public keys to tolerate the compressed
representation.
Result:
Users holding compressed keys can use them.
Motivation:
I couldn't build for Android armv7 on the CI I set up without this.
Modifications:
Initialize with the right size of UInt to BoringSSL.
Result:
I can build for armv7 again.
Co-authored-by: Cory Benfield <lukasa@apple.com>
Motivation:
The various Apple SoS projects are currently dropping Swift 5.1 support.
Swift Crypto should do the same. While we're here, let's add CI for 5.4,
5.5 nightlies, and main nightlies.
Modifications:
- Remove 5.1 dockerfile.
- Stop claiming we support 5.1.
- Add 5.4, 5.5, and main dockerfiles.
- Updated Swift Format to 5.2.
- Associated formatting changes.
Result:
Better test matrix and support matrix.
Motivation:
Some critical use-cases require RSA signing support. This is most
commonly required when interacting with legacy systems. While RSA is an
older and less efficient cryptosystem than the elliptic-curve algorithms
supported by Swift Crypto already, those interop use-cases are
unavoidable.
This version of the patch does not promote RSA to supported API at this
time, as we'd like to let the API bake somewhat. Users are free to use
it, but these APIs are not covered by semantic versioning at this time
and may break in future.
Modifications:
- Defined new RSA API
- Implemented on top of `Security` when available
- Implemented on top of BoringSSL when `Security` is unavailable
Result:
Users can do RSA if needed.
The `include` directory is required for the interface include
directories for using `CCryptoBoringSSL` as a module from an external
package (i.e. SPM). This allows SPM to include `CCryptoBoringSSL`
and find the module map.
When building swift-crypto from source for a toolchain build, it is
convenient to build it without building up a toolchain image. This
additional knob allows for building swift-crypto with the build
artifacts of previous builds, allowing building up a toolchain image
while chaining multiple builds together.
Co-authored-by: tomer doron <tomer@apple.com>
* Setup docker for cmake build
Motivation:
Be able to run cmake build in CI
Modifications:
- Add "cmake" service to `docker-compose.yaml`
- Update `Dockerfile` to install `cmake` and `ninja`. Remove unneeded dependencies.
- Add `docker-compose.2004.53.yaml`. `cmake` on previous Ubuntu versions are too old and it would be a pain to upgrade, so using Ubuntu 20.04 to simplify things.
- Add back modulemap to ensure cmake build is successful
Result:
Can run cmake in CI
Motivation:
This is to support https://github.com/apple/swift-package-manager/pull/3202, which adds swift-crypto as a dependency to SwiftPM.
Modifications:
Add CMake files.
Result:
Can build swift-crypto with cmake.
Co-authored-by: Saleem Abdulrasool <compnerd@compnerd.org>
Co-authored-by: Saleem Abdulrasool <abdulras@google.com>
This adds the generated assembly files for Windows. Unfortunately, the
x64 generated assembly appears to be ELF-esque and SYSV ABI rather than
Win64. Additionally, the ARM targets do not seem to generate valid
Windows ARM code either (quick perusal shows at least invalid SP
handling on ARMv7 NT and non-conforming prologues on AArch64). Add x86
Windows assembly only for the time being.
Co-authored-by: Cory Benfield <lukasa@apple.com>
Resolves [issue#51](https://github.com/apple/swift-crypto/issues/51).
In Swift 5.3, a warning is viewed on Linux because `memset_s` implemented in this module returns `Void`.
This commit let the function return the same type with Darwin.
Motivation:
At WWDC 2020 Apple updated the CryptoKit APIs. This PR brings those new
APIs to Swift Crypto. This brings Swift Crypto up-to-date with the
latest CryptoKit API support, including PEM/DER key support and HKDF API
extensions.
Modifications:
- Bring forward the CryptoKit API files
- Update to have API match the WWDC seed.
Result:
Users will have access to the seed APIs.
Motiviation:
One `let` was hiding as a `var` and a few `#file` parameters have been
forwarded to (now) `#filePath` ones.
Modification:
- make the `var` a `let`
- silence the `#file`/`#filePath` warning by adding `(#file)` because we
can't forward them properly right now
(https://bugs.swift.org/browse/SR-12934). That's okay because even on
the Swift master branch, `#file` == `#filePath`.
Result:
No warnings in newer Swift compilers.
Motivation:
BoringSSL and Folly both attempt to play silly buggers with the sdallocx
symbol defined in jemalloc. Unfortunately, they don't play nicely
together, and the end result if you have both present is that BoringSSL
will reliably SIGBUS or SIGSEGV on initialization. Naturally, this isn't
good.
See also apple/swift-nio-ssl#191.
Modifications:
- Resolve the issue by patching out BoringSSL's allocator optimisation.
- Update BoringSSL to 6432bb46ab44731567ec923e6c8fc182f13d0070.
Result:
Flow and BoringSSL will play better together.
* 1) Adding gyb to scripts
2) Adding warning in gyb files about gyb overwritting manual edits to gyb generated swift files
3) Updated README with gyb instructions
4) Adding script for running all gyb generation
5) Adding CI check for discrepancies in gyb generated files
* Updating Dockerfile
Franz Busch