René Meusel

@randombit Is there anything we can do to help here? Apparently automatic scanners (e.g. [gitguardian.com](https://www.gitguardian.com/)) pick this up and contacted us about a potential security issue regarding this token in...

Apparently clang had a oopsie on macos-13 building the amalgamation. This seems to be caused by the changes in this PR, given that the base PR (#5101) seems to pass...

> Would something along these lines be a valuable addition, or too specific to my use-case? I really like the idea in general. This is a long-running computation by definition...

Thanks for the ping on this! Our next release is just around the corner. We'll see whether we can still make it for that.

For the record: Currently, there is an ongoing tender from BSI ([Projekt 663](https://ted.europa.eu/en/notice/-/detail/487118-2025) - partially in German) that explixitly requests the implementation of [draft-ietf-lamps-dilithium-certificates](https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates) among other things. Whoever wins this...

> So all in all, we think it would be possible to achieve something similar with TLS 1.3 but it is definitely way more complex. We suggest to keep this...

Looking at the CI outputs, we seem to get in trouble with macOS (Xcode 13 and 14) and Android NDK. For both of which [we claim to only support the...

> Merged both PRs you linked in here, let's see what happens.. Thanks. I was about to propose exactly that. The macOS 26 PR currently doesn't work -- some Python-based...

> I ended up assuming ARMv6 is ok🤞 I'm guessing it is. Existing users still have the escape hatch of disabling the modules that use password-based key derivation if they...