Even before this past week's XZ backdoor revelation, checking binaries into source control rather than building from source seems quite questionable. In fairness to the Bun developer's, they have a comment in their build.zig file acknowledging that this shim should be built more normally rather than being checked in.
For no discernible reason, it is using a bunch of undocumented Windows APIs. The source cites this Zig issue as one reason for why they think it is OK to use undocumented APIs:
I don't see any good reasons here cited for using undocumented, unstable interfaces. For Zig's part, there seems to be some poorly-explained interest in linking against "lower level" libraries without any motivating use case (just some hand waving about security and drivers, neither of which makes much sense. Onecore.lib is a thing if you wanted a documented way of linking an executable that run on a diverse set of Windows form factors. And compiling drivers may as well be treated as a seperate target, since function names are different). For Bun, I assume they are trying to have low binary size. But targeting NTDLL vs. Kernel32 should not make a big difference, especially when the shim is just doing basic file IO. For an example of making small executable with standard API, you can make hello world 4kb using MSVC just by using /NODEFAULTLIB and /ENTRY:main with link.exe and this program :
So it should be possible to make a .bunx shim of small size without having to resort to undocumented API. (Current exe is 12kb). But even if the shim exe was 100kb, that would be still be an acceptable tradeoff for me than having to debug any problem that results from using non-standard APIs.
the motivation behind zig#1840 is that while the functions in ntdll aren't as well documented as the kernel32 functions, theyre not unstable and not having our binaries depend on kernel32.dll would lead to faster startup times as well as allow us to do things like use more performant algorithms for UTF-8 <-> UTF-16 conversion. on top of the things mentioned in the issue like having APIs with more powerful features.
For Bun's shim, it is linking against kernel32 anyways. And there is nothing special about it's use of NtCreateFile, NtReadFile, NtWriteFile, and NtClose that would preclude it from using the standard functions.
I'm not sure it's possible to not have kernel32 loaded into your process anyways. Even if you create an EXE that imports 0 DLLs, kernel32 gets loaded into the process by NTDLL. The callstack from main:
There are valid reasons to use APIs from NTDLL. Where I disagree with zig#1840 is the idea that it is always better to use NTDLL versions of API. Every other software ecosystem uses the standard Win32 APIs and diverging from that without a good reason seems like a good way to have unexpected behavior. One concrete example is most users and programmers expect Windows to redirect some file system paths when running on WOW64. But this is implemented in Kernel32, not ntdll.
https://github.com/oven-sh/bun/blob/801e475c72b3573a91e0fb4c...
Even before this past week's XZ backdoor revelation, checking binaries into source control rather than building from source seems quite questionable. In fairness to the Bun developer's, they have a comment in their build.zig file acknowledging that this shim should be built more normally rather than being checked in.
Then I look into the source for it:
https://github.com/oven-sh/bun/blob/801e475c72b3573a91e0fb4c...
For no discernible reason, it is using a bunch of undocumented Windows APIs. The source cites this Zig issue as one reason for why they think it is OK to use undocumented APIs:
https://github.com/ziglang/zig/issues/1840
I don't see any good reasons here cited for using undocumented, unstable interfaces. For Zig's part, there seems to be some poorly-explained interest in linking against "lower level" libraries without any motivating use case (just some hand waving about security and drivers, neither of which makes much sense. Onecore.lib is a thing if you wanted a documented way of linking an executable that run on a diverse set of Windows form factors. And compiling drivers may as well be treated as a seperate target, since function names are different). For Bun, I assume they are trying to have low binary size. But targeting NTDLL vs. Kernel32 should not make a big difference, especially when the shim is just doing basic file IO. For an example of making small executable with standard API, you can make hello world 4kb using MSVC just by using /NODEFAULTLIB and /ENTRY:main with link.exe and this program :
So it should be possible to make a .bunx shim of small size without having to resort to undocumented API. (Current exe is 12kb). But even if the shim exe was 100kb, that would be still be an acceptable tradeoff for me than having to debug any problem that results from using non-standard APIs.