Version bump 0.8.1 -> 0.8.2 across the app shell, the website and the README, plus v0.8.2 changelog entries for the native MySQL execution work merged in #42.
- desktop/package.json, desktop/src-tauri/Cargo.toml, desktop/src-tauri/tauri.conf.json, Cargo.lock (cargo-regenerated; gridline only - webview2-com-macros stays 0.8.1)
- www/public/landing.js + www/src/pages/index.astro const version; new top entry in www/src/data/changelog.ts
- version.test.ts, bundle-config.test.ts, docs-coverage.test.ts updated to 0.8.2
- README: both banners, both download tables (asset names + tags, incl. apt/dnf strings), MAINTENANCE comment, new v0.8.2 bullet
Verified: cargo build (gridline v0.8.2) + cargo test --lib 442 passed / 0 failed; bun run test 133 files / 1151 tests exit 0; tsc clean.
Fixes#41.
MySQL columns now decode by their declared type instead of a blind try_get chain,
so every non-string type (integers, DECIMAL, BIT, YEAR, DATE/TIME/DATETIME/TIMESTAMP)
renders its value instead of NULL. MySQL restore runs in-process over the sqlx driver
(no bundled MariaDB client, so MySQL 8 caching_sha2_password works) and the Clean toggle
is implemented. .sql files can be opened with Gridline from the OS file manager.
Verified: cargo test --lib 442 passed / 0 failed; bun run test 133 files / 1151 tests
exit 0; tsc clean; both live MySQL 8 integration tests pass with the bundled CLI hidden.
On macOS 26+ the Dock and any launcher that resolves app icons through
NSWorkspace.icon(forFile:) (Spotlight, Vicinae, Raycast, ...) drew a grey
rounded-square "legacy plate" behind Gridline's icon, i.e. a white border
around the app icon at every render size below ~72px.
Reproduced outside any launcher: NSWorkspace.icon(forFile:) on
Gridline.app returns the plated icon at 16-64px and the clean icon at
>=72px. The trigger lives in icon.icns, not in the app -- moving that file
into Zed.app reproduces the border, moving Zed's icns into Gridline.app
removes it.
Two things in the file cause it:
- ic12 (64x64) -> plates the 40-64px range
- is32/s8mk (16x16 RGB+mask)
il32/l8mk (32x32 RGB+mask) -> plates the 16-32px range
macOS treats padded small representations as legacy, and this icns carries
them in both places.
Fix, in two parts.
1. Strip those chunks. scripts/fix-icns.mjs does it; `tauri icon` re-emits
them on every run, so it has to be a committed, repeatable step.
scripts/verify-app-icon.mjs is the regression check: it builds a
throwaway .app around the committed icon.icns, asks AppKit to render it
at 16..512px and fails if any size comes back plated. It fails (6/11
plated) on the previous icns and passes on this one.
2. Regenerate the raster set from icon.svg via
scripts/regenerate-icons.sh, so the icons directory matches its source
of truth again. The SVG has been full-bleed since the initial commit
(md5 unchanged at d872e42/3dab09f/6854d88/HEAD) while the rasters were
replaced with a hand-tuned padded version at v0.2.0 and had drifted
from it ever since. The script generates into a temp dir because
`tauri icon` only takes one output directory and would otherwise drop
generated android/ and ios/ trees into the desktop-only icons dir.
No visual change on macOS: IconServices normalizes app-icon artwork when
rendering, so padded and full-bleed sets come out pixel-identical there
(same bbox and art fraction at 48/128/512px).
Windows and Linux do consume the PNG/ICO directly, so the icon there does
change from padded to full-bleed -- consistent with the SVG, but a
visible difference worth eyeballing before release.
Verified: verify-app-icon passes at 16, 24, 32, 40, 48, 64, 72, 96, 128,
256, 512px; iconutil and `file` still decode the new .icns and .ico
(6 sizes); frontend tests pass (131 files / 1134 tests).
* fix(keychain): repair stale macOS keychain ACLs before reads
macOS records the trusted application of a legacy keychain item as the
executable *path* for an ad-hoc (dev/linker-signed) build, and as a code
requirement + cdhash partition list for a signed bundle. When the path
changes — the monorepo move (`src-tauri/` -> `desktop/src-tauri/`), a
reinstalled app, running the installed app after a dev build — the ACL no
longer admits the running binary, so macOS demands the keychain password on
*every* access: once per secret, every time, with no "Always Allow".
The pin only ran after writes, and writing to an inaccessible item needs the
same authorization, so the ACL was never repaired.
- keychain_acl::is_item_trusted() answers "am I already in this item's ACL?"
with a metadata-only, prompt-free lookup (SecKeychainItemCopyAccess +
SecAccessCopyACLList + comparison against this process's own
SecTrustedApplication representation; a signed bundle's `cdhash:` partition
lists count as trusted and are left alone).
- ensure_item_acl() now no-ops when already trusted (no duplicate ACL entries,
no redundant authorization) and otherwise pins exactly as before.
- New before_read() hook, called from every keychain read path (DB password,
SSH password, SSH passphrase — commands and internal helpers), so a stale
item costs one authorization and is silent from then on.
- ItemSearchOptions reports "nothing matched" as errSecItemNotFound, which is
now handled as "no item" instead of a lookup error — previously every
connection without a stored password logged a spurious failure.
Verified: cargo test --lib (408 passed) plus the ignored live test
(`cargo test --lib -- --ignored keychain_acl`), which asserts a fresh item is
already trusted, repairs are idempotent and the secret still reads back. That
test now finishes in 0.25s instead of ~8s because the redundant
SecKeychainItemSetAccess is gone.
* chore(release): bump 0.8.1 and document GitHub-only releases
Version 0.8.0 -> 0.8.1 across every synced location: desktop/package.json,
desktop/src-tauri/Cargo.toml (+ Cargo.lock gridline entry), tauri.conf.json,
www/src/pages/index.astro, www/public/landing.js, both README download tables
(+ the MAINTENANCE note), and the version/docs-coverage/bundle-config tests.
Adds the 0.8.1 changelog entry (site + README Recent Changes).
AGENTS.md: releases are GitHub-only — tag `prod` and `git push github vN.M.N`
(origin/Gitea is a just-in-case mirror; never push branches, PRs or tags
there), and the keychain row documents the self-healing ACL repair.
Connecting to a managed provider (Neon in the report) failed with
"connection is insecure (try using `sslmode=require`)" because the TLS mode
never reached the backend:
- ConnectionFormData carried no ssl_* fields and both submit handlers
(NewConnectionScreen.buildPayload, EditConnectionModal save + test) omitted
them, so the SSH/SSL tab's mode was silently dropped before IPC.
- SslFields wrote ssl_ca_cert / ssl_client_cert / ssl_client_key — names the
Rust ConnectionInput ignores (it expects ssl_ca_path / ssl_cert_path /
ssl_key_path).
- parseConnectionString ignored query params, so a pasted Neon/Supabase URL's
?sslmode=require was discarded.
Pasting a URI now fills every setting it can (sslmode / ssl-mode, including
MySQL's REQUIRED and VERIFY_IDENTITY spellings) and offers a derived label
(database name, else host/file stem) as a placeholder that Test/Save uses when
the field is left blank. Managed presets pre-select their TLS mode (Supabase /
Neon → Require, PlanetScale → Verify Full).
Backend safety net: db::tls::resolve_ssl_mode defaults *.neon.tech /
*.supabase.co / *.psdb.cloud to `require` when a connection has no ssl_mode, so
connections saved before this fix keep working; an explicit mode (including
disable) always wins.
Tests: +15 frontend (parser, form payload, SSL field names, edit modal),
+4 Rust (resolve_ssl_mode / tls_decision_for).
adrianbonpin