Ryan Malloy
2896f7e93e
Tests and docs only, no behaviour change. TLS was the last untested surface and it came back clean. Previous coverage stopped at the handshake; everything after it ran only over plain sockets. That gap mattered because SSLSocket.recv is not socket.recv: it returns at most one TLS record's worth of plaintext however much you ask for, can return fewer bytes than are available, and plaintext buffered inside the SSL object is invisible to the OS. The Phase 39 buffered reader asks for up to 64 KB per call and loops until satisfied — that loop had never been pressured the same way. tests/test_tls_traffic.py runs real SQLI through a TLS-terminating proxy: the framing-bug types end to end, payloads at 1/4096/16383/16384/ 16385/32000 bytes (straddling the ~16 KB record boundary), 500- and 5000-row bulk fetches, error recovery, concurrent TLS sessions, and three negative cases — TLS client against a plaintext port, plaintext client against a TLS port (must raise, not hang), and a verifying context rejecting a self-signed cert. All clean on all three servers. The buffered reader handles SSLSocket semantics correctly. Scope, stated plainly: the proxy supplies the TLS half, so this covers the driver's TLS path — the half we own. It does NOT cover IBM's server-side TLS listener. Setting one up on the developer-edition image was attempted and abandoned: Informix 15 wants a PKCS#12 keystore (onkstash takes a .p12, not the older CMS .kdb) and the engine kept rejecting the stash with GSK_ERROR_BAD_KEYFILE_PASSWORD even with a keystore GSKit itself could open. That half is IBM's code; everything below ssl.wrap_socket is identical either way. 414/414 integration on 15, 14.10 and 12.10 (was 399). Every surface is now fuzzed: type framing, fetch batching, error recovery, cursor lifecycle, threads, pooling, transactions, async cancellation, executemany partial failure, scrollable cursors, smart LOBs, and TLS.
Starlight Starter Kit: Basics
npm create astro@latest -- --template starlight
🧑🚀 Seasoned astronaut? Delete this file. Have fun!
🚀 Project Structure
Inside of your Astro + Starlight project, you'll see the following folders and files:
.
├── public/
├── src/
│ ├── assets/
│ ├── content/
│ │ └── docs/
│ └── content.config.ts
├── astro.config.mjs
├── package.json
└── tsconfig.json
Starlight looks for .md or .mdx files in the src/content/docs/ directory. Each file is exposed as a route based on its file name.
Images can be added to src/assets/ and embedded in Markdown with a relative link.
Static assets, like favicons, can be placed in the public/ directory.
🧞 Commands
All commands are run from the root of the project, from a terminal:
| Command | Action |
|---|---|
npm install |
Installs dependencies |
npm run dev |
Starts local dev server at localhost:4321 |
npm run build |
Build your production site to ./dist/ |
npm run preview |
Preview your build locally, before deploying |
npm run astro ... |
Run CLI commands like astro add, astro check |
npm run astro -- --help |
Get help using the Astro CLI |
👀 Want to learn more?
Check out Starlight’s docs, read the Astro documentation, or jump into the Astro Discord server.