Proposal: a steady stream of small, tested PRs towards running x86_64 macOS apps on Linux and WSL2

[fitandre]

Hi Darling maintainers,

I'm Andre (@fitandre). I'm starting a long-running effort to make Darling run unmodified x86_64 macOS apps on x86_64
Linux and on Windows 11 through WSL2, and I want it to happen upstream, in Darling, not in a hard fork. Before
sending more PRs, I'd like to agree on a way of working that is easy for you to review.

What I'd like to propose

• Small PRs. One concern per PR, usually under 400 changed lines, each with a darling-testsuite case or a short
  note on why it can't be tested, and exact reproduction steps (distro, compiler, commands).
• A named owner, and AI assistance disclosed. Much of the work is prepared with AI coding tools. Every PR names a
  human owner (me) who has reviewed it and answers for it, and says plainly that it was AI-assisted. If you'd rather
  not receive AI-assisted PRs at all, or only some kinds, please tell me and I'll respect that.
• Larger designs discussed first. Anything bigger than a fix (for example a Metal.framework built on
  metal2vulkan's Metal-on-Vulkan runtime) would start as a short design
  note in Discussions, so you can say "yes", "not like this" or "not in Darling" before any code is written.
• A pace you choose. I'll keep at most a few PRs open at a time and won't ping for reviews; tell me the cadence
  that works for you.

What I can offer without money

• CI evidence: I build Darling (COMPONENTS=stock) and run darling shell on Ubuntu 24.04, Fedora 44 and Arch on every
  change, and can attach logs to PRs and issues.
• Issue reports with reproductions, for example: -DCOMPONENTS=cli alone fails to link secd (ld: library not found for -lCoreData #1603, fix proposed in
  Build the CoreData stub for a cli-only build (-DCOMPONENTS=cli) #1789), and the newest Arch clang emits Objective-C constant literals (NSConstantArray, NSConstantDictionary)
  that Darling's Foundation doesn't provide yet.
• Help with testing other contributors' PRs on those three distros, if that's useful to you.
• A survey of darling-corecrypto, which I'd like to work on first because HTTPS, Keychain and signature checks depend
  on it. About 222 of its ~460 functions still print DARLING CRYPTO STUB. Hashes, AES and HMAC work. Most of RSA
  (key generation, private-key operations, key decoding), most of ccec (NIST curves), parts of GCM,
  ChaCha20-Poly1305, CMAC, CCM, DH and ccz are stubs. I also compared it with NeoDarwin's clean-room corecrypto
  (MPL-2.0, https://github.com/NeoDarwinOS/corecrypto). It implements only about 10 of those stubbed functions, and it
  has no ccec, GCM or ccder. So darling-corecrypto remains the better base, though NeoDarwin's NIST CTR-DRBG and
  kernel PRNG code could be reused, with MPL notices kept. Counts come from a text scan of the sources, so they are
  approximate.

Questions

1. Are you open to this way of working, and to AI-assisted PRs under the rules above?
2. Is there one maintainer I should address PRs to, or a label you'd like me to use?
3. For newer compilers (clang 22+), would you prefer build flags (-fno-objc-constant-literals,
   -Wno-error=incompatible-pointer-types) in CMake, or fixes in the affected code?
4. While a PR waits for review I'd keep it in my fork (fitandre/darling) so people can try it. Is that fine with you?
5. For the missing darling-corecrypto families, my plan is to start with what TLS needs: EC P-256/P-384, RSA, AES-GCM
   and ChaCha20-Poly1305. Would you accept implementations written in Rust? That would be a small static library
   exporting the same C ABI, built on the RustCrypto crates (MIT/Apache-2.0) and added one family per PR. Or should
   they stay in C?
6. Would you be open to pulling selected files from NeoDarwin's corecrypto (MPL-2.0) into darling-corecrypto?

Thanks for Darling, and for your time.

Andre

[CuriousTommy]

Are you open to this way of working, and to AI-assisted PRs under the rules above?

One concern I have with AI is what the AI was trained from. For simple contributions, I don't really have an issue with AI contributions (as along as people are upfront about it).

However... For any AI assisted contributions that makes involved modifications to Apple's APIs, I would have to reject it. For example, if I see an AI assisted contribution that implemented Storyboard support for AppKit, I would reject it for legal reasons.

While a PR waits for review I'd keep it in my fork (fitandre/darling) so people can try it. Is that fine with you?

You're free to do whatever you want in your fork.

Would you accept implementations written in Rust?

I rather not add a build dependency for Rust (unless Apple themselves starting using Rust in their system libraries).

Would you be open to pulling selected files from NeoDarwin's corecrypto (MPL-2.0) into darling-corecrypto?

If their project is at a better state than darling-corecrypto, it would makes more sense to just fork their project and integrate it into Darling's build system.

[LubosD]

We have an internal disagreement about AI-assisted contributions.

My stance is that legality is OK. No LLM has been trained on Apple's source code because LLMs have been trained on material available online, therefore there's no risk of Apple source code being reproduced into Darling.

My main ask is that the contributor is aware of what his PRs do and why. "AI spit this out" is not acceptable.

[CuriousTommy]

No LLM has been trained on Apple's source code because LLMs have been trained on material available online, therefore there's no risk of Apple source code being reproduced into Darling.

We can't always trust code that's published online. For example, someone could publish leaked proprietary code to the public (or publish code that is non-open source/source available).

For example, someone could release Apple's official corecrypto source code (which is under a very restricted license) to a GitHub repository. Outside of Apple, I've seen leaked source code of Valve's Source engine.

[LubosD]

Sure thing, but I guess we would heard about an Apple code leak if it happened.

That being said, CoreCrypto is a special case. The risk of original code spilling into ours is very real.

[fitandre]

Dear Friends,

We plan to use the final code IN PRODUCTION as part of our desktop in the cloud service, then i will personally check all code sended one by one.

The goal here is to contribute with the community back...

Regards,

Andre

[fitandre]

Thanks, this is very helpful.

Understood on Rust: I'll stay in C. NeoDarwin's corecrypto is not in a better state (it has no ccec, GCM or ccder), so I won't propose switching.

On AI: every PR will be one I can explain line by line, and I'll answer review questions myself.

Two questions so I don't waste your time:

1. Where would you draw the line between "simple" and "involved" changes to Apple's APIs? Would build fixes, crash fixes with a test, and filling in a missing function from its public header count as simple?
2. My team works with AI tools, so I'd rather ask up front. For darling-corecrypto, would any of these be acceptable to you?
   a) AI-assisted code, with safeguards against Apple code leaking in: nobody on the team reads Apple's corecrypto source; each PR is checked by an automated similarity scan against Apple's published corecrypto, and the result is attached; every function is tested against NIST/Wycheproof test vectors; and I review it line by line.
   b) a thin layer, also AI-assisted, that maps the corecrypto API onto an established C crypto library, so none of the crypto math is written by us or by an AI;
   c) neither, and we keep CoreCrypto work in our fork only.

Andre

[LubosD]

I would say that checking that your corecrypto changes are not identical to Apple code is good enough of a safeguard.

[LubosD]

@fitandre Please see this PR for the AI policy we're introducing: #1811. I believe it should address all of your questions.