Merge pull request #1 from rorkai/codex/wasi-thread-specific-storage

fix: support thread-specific storage on WASI

[5.x] Align with CryptoKit APIs from Xcode 27 beta 1 (apple#442)

## Motivation

Xcode 27 beta is now available[^1] with new CryptoKit API so we need to
provide the cross-platform API here.

## Modifications

- Update shared API surface to align with CryptoKit
- Provide backing implementations for non-Apple platforms
- Bump minimum Swift version to 6.2
- Adopt `Lifetimes` language feature
- Provide Dev Container config for maintainers working on Linux backend
- Update CI to 6.2, where required
- Update CMake build
- Remove duplicate tests

## Result

Adopters can try out new APIs via this cross-platform package.

[^1]: https://developer.apple.com/download/all/?q=Xcode%2027

Add module anchor to fix empty dynamic framework on Xcode 26 (apple#436)

## Summary

Fixes apple#435.

On Apple platforms every source file in the `Crypto` target compiles to
just `@_exported import CryptoKit` (because `CRYPTO_IN_SWIFTPM` is
defined but `CRYPTO_IN_SWIFTPM_FORCE_BUILD_API` is not), producing
**zero exported symbols**.

Xcode 26 changed how SPM packages are built for test-target
dependencies: each package product is built as a separate dynamic
framework. A module with no symbols generates a `.framework` directory
but no Mach-O binary, causing a linker error:

```
clang: error: no such file or directory:
  '.../PackageFrameworks/Crypto_17A3B1FFC41E47_PackageProduct.framework/Crypto_17A3B1FFC41E47_PackageProduct'
```

## Fix

Added a minimal `_CryptoModuleAnchor` public enum (outside the
conditional compilation guard) so the module always produces at least
one exported symbol, regardless of how it is linked. The type is
prefixed with `_` to signal it is not intended for public use.

## Test plan

- [ ] Build a project with a test target that has `swift-crypto` (or a
transitive dependency like `swift-certificates`) as a
`packageProductDependency` on Xcode 26 targeting iOS Simulator — should
now succeed
- [ ] Verify existing tests still pass (`swift test`)

---------

Co-authored-by: Niccolò Calamai <niccolo.calamai@esselunga.it>
Co-authored-by: Cory Benfield <lukasa@apple.com>

Drop Swift 6.0 (apple#434)

Motivation:

Swift 6.0 is no longer supported, we should bump the tools version and
remove it from our CI.

Modifications:

* Bump the Swift tools version to Swift 6.1
* Remove Swift 6.0 jobs where appropriate in main.yml, pull_request.yml

Result:

Code reflects our support window.

Merge commit from fork

* Reproduce memory-safty issue in HPKE decapsulation

* Validate ciphertext len before calling decapsulate

update `actions/checkout` from v4 to v6 (apple#431)

Motivation

* Following [GitHub's
announcement](https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/),
Node 20 is being deprecated and runners will begin using Node 24 by
default starting March 4th, 2026. Node 20 will reach end-of-life in
April 2026.

Modifications

* Upgrade GitHub Actions to their latest versions to ensure
compatibility with Node 24.
* Replace `actions/checkout@v4` with `actions/checkout@v6` in all
workflow files.

Result

* Workflow files reference `actions/checkout@v6`.

Add RSA PKCSv1.5 padding support for legacy compat (apple#425)

Add RSA PKCSv1.5 padding support for legacy compat

### Checklist
- [X] I've run tests to see all new and existing tests pass
- [X] I've followed the code style of the rest of the project
- [X] I've read the [Contribution Guidelines](CONTRIBUTING.md)
- [X] I've updated the documentation if necessary

#### If you've made changes to `gyb` files
- [n/a] I've run `./scripts/generate_boilerplate_files_with_gyb.sh` and
included updated generated files in a commit of this pull request

### Motivation:
I have a scenario that requires me to be able to encrypt and decrypt
values that use RSA PKCSv1.5 padding. This is known to be a weak
algorithm, so we explicitly want to discourage its use, but there are
scenarios where you need the algorithm for legacy compatibility, so we
want to provide the capability, even if we strongly discourage its use.

### Modifications:
Added a new enum + constant + passthrough to allow users to specify RSA
PKCSv1.5. From the internal review, we thought it would be best to
explicitly name the constants in a way that discouraged use without very
intentional needs, hence the "weak" and "insecure" references in all of
the naming.

### Result:
You can now specify PKCSv1.5 padding for use in encryption and
decryption. This is only adding constants, and the enums are not public,
so there should not be any impact on compatibility (source or binary).

Co-authored-by: Mike Schrag <schrag@apple.com>

Incorrect maximum encryption size for RSA OAEP (apple#423)

Incorrect maximum encryption size for RSA OAEP

### Checklist
- [X] I've run tests to see all new and existing tests pass
- [X] I've followed the code style of the rest of the project
- [X] I've read the [Contribution Guidelines](CONTRIBUTING.md)
- [X] I've updated the documentation if necessary

#### If you've made changes to `gyb` files
- [n/a] I've run `./scripts/generate_boilerplate_files_with_gyb.sh` and
included updated generated files in a commit of this pull request

### Motivation:
The `maximumEncryptSize` function is hardcoded to use 42 as the hash
offset, but the RFC actually says it's "2*hLen-2" so 42 is only valid
for SHA1. SHA256 should be 62 (2*32-2). This adds a hash length onto the
Digest enum, which can then be used in the length calculation.

In writing the tests for this, I also stumbled on the unsafe PEM
representation for RSA Public Keys don't allow 1024-bit keys as
documented, so this also fixes that.

### Modifications:
* Added a `hashBitLength` to the RSA Digest which is then used in the
`maximumEncryptSize` to properly compute the maximum length
* Corrected the minimum key size for RSA unsafe PEM public keys to 1024
from 2048

### Result:
* The `maximumEncryptSize` function will return the expected value for
RSA OAEP SHA256 keys. I don't believe anything calls this internally, so
this would be for external consumers.
* Unsafe construction of RSA public keys now allow 1024 bit keys. It was
documented as supporting them, but the check was still 2048 (probably
copy-paste error from the safe variant). This only expands the potential
uses, so it shouldn't introduce any new failures.

Co-authored-by: Mike Schrag <schrag@apple.com>

Update README for 4.0 release (apple#418)

Enable Swift 6.2 jobs in CI (apple#414)

Motivation:

Swift 6.2 has been released, we should add it to our CI coverage.

Modifications:

Add additional Swift 6.2 jobs where appropriate in main.yml,
pull_request.yml

Result:

Improved test coverage.