[main] Michijs Dependabot changes · Pull Request #16 · michijs/.github

ghost · 2025-09-15T01:06:20Z

Updated Packages

Bump bun-types from 1.2.21 to 1.2.22

ghost · 2025-09-15T01:06:21Z

Bump bun-types from 1.2.21 to 1.2.22

Changelog:

Sourced from releases.
        ### bun-v1.2.22To install Bun v1.2.22
curl -fsSL https://bun.sh/install | bash
# or you can use npm
# npm install -g bun
Windows:
powershell -c "irm bun.sh/install.ps1|iex"
To upgrade to Bun v1.2.22:
bun upgrade
Read Bun v1.2.22's release notes on Bun's blog

Thanks to 14 contributors!

@alii

@avarayr

@cirospaciari

@dylan-conway

@jarred-sumner

@lydiahallie

@markovejnovic

@nektro

@pfgithub

@robobun

@samyarkd

@sosukesuzuki

@taylordotfish

@zackradisic

Commit history:

6bafe2 Fix Windows shell crash with && operator and external commands (#22651)
What does this PR do?

Fixes https://redirect.github.com/oven-sh/bun/issues/22650
Fixes https://redirect.github.com/oven-sh/bun/issues/22615
Fixes https://redirect.github.com/oven-sh/bun/issues/22603
Fixes https://redirect.github.com/oven-sh/bun/issues/22602

Fixes a crash that occurred when running shell commands through bun run (package.json scripts) on Windows that use the && operator
followed by an external command.

The Problem

The minimal reproduction was:
```
bun exec 'echo && node --version'
```
This would crash with: panic(main thread): attempt to use null value

Root Causes

Two issues were causing the crash:
1. Missing top_level_dir: When runPackageScriptForeground creates
  a MiniEventLoop for running package scripts, it wasn't setting the
  top_level_dir field. This caused a null pointer dereference when the
  shell tried to access it.
2. MovableIfWindowsFd handling: After PR #21800 introduced
  MovableIfWindowsFd to handle file descriptor ownership on Windows, the
  IOWriter.fd could be moved to libuv, leaving it null. When the shell
  tried to spawn an external command after a && operator, it would crash
  trying to access this null fd.
The Fix
1. Set mini.top_level_dir = cwd after initializing the MiniEventLoop
  in run_command.zig
2. In IO.zig, when the fd has been moved to libuv (is null), use
  .inherit for stdio instead of trying to pass the null fd
How did you verify your code works?
- Added a regression test that reproduces the issue
- Verified the test fails without the fix and passes with it
- Tested the minimal reproduction command directly
- The fix correctly allows both commands in the && chain to execute
```
# Before fix: crashes
> bun exec 'echo test && node --version'
panic(main thread): attempt to use null value

# After fix: works correctly
> bun exec 'echo test && node --version'
test
v22.4.1
```
_{also probably fixes #22615 and fixes #22603 and fixes #22602}

Co-authored-by: Zack Radisic <zack@theradisic.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.redirect.github.com>
9411c6 Make the bundler tests use the API by default in most cases (#22646)

What does this PR do?

This branch:

Ran 1600 tests across 46 files. [63.24s]

Main:

Ran 1600 tests across 46 files. [137.05s]

This makes the bundler tests run about 60 seconds faster

How did you verify your code works?

8614b9 Disable glibcxx assertions in WebKit release non-asan builds (#22647)

What does this PR do?

Evidently, Ubuntu turns them on by default.

Claude:

> What is the typical overhead for glibcxx assertions?

⏺ The overhead of glibc/libstdc++ assertions can be significant, especially in
  performance-critical code:

  Typical Overhead Ranges:

  libstdc++ (C++ standard library) assertions:
  - 5-15% overall performance impact in typical applications
  - Up to 30-50% in container-heavy code (vectors, maps, etc.)
  - Iterator validity checks are particularly expensive

  glibc (C library) assertions:
  - 2-8% overall impact in typical applications
  - Up to 20% in malloc/free intensive code
  - Heap consistency checks, buffer overflow detection
 ```</li><li><a href="https://redirect.github.com/oven-sh/bun/commit/ecd23df4cab85230fe4447af8145587036d54158"><code>ecd23d</code></a> Fix banner positioning with --format=cjs --target=bun (#22641)

## Summary
- Fixes incorrect banner positioning when using `--banner` with
`--format=cjs` and `--target=bun`
- Ensures Bun-specific comments (`// @&ZeroWidthSpace;bun @&ZeroWidthSpace;bun-cjs`) appear before user
banner content
- Properly extracts and positions hashbangs from banner content

## Problem
When using `--banner` with `--format=cjs --target=bun`, the banner was
incorrectly placed before the `// @&ZeroWidthSpace;bun @&ZeroWidthSpace;bun-cjs` comment and CJS wrapper
function, breaking the module format that Bun expects.

## Solution
Implemented proper ordering:
1. **Hashbang** (from source file or extracted from banner if it starts
with `#!`)
2. **@&ZeroWidthSpace;bun comments** (e.g., `// @&ZeroWidthSpace;bun`, `// @&ZeroWidthSpace;bun @&ZeroWidthSpace;bun-cjs`, `// @&ZeroWidthSpace;bun
@&ZeroWidthSpace;bytecode`)
3. **CJS wrapper** `(function(exports, require, module, __filename,
__dirname) {`
4. **Banner content** (excluding any extracted hashbang)

## Test plan
- [x] Added comprehensive tests for banner positioning with CJS/ESM and
Bun target
- [x] Tests cover hashbang extraction from banners
- [x] Tests verify proper ordering with bytecode generation
- [x] All existing tests pass

🤖 Generated with [Claude Code](https://claude.ai/code)

---------

Co-authored-by: Claude <noreply@&ZeroWidthSpace;anthropic.com></li><li><a href="https://redirect.github.com/oven-sh/bun/commit/3d8139dc27cadd7a7b3b17cae6beefe0dd04f3ec"><code>3d8139</code></a> fix(bundler): propagate TLA through importers (#22229)

(For internal tracking: fixes ENG-20351)

---------

Co-authored-by: Dylan Conway <dylan.conway567@&ZeroWidthSpace;gmail.com>
Co-authored-by: Claude Bot <claude-bot@&ZeroWidthSpace;bun.sh>
Co-authored-by: Claude <noreply@&ZeroWidthSpace;anthropic.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@&ZeroWidthSpace;users.noreply.redirect.github.com>
Co-authored-by: taylor.fish <contact@&ZeroWidthSpace;taylor.fish></li><li><a href="https://redirect.github.com/oven-sh/bun/commit/beea7180f358f779ea84d5960c6db8d92bf1c603"><code>beea71</code></a> refactor(MySQL) (#22619)

### What does this PR do?

### How did you verify your code works?

---------

Co-authored-by: Jarred Sumner <jarred@&ZeroWidthSpace;jarredsumner.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@&ZeroWidthSpace;users.noreply.redirect.github.com></li><li><a href="https://redirect.github.com/oven-sh/bun/commit/8e786c1cfc4e5184f1a16778fddae49b8c58b982"><code>8e786c</code></a> Fix bug causing truncated stack traces (#22624)

### What does this PR do?

Fixes https://redirect.github.com/oven-sh/bun/issues/21593 (very likely)

### How did you verify your code works?

Regression test</li><li><a href="https://redirect.github.com/oven-sh/bun/commit/9b97dd11e2d19e751b44c8bd0c98ed18c66edac9"><code>9b97dd</code></a> Fix TTY reopening after stdin EOF (#22591)

## Summary
- Fixes ENXIO error when reopening `/dev/tty` after stdin reaches EOF
- Fixes ESPIPE error when reading from reopened TTY streams  
- Adds ref/unref methods to tty.ReadStream for socket-like behavior
- Enables TUI applications that read piped input then switch to
interactive TTY mode

## The Problem
TUI applications and interactive CLI tools have a pattern where they:
1. Read piped input as initial data: `echo "data" | tui-app`
2. After stdin ends, reopen `/dev/tty` for interactive session
3. Use the TTY for interactive input/output

This didn't work in Bun due to missing functionality:
- **ESPIPE error**: TTY ReadStreams incorrectly had `pos=0` causing
`pread()` syscall usage which fails on character devices
- **Missing methods**: tty.ReadStream lacked ref/unref methods that TUI
apps expect for socket-like behavior
- **Hardcoded isTTY**: tty.ReadStream always set `isTTY = true` even for
non-TTY file descriptors

## The Solution
1. **Fix ReadStream position**: For fd-based streams (like TTY), don't
default `start` to 0. This keeps `pos` undefined, ensuring `read()`
syscall is used instead of `pread()`.

2. **Add ref/unref methods**: Implement ref/unref on tty.ReadStream
prototype to match Node.js socket-like behavior, allowing TUI apps to
control event loop behavior.

3. **Dynamic isTTY check**: Use `isatty(fd)` to properly detect if the
file descriptor is actually a TTY.

## Test Results
```bash
$ bun test test/regression/issue/tty-reopen-after-stdin-eof.test.ts
✓ can reopen /dev/tty after stdin EOF for interactive session
✓ TTY ReadStream should not set position for character devices

$ bun test test/regression/issue/tty-readstream-ref-unref.test.ts
✓ tty.ReadStream should have ref/unref methods when opened on /dev/tty
✓ tty.ReadStream ref/unref should behave like Node.js

$ bun test test/regression/issue/tui-app-tty-pattern.test.ts
✓ TUI app pattern: read piped stdin then reopen /dev/tty
✓ tty.ReadStream handles non-TTY file descriptors correctly

Compatibility

Tested against Node.js v24.3.0 - our behavior now matches:

✅ Can reopen /dev/tty after stdin EOF
✅ TTY ReadStream has pos: undefined and start: undefined
✅ tty.ReadStream has ref/unref methods for socket-like behavior
✅ isTTY is properly determined using isatty(fd)

Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.redirect.github.com>
Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>

069a8d patch: make Header struct use one-based line indexing by default (#21995)

What does this PR do?
- Change Header struct start fields to default to 1 instead of 0
- Rename Header.zeroes to Header.empty with proper initialization
- Maintain @max(1, ...) validation in parsing to ensure one-based
  indexing
- Preserve compatibility with existing patch file formats
🤖 Generated with Claude Code

How did you verify your code works?

Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Zack Radisic <56137411+zackradisic@users.noreply.redirect.github.com>
9907c2 fix(patch): add bounds checking to prevent segfault during patch application (#21939)

Summary
- Fixes segmentation fault when applying patches with out-of-bounds line
  numbers
- Adds comprehensive bounds checking in patch application logic
- Includes regression tests to prevent future issues
Problem

Previously, malformed patches with line numbers beyond file bounds could
cause segmentation faults by attempting to access memory beyond
allocated array bounds in addManyAt() and replaceRange() calls.

Solution

Added bounds validation at four key points in src/patch.zig:
1. Hunk start position validation (line 283-286) - Ensures hunk
  starts within file bounds
2. Context line validation (line 294-297) - Validates context lines
  exist within bounds
3. Insertion position validation (line 302-305) - Checks insertion
  position is valid
4. Deletion range validation (line 317-320) - Ensures deletion range
  is within bounds
All bounds violations now return EINVAL error gracefully instead of
crashing.

Test Coverage

Added comprehensive regression tests in
test/regression/issue/patch-bounds-check.test.ts:
- ✅ Out-of-bounds insertion attempts
- ✅ Out-of-bounds deletion attempts
- ✅ Out-of-bounds context line validation
- ✅ Valid patch application (positive test case)
Tests verify that bun install completes gracefully when encountering
malformed patches, with no crashes or memory corruption.

Test Results
```
bun test v1.2.21
✅ Bounds checking working: bun install completed gracefully despite malformed patch
✅ Bounds checking working: bun install completed gracefully despite deletion beyond bounds
✅ Bounds checking working: bun install completed gracefully despite context lines beyond bounds

 4 pass
 0 fail
 22 expect() calls
Ran 4 tests across 1 file. [4.70s]
```
🤖 Generated with Claude Code

Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.redirect.github.com>
Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>
Co-authored-by: Zack Radisic <56137411+zackradisic@users.noreply.redirect.github.com>
3976fd Fix crash relating to linear-gradients in CSS (#22622)

What does this PR do?

Fixes #18924
2ac835 Update napi.test.ts
52b82c Fix: Allow napi_reference_unref to be called during GC (#22597)

Summary
- Fixes #22596 where Nuxt crashes when building with rolldown-vite
- Aligns Bun's NAPI GC safety checks with Node.js behavior by only
  enforcing them for experimental NAPI modules
The Problem

Bun was incorrectly enforcing GC safety checks
(NAPI_CHECK_ENV_NOT_IN_GC) for ALL NAPI modules, regardless of
version. This caused crashes when regular production NAPI modules called
napi_reference_unref from finalizers, which is a common pattern in the
ecosystem (e.g., rolldown-vite).

The crash manifested as:
```
panic: Aborted
- napi.h:306: napi_reference_unref
```
Root Cause: What We Did Wrong

Our previous implementation always enforced the GC check for all NAPI
modules:

Before (incorrect):
```
// src/bun.js/bindings/napi.h:304-311
void checkGC() const
{
    NAPI_RELEASE_ASSERT(!inGC(),
        "Attempted to call a non-GC-safe function inside a NAPI finalizer...");
    // This was called for ALL modules, not just experimental ones
}
```
This was overly restrictive and didn't match Node.js's behavior, causing
legitimate use cases to crash.

The Correct Solution: How Node.js Does It

After investigating Node.js source code, we found that Node.js only
enforces GC safety checks for experimental NAPI modules. Regular
production modules are allowed to call functions like
napi_reference_unref from finalizers for backward compatibility.

Evidence from Node.js Source Code

1. The CheckGCAccess implementation
(vendor/node/src/js_native_api_v8.h:132-143):
```
void CheckGCAccess() {
  if (module_api_version == NAPI_VERSION_EXPERIMENTAL && in_gc_finalizer) {
    // Only fails if BOTH conditions are true:
    // 1. Module is experimental (version 2147483647)
    // 2. Currently in GC finalizer
    v8impl::OnFatalError(...);
  }
}
```
2. NAPI_VERSION_EXPERIMENTAL definition
(vendor/node/src/js_native_api.h:9):
```
#define NAPI_VERSION_EXPERIMENTAL 2147483647  // INT_MAX
```
3. How it's used in napi_reference_unref
(vendor/node/src/js_native_api_v8.cc:2814-2819):
```
napi_status NAPI_CDECL napi_reference_unref(napi_env env,
                                            napi_ref ref,
                                            uint32_t* result) {
  CHECK_ENV_NOT_IN_GC(env);  // This check only fails for experimental modules
  // ... rest of implementation
}
```
Our Fix: Match Node.js Behavior Exactly

After (correct):
```
// src/bun.js/bindings/napi.h:304-315
void checkGC() const
{
    // Only enforce GC checks for experimental NAPI versions, matching Node.js behavior
    // See: https://redirect.github.com/nodejs/node/blob/main/src/js_native_api_v8.h#L132-L143
    if (m_napiModule.nm_version == NAPI_VERSION_EXPERIMENTAL) {
        NAPI_RELEASE_ASSERT(!inGC(), ...);
    }
    // Regular modules (version <= 8) can call napi_reference_unref from finalizers
}
```
This change means:
- Regular NAPI modules (version 8 and below): ✅ Can call
  napi_reference_unref from finalizers
- Experimental NAPI modules (version 2147483647): ❌ Cannot call
  napi_reference_unref from finalizers
Why This Matters

Many existing NAPI modules in the ecosystem were written before the
stricter GC rules and rely on being able to call functions like
napi_reference_unref from finalizers. Node.js maintains backward
compatibility by only enforcing the stricter rules for modules that
explicitly opt into experimental features.

By not matching this behavior, Bun was breaking existing packages that
work fine in Node.js.

Test Plan

Added comprehensive tests that verify both scenarios:

1. test_reference_unref_in_finalizer.c (Regular Module)
- Uses default NAPI version (8)
- Creates 100 objects with finalizers that call napi_reference_unref
- Expected: Works without crashing
- Result: ✅ Passes with both Node.js and Bun (with fix)
2. test_reference_unref_in_finalizer_experimental.c (Experimental

Module)
- Uses NAPI_VERSION_EXPERIMENTAL (2147483647)
- Creates objects with finalizers that call napi_reference_unref
- Expected: Crashes with GC safety assertion
- Result: ✅ Correctly fails with both Node.js and Bun (with fix)
Verification

The tests prove our fix is correct:
```
# Regular module - should work
$ bun-debug --expose-gc main.js test_reference_unref_in_finalizer '[]'
✅ SUCCESS: napi_reference_unref worked in finalizers without crashing

# Experimental module - should fail
$ bun-debug --expose-gc main.js test_reference_unref_in_finalizer_experimental '[]'
✅ ASSERTION FAILED: Attempted to call a non-GC-safe function inside a NAPI finalizer
```
Both behaviors now match Node.js exactly.

Impact

This fix:
1. Resolves crashes with rolldown-vite and similar packages
2. Maintains backward compatibility with the Node.js ecosystem
3. Still enforces safety for experimental NAPI features
4. Aligns Bun's behavior with Node.js's intentional design decisions
🤖 Generated with Claude Code

Co-Authored-By: Claude <noreply@anthropic.com>

Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.redirect.github.com>
Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>
Co-authored-by: Zack Radisic <zack@theradisic.com>
7ddb52 feat: Update BoringSSL to latest upstream (Sept 2025) - Post-quantum crypto, Rust support, and major performance improvements (#22562)

🚀 BoringSSL Update - September 2025

This PR updates BoringSSL to the latest upstream version, bringing 542
commits worth of improvements, new features, and security
enhancements. This is a major update that future-proofs Bun's
cryptographic capabilities for the quantum computing era.

📊 Update Summary
- Previous version: 7a5d984c69b0c34c4cbb56c6812eaa5b9bef485c
- New version: 94c9ca996dc2167ab670c610378a50a8a1c4672b
- Total commits merged: 542
- Files changed: 3,014
- Lines added: 135,271
- Lines removed: 173,435
🔐 Post-Quantum Cryptography Support

ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism)
- ML-KEM-768: NIST FIPS 204 standardized quantum-resistant key
  encapsulation
- ML-KEM-1024: Larger key size variant for higher security
- MLKEM1024 for TLS: Direct integration into TLS 1.3 for
  quantum-resistant key exchange
- Full ACVP (Automated Cryptographic Validation Protocol) support
- Private key parsing moved to internal APIs for better security
ML-DSA (Module-Lattice-Based Digital Signature Algorithm)
- ML-DSA-44: NIST standardized quantum-resistant digital signatures
- Efficient lattice-based signing and verification
- Suitable for long-term signature security
SLH-DSA (Stateless Hash-based Digital Signature Algorithm)
- Full implementation moved into FIPS module
- SHA-256 prehashing support for improved performance
- ACVP test vector support
- Stateless design eliminates state management complexity
X-Wing Hybrid KEM
- Combines classical X25519 with ML-KEM for defense in depth
- Available for HPKE (Hybrid Public Key Encryption)
- Protects against both classical and quantum attacks
🦀 Rust Integration

First-Class Rust Support
```
// Now available in bssl-crypto crate
use bssl_crypto::{aead, aes, cipher};
```
- bssl-crypto crate: Official Rust bindings for BoringSSL
- Full workspace configuration: Cargo.toml, deny.toml
- CI/CQ integration: Automated testing on Linux, macOS, Windows
- Native implementations: AES, AEAD, cipher modules in pure Rust
Platform Coverage
- ✅ Linux (32-bit and 64-bit)
- ✅ macOS (Intel and Apple Silicon)
- ✅ Windows (MSVC and MinGW)
- ✅ WebAssembly targets
⚡ Performance Optimizations

AES-GCM Enhancements
- AVX2 implementation: Up to 2x faster on modern Intel/AMD CPUs
- AVX-512 implementation: Up to 4x faster on Ice Lake and newer
- Improved constant-time operations for side-channel resistance
Entropy & Randomness
- Jitter entropy source: CPU timing jitter as additional entropy
- Raw jitter sample dumping utility for analysis
- Enhanced fork detection and reseeding
Assembly Optimizations
- Updated x86-64 assembly for better µop scheduling
- Improved ARM64 NEON implementations
- Better branch prediction hints
🛡️ Security Enhancements

RSA-PSS Improvements
- EVP_pkey_rsa_pss_sha384: SHA-384 based PSS
- EVP_pkey_rsa_pss_sha512: SHA-512 based PSS
- SHA-256-only mode for constrained environments
- Default salt length changed to RSA_PSS_SALTLEN_DIGEST
X.509 Certificate Handling
- X509_parse_with_algorithms: Parse with specific algorithm
  constraints
- X509_ALGOR_copy: Safe algorithm identifier copying
- Improved SPKI (Subject Public Key Info) parsing
- Better handling of unknown algorithms
Constant-Time Operations
- Extended to Kyber implementations
- All post-quantum algorithms use constant-time operations
- Side-channel resistant by default
🏗️ Architecture & API Improvements

C++17 Modernization
- Required: C++17 compiler (was C++14)
- [[fallthrough]] attributes instead of macros
- std::optional usage where appropriate
- Anonymous namespaces for better ODR compliance
Header Reorganization
- sha2.h: SHA-2 functions moved to dedicated header
- Improved IWYU (Include What You Use) compliance
- Better separation of public/internal APIs
FIPS Module Updates
- SLH-DSA moved into FIPS module
- AES-KW(P) and AES-CCM added to FIPS testing
- Updated CAVP test vectors
- Removed deprecated DES from FIPS tests
Build System Improvements
- Reorganized cipher implementations (cipher_extra/ → cipher/)
- Unified digest implementations
- Better CMake integration
- Reduced binary size despite new features
✅ Preserved Bun-Specific Patches

All custom modifications have been successfully preserved and tested:

Hash Algorithms
- ✅ EVP_blake2b512: BLAKE2b-512 support for 512-bit hashes
- ✅ SHA512-224: SHA-512/224 truncated variant
- ✅ RIPEMD160: Legacy compatibility (via libdecrepit)
Cipher Support
- ✅ AES-128-CFB: 128-bit AES in CFB mode
- ✅ AES-256-CFB: 256-bit AES in CFB mode
- ✅ Blowfish-CBC: Legacy Blowfish support
- ✅ RC2-40-CBC: 40-bit RC2 for legacy compatibility
- ✅ DES-EDE3-ECB: Triple DES in ECB mode
Additional Features
- ✅ Scrypt parameter validation: Input validation for scrypt KDF
- ✅ All patches compile and pass tests
🔄 Migration & Compatibility

Breaking Changes
- C++17 compiler required (update build toolchain if needed)
- ML-KEM private key parsing removed from public API
- Some inline macros replaced with modern C++ equivalents
API Additions (Non-Breaking)
```
// New post-quantum APIs
MLKEM768_generate_key()
MLKEM1024_encap()
MLDSA44_sign()
SLHDSA_sign_with_prehash()

// New certificate APIs
X509_parse_with_algorithms()
SSL_CTX_get_compliance_policy()

// New error handling
ERR_equals()
```
📈 Testing & Verification

Automated Testing
- ✅ All existing Bun crypto tests pass
- ✅ Custom hash algorithms verified
- ✅ Custom ciphers tested
- ✅ RIPEMD160 working via libdecrepit
- ✅ Debug build compiles successfully (1.2GB binary)
Test Coverage
```
// All custom patches verified working:
✓ SHA512-224: 06001bf08dfb17d2...
✓ BLAKE2b512: a71079d42853dea2...
✓ RIPEMD160: 5e52fee47e6b0705...
✓ AES-128-CFB cipher works
✓ AES-256-CFB cipher works
✓ Blowfish-CBC cipher works
```
🌟 Notable Improvements

Developer Experience
- Better error messages with ERR_equals()
- Improved documentation and API conventions
- Rust developers can now use BoringSSL natively
Performance Metrics
- AES-GCM: Up to 4x faster with AVX-512
- Certificate parsing: ~15% faster
- Reduced memory usage in FIPS module
- Smaller binary size despite new features
Future-Proofing
- Quantum-resistant algorithms ready for deployment
- Hybrid classical/quantum modes available
- NIST-approved implementations
- Extensible architecture for future algorithms
📝 Related PRs
- BoringSSL fork update: Update BoringSSL to latest upstream (Jan 2025) oven-sh/boringssl#2
- Upstream tracking: google/boringssl (latest main branch)
🔗 References
- NIST Post-Quantum
  Cryptography
- ML-KEM Standard (FIPS
  204)
- ML-DSA Standard
- SLH-DSA Specification
- BoringSSL
  Documentation
✨ Impact

This update positions Bun at the forefront of cryptographic security:
- Quantum-Ready: First-class support for post-quantum algorithms
- Performance Leader: Leverages latest CPU instructions for speed
- Developer Friendly: Rust bindings open new possibilities
- Future-Proof: Ready for the quantum computing era
- Standards Compliant: NIST FIPS approved implementations
🤖 Generated with Claude Code
Co-authored-by: Claude <noreply@anthropic.com>

Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.redirect.github.com>
bac132 fmt
0a3b9c Smarter auto closing crash issues
7d5f5a Fix strange build error
a3d3d4 Fix linear_fifo (#22590)

There was a bug with append append shift append append append shift shift

I couldn't remove it entirely because we add two new methods
'peekItemMut' and 'orderedRemoveItem' that are not in the stdlib
version.
d9551d fix: AbortController instance is empty with @types/node>=24.3.1 (#22588)
ee7608 feat: support overriding Host, Sec-WebSocket-Key, and Sec-WebSocket-Protocol headers in WebSocket client (#22545)

Summary

Adds support for overriding special WebSocket headers (Host,
Sec-WebSocket-Key, and Sec-WebSocket-Protocol) via the headers
option when creating a WebSocket connection.

Changes
- Modified WebSocketUpgradeClient.zig to check for and use
  user-provided special headers
- Added header value validation to prevent CRLF injection attacks
- Updated the NonUTF8Headers struct to automatically filter duplicate
  headers
- When a custom Sec-WebSocket-Protocol header is provided, it properly
  updates the subprotocols list for validation
Implementation Details

The implementation adds minimal code by:
1. Using the existing NonUTF8Headers struct's methods to find valid
  header overrides
2. Automatically filtering out WebSocket-specific headers in the format
  method to prevent duplication
3. Maintaining a single, clean code path in buildRequestBody()
Testing

Added comprehensive tests in websocket-custom-headers.test.ts that
verify:
- Custom Host header support
- Custom Sec-WebSocket-Key header support
- Custom Sec-WebSocket-Protocol header support
- Header override behavior when both protocols array and header are
  provided
- CRLF injection prevention
- Protection of system headers (Connection, Upgrade, etc.)
- Support for additional custom headers
All existing WebSocket tests continue to pass, ensuring backward
compatibility.

Security

The implementation includes validation to:
- Reject header values with control characters (preventing CRLF
  injection)
- Prevent users from overriding critical system headers like Connection
  and Upgrade
- Validate header values according to RFC 7230 specifications
Use Cases

This feature enables:
- Testing WebSocket servers with specific header requirements
- Connecting through proxies that require custom Host headers
- Implementing custom WebSocket subprotocol negotiation
- Debugging WebSocket connections with specific keys
Fixes #[issue_number]

Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.redirect.github.com>
e32931 Generate dependency versions header from CMake (#22561)

Summary

This PR introduces a CMake-generated header file containing all
dependency versions, eliminating the need for C++ code to depend on
Zig-exported version constants.

Changes
- New CMake script: cmake/tools/GenerateDependencyVersions.cmake
  that:
  - Reads versions from the existing generated_versions_list.zig file
- Extracts semantic versions from header files where available
  (libdeflate, zlib)
- Generates bun_dependency_versions.h with all dependency versions as
  compile-time constants
- Updated BunProcess.cpp:
  - Now includes the CMake-generated bun_dependency_versions.h
  - Uses BUN_VERSION_* constants instead of Bun__versions_*
  - Removes dependency on Zig-exported version constants
- Build system updates:
  - Added GenerateDependencyVersions to main CMakeLists.txt
  - Added build directory to include paths in BuildBun.cmake
Benefits

✅ Single source of truth for dependency versions
✅ Versions accessible from C++ without Zig exports
✅ Automatic regeneration during CMake configuration
✅ Semantic versions shown where available (e.g., zlib 1.2.8 instead of
commit hash)
✅ Debug output file for verification

Test Results

Verified that process.versions correctly shows all dependency
versions:
```
$ bun -e "console.log(JSON.stringify(process.versions, null, 2))"
{
  "node": "24.3.0",
  "bun": "1.2.22-debug",
  "boringssl": "29a2cd359458c9384694b75456026e4b57e3e567",
  "libarchive": "898dc8319355b7e985f68a9819f182aaed61b53a",
  "mimalloc": "4c283af60cdae205df5a872530c77e2a6a307d43",
  "webkit": "0ddf6f47af0a9782a354f61e06d7f83d097d9f84",
  "zlib": "1.2.8",
  "libdeflate": "1.24",
  // ... all versions present and correct
}
```
Generated Files
- build/debug/bun_dependency_versions.h - Header file with version
  constants
- build/debug/bun_dependency_versions_debug.txt - Human-readable
  version list
🤖 Generated with Claude Code

Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.redirect.github.com>
9479bb Enable async stack traces (#22517)

What does this PR do?

Enables async stack traces

How did you verify your code works?

Added tests

Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.redirect.github.com>
88a000 feat: Add Redis HGET command (#22579)

Summary

Implements the Redis HGET command which returns a single hash field
value directly, avoiding the need to destructure arrays when retrieving
individual fields.

Requested by user who pointed out that currently you have to use HMGET
which returns an array even for single values.

Changes
- Add native HGET implementation in js_valkey_functions.zig
- Export function in js_valkey.zig
- Add JavaScript binding in valkey.classes.ts
- Add TypeScript definitions in redis.d.ts
- Add comprehensive tests demonstrating the difference
Motivation

Currently, to get a single hash field value:
```
// Before - requires array destructuring
const [value] = await redis.hmget("key", ["field"]);
```
With this PR:
```
// After - direct value access
const value = await redis.hget("key", "field");
```
Test Results

All tests passing locally with Redis server:
- ✅ Returns single values (not arrays)
- ✅ Returns null for non-existent fields/keys
- ✅ Type definitions work correctly
- ✅ ~2x faster than HMGET for single field access
Notes

This follows the exact same pattern as existing hash commands like
HMGET, just simplified for the single-field case. The Redis HGET
command has been available since Redis 2.0.0.

🤖 Generated with Claude Code

Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
6e9d57 Auto assign @alii on anything with types (#22581)

Adds a GitHub workflow to assign me on anything with the types label
3b7d1f Add --cwd to test error messages for AI agents (#22560)

Summary
- Updates test error messages to include --cwd=<path> when AI agents
  are detected
- Helps AI agents (like Claude Code) understand the working directory
  context when encountering "not found" errors
- Normal user output remains unchanged
Changes

When Output.isAIAgent() returns true (e.g., when CLAUDECODE=1 or
AGENT=1), error messages in test_command.zig now include the current
working directory:

Before (AI agent mode):
```
Test filter "./nonexistent" had no matches
```
After (AI agent mode):
```
Test filter "./nonexistent" had no matches in --cwd="/workspace/bun"
```
Normal mode (unchanged):
```
Test filter "./nonexistent" had no matches
```
This applies to all "not found" error scenarios:
- When test filters don't match any files
- When no test files are found in the directory
- When scanning non-existent directories
- When filters don't match any test files
Test plan
- Verified error messages show actual directory paths (not literal
  strings)
- Tested with CLAUDECODE=1 environment variable
- Tested without AI agent flags to ensure normal output is unchanged
- Tested from various directories (/, /tmp, /home, etc.)
- Built successfully with bun bd
🤖 Generated with Claude Code

Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
1f5174 add _compile to Module prototype (#22565)

What does this PR do?

Unblocks jazzer.js

How did you verify your code works?

Added a test running `bun -p "module._compile ===
require('module').prototype._compile"
b3f5dd http(proxy): preserve TLS record ordering in proxy tunnel writes (#22417)

What does this PR do?

Fixes a TLS corruption bug in CONNECT proxy tunneling for HTTPS uploads.
When a large request body is sent over a tunneled TLS connection, the
client could interleave direct socket writes with previously buffered
encrypted bytes, causing TLS records to be emitted out-of-order. Some
proxies/upstreams detect this as a MAC mismatch and terminate with
SSLV3_ALERT_BAD_RECORD_MAC, which surfaced to users as ECONNRESET ("The
socket connection was closed unexpectedly").

This change makes ProxyTunnel.write preserve strict FIFO ordering of
encrypted bytes: if any bytes are already buffered, we enqueue new bytes
instead of calling socket.write directly. Flushing continues
exclusively via onWritable, which writes the buffered stream in order.
This eliminates interleaving and restores correctness for large proxied
HTTPS POST requests.

How did you verify your code works?
- Local reproduction using a minimal script that POSTs ~20MB over HTTPS
  via an HTTP proxy (CONNECT):
- Before: frequent ECONNRESET. With detailed SSL logs, upstream sent
  SSLV3_ALERT_BAD_RECORD_MAC.
  - After: requests complete successfully. Upstream responds as expected
- Verified small bodies and non-proxied HTTPS continue to work.
- Verified no linter issues and no unrelated code changes. The edit is
  isolated to src/http/ProxyTunnel.zig and only affects the write path
  to maintain TLS record ordering.
Rationale: TLS record boundaries must be preserved; mixing buffered data
with immediate writes risks fragmenting or reordering records under
backpressure. Enqueuing while buffered guarantees FIFO semantics and
avoids record corruption.

fixes:
#17434

#18490 (false fix in corresponding pr)

Co-authored-by: Ciro Spaciari <ciro.spaciari@gmail.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.redirect.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.redirect.github.com>
a37b85 Add debug-only network traffic logging via BUN_RECV and BUN_SEND env vars (#21890)

Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Meghan Denny <meghan@bun.sh>
09c56c Fix PostgreSQL StringBuilder assertion failure with empty error messages (#22558)

Summary
- Fixed a debug build assertion failure in PostgreSQL error handling
  when all error message fields are empty
- Added safety check before calling StringBuilder.allocatedSlice() to
  handle zero-length messages
- Added regression test to prevent future occurrences
The Problem

When PostgreSQL sends an error response with completely empty message
fields, the ErrorResponse.toJS function would:
1. Calculate b.cap but end up with b.len = 0 (no actual content)
2. Call b.allocatedSlice()[0..b.len] unconditionally
3. Trigger an assertion in StringBuilder.allocatedSlice() that
  requires cap > 0
This only affected debug builds since the assertion is compiled out in
release builds.

The Fix

Check if b.len > 0 before calling allocatedSlice(). If there's no
content, use an empty string instead.

Test Plan
- Added regression test that triggers the exact crash scenario
- Verified test crashes without the fix (debug build)
- Verified test passes with the fix
- Confirmed release builds were not affected
🤖 Generated with Claude Code

Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.redirect.github.com>
6e3349 Make the error slightly better

Michijs Dependabot changes

f820a7f

ghost closed this Sep 22, 2025

ghost deleted the michijs-dependabot branch September 22, 2025 01:08

This pull request was closed.

Conversation

ghost commented Sep 15, 2025

Updated Packages

Uh oh!

ghost commented Sep 15, 2025

Bump bun-types from 1.2.21 to 1.2.22

Read Bun v1.2.22's release notes on Bun's blog

Thanks to 14 contributors!

What does this PR do?

The Problem

Root Causes

The Fix

How did you verify your code works?

What does this PR do?

How did you verify your code works?

What does this PR do?

Compatibility

What does this PR do?

How did you verify your code works?

Summary

Problem

Solution

Test Coverage

Test Results

What does this PR do?

Summary

The Problem

Root Cause: What We Did Wrong

The Correct Solution: How Node.js Does It

Evidence from Node.js Source Code

Our Fix: Match Node.js Behavior Exactly

Why This Matters

Test Plan

1. test_reference_unref_in_finalizer.c (Regular Module)

2. test_reference_unref_in_finalizer_experimental.c (Experimental

Verification

Impact

🚀 BoringSSL Update - September 2025

📊 Update Summary

🔐 Post-Quantum Cryptography Support

ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism)

ML-DSA (Module-Lattice-Based Digital Signature Algorithm)

SLH-DSA (Stateless Hash-based Digital Signature Algorithm)

X-Wing Hybrid KEM

🦀 Rust Integration

First-Class Rust Support

Platform Coverage

⚡ Performance Optimizations

AES-GCM Enhancements

Entropy & Randomness

Assembly Optimizations

🛡️ Security Enhancements

RSA-PSS Improvements

X.509 Certificate Handling

Constant-Time Operations

🏗️ Architecture & API Improvements

C++17 Modernization

Header Reorganization

FIPS Module Updates

Build System Improvements

✅ Preserved Bun-Specific Patches

Hash Algorithms

Cipher Support

Additional Features

🔄 Migration & Compatibility

Breaking Changes

API Additions (Non-Breaking)

📈 Testing & Verification

Automated Testing

Test Coverage

🌟 Notable Improvements

Developer Experience

Performance Metrics

Future-Proofing

📝 Related PRs

🔗 References

✨ Impact

Summary

Changes

Implementation Details