Remove jasypt 1.9.3 dependency (v41 breaking change)

[amcclain]

TL;DR for a busy reviewer

• What: Removes the org.jasypt:jasypt:1.9.3 dependency (EOL since 2014, no successor release). Replaces its two internal uses in hoist-core with pure-JDK code, ships a new BCrypt-based password encoder for consuming apps, and moves the AppConfig pwd encryption key out of open-source code and into operator-controlled instance config.
• Breaking on two surfaces, both narrow:
  • Any app whose User (or AppUser) domain class imports org.jasypt.util.password.BasicPasswordEncryptor (the common pattern) will fail to compile until it switches to io.xh.hoist.security.HoistPasswordEncoder. Roughly 5 LoC per affected domain class.
  • Any app that writes pwd-typed AppConfig values must now supply an encryption key via instance config (appConfigCryptoKey — env var APP_<appCode>_APP_CONFIG_CRYPTO_KEY or YAML). Without it, pwd reads still work (legacy shim), but pwd writes fail closed with a clear error. Apps that don't use pwd configs are unaffected by this branch.
• No DB migration. Existing pwd values decrypt transparently via the one-release LegacyJasyptDecrypter shim. Existing user password hashes verify transparently via HoistPasswordEncoder.matches() — no forced password reset.
• Targets v41. Coordinated with v41 upgrade notes; not a backport.

Why this PR

The proximate trigger was a Toolbox bootstrap that exploded under JDK 21, with the failure surfacing inside jasypt's reflective Unicode-normalizer wrapper. End-to-end verification (see "Verification" below) found that the surface symptom was actually caused by a Gradle build-script bug in Toolbox that fed the daemon's java.home to a forked toolchain JVM — independent of jasypt. The Toolbox fix lands separately and removes the immediate symptom.

That doesn't change the case for this PR, which stands on its own merits:

1. Jasypt 1.9.3 is unmaintained. Last release was 2014. There is no 2.x. jasypt-spring-boot (a community shim) still pins the same 1.9.3 artifact. Carrying an unmaintained transitive api dep across every consuming Hoist app is a slow-burn risk; any future JDK move that breaks one of its many reflective code paths becomes our problem.
2. The pre-existing pwd AppConfig encryption was effectively obfuscation, not encryption. The fixed key lived in this open-source file's static block. Anyone with read access to the repo could decrypt every pwd value from a DB dump. The PR replaces that with operator-supplied keys.
3. MD5+8-byte-salt user-password hashing is below modern baseline. Jasypt's BasicPasswordEncryptor default. BCrypt's adaptive cost is the de-facto standard.
4. First test infrastructure in hoist-core. The PR adds src/test/groovy/ with Spock; that's a long-term win independent of the crypto rework.

What's in the change

New code (src/main/groovy/io/xh/hoist/security/)

• HoistPasswordEncoder — thin BCrypt wrapper (via spring-security-crypto). encode() writes BCrypt; matches() transparently accepts BCrypt or legacy jasypt-default hashes; isLegacyHash() lets apps opportunistically re-encode on successful login.
• crypto/AesTextCipher — AES-256-GCM with PBKDF2-derived key (SHA-256, 65,536 iterations), random salt + IV per encryption, output prefixed with the $hoist-aes1$ format marker. Authenticated encryption — tampering is detected on decrypt. Strength = key strength; the class doc is explicit that the cipher is as good as the key the caller supplies.
• crypto/LegacyJasyptDecrypter — read-only, pure-JDK reproduction of jasypt 1.9.3's BasicTextEncryptor (PBEWithMD5AndDES, 1000 iterations, 8-byte salt) and BasicPasswordEncryptor (MD5, 1000 iterations, 8-byte salt, jasypt's specific re-digest-without-resalt loop). Applies NFC normalization to match jasypt exactly. Class doc explicitly scopes this as a one-release migration shim with no security value of its own.
• crypto/ConfigValueDigester — deterministic SHA-256 of plaintext, used by the Admin Console's Config Diff workflow to compare pwd values across environments without exposing them. No salt by design (admin-only trust boundary; salt would have broken cross-environment diff).

Wiring (AppConfig)

• The hardcoded obfuscation key from prior releases is preserved verbatim in source under LEGACY_OBFUSCATION_KEY, but its sole consumer is now LegacyJasyptDecrypter — a read-only path. It never reaches AesTextCipher and never encrypts new content.
• The active cipher is constructed from InstanceConfigUtils.getInstanceConfig('appConfigCryptoKey'). If unset, the cipher is null and pwd writes fail closed (IllegalStateException naming the missing config); pwd reads of pre-v41 values still flow through the legacy shim unaffected.
• decryptPassword dispatches by $hoist-aes1$ format marker: present → active cipher (with the same fail-closed branch for the misconfiguration case where a $hoist-aes1$ row exists but no key is configured); absent → legacy shim. Re-saving a pwd config from the admin UI promotes the row to the new format under the app-supplied key.

Build (build.gradle)

• Removed: api org.jasypt:jasypt:1.9.3
• Added: api org.springframework.security:spring-security-crypto (crypto module only, version managed by the Spring Boot BOM)
• Added: testImplementation org.spockframework:spock-core:2.3-groovy-4.0 + tasks.named('test') { useJUnitPlatform() }

Tests (first src/test/groovy/ tree in the repo)

60 Spock specs across 5 files — ./gradlew test green. Pure-JDK only (no Grails context, no DB). Notable coverage:

• AES round-trip across unicode/large/empty inputs, fresh-output-per-call, format-marker dispatch, wrong-password failure, cross-instance compatibility.
• Legacy jasypt fixtures generated out-of-band on a standalone JVM with real jasypt 1.9.3 and pinned into the spec. Covers empty / single-char / 256-char / NFC / NFD / whitespace inputs and an explicit NFC↔NFD cross-check.
• BCrypt encode/match round-trip, transparent legacy verification, isLegacyHash detection, malformed-input handling.
• Three-way decrypt dispatch (active cipher / legacy shim / unconfigured-key failure) and the fail-closed write path, exercised end-to-end against a simulated AppConfig.
• Conventions and the jasypt-fixture regeneration recipe live in src/test/groovy/README.md.

Docs

• CHANGELOG.md — v41-SNAPSHOT breaking-change + technical entries, including the new required appConfigCryptoKey setup for apps that write pwd configs.
• docs/upgrade-notes/v41-upgrade-notes.md — step-by-step migration with before/after code for the User domain swap, optional migrate-on-login pattern, a full step for the appConfigCryptoKey setup with env-var / YAML wiring, fail-closed write semantics, the in-place re-save migration path, and a hard warning against rotating the key once pwd rows exist under it.
• CLAUDE.md — refresh AppConfig description and key-dependencies list.

Verification

End-to-end manual smoke test against this branch from Toolbox with runHoistInline=true on JDK 21 Temurin (a Toolbox-side build.gradle fix was needed to keep bootRun from feeding the daemon's java.home into the forked toolchain JVM — landing separately in xh/toolbox#856).

PR Test Plan item	Result
./gradlew test green (60/60 locally)	✅
./gradlew clean assemble green	✅
Wrapper app boots with appConfigCryptoKey set; admin UI reads existing legacy pwd config; save promotes the row to $hoist-aes1$ format under the app-supplied key	✅ — verified DB row before (HO+/H4S... legacy base64) and after ($hoist-aes1$rrYO...); round-tripped readback returns the new plaintext via the new digest
Wrapper app without appConfigCryptoKey configured: legacy pwd reads succeed; pwd writes raise IllegalStateException with actionable message; row unmodified	✅ — error: "Cannot save pwd-typed AppConfig 'llmApiKey': no encryption key configured. Set instance config 'appConfigCryptoKey'..." — and the DB row is unchanged
Local user with a legacy jasypt-format password hash authenticates successfully; new user records hash with BCrypt	✅ — seeded test-legacy@xh.io with the spec's playwright-test legacy fixture (3hrIc7ebBL/Nxnkk...); login returned success: true. Bootstrap-created test-admin@xh.io and test-user@xh.io show $2a$10$... BCrypt hashes in the DB

Safety / release readiness

• ✓ Hardcoded key flows only into LegacyJasyptDecrypter (read-only); no new content can be written under it.
• ✓ Active cipher is honest AES-256-GCM under an operator-supplied key.
• ✓ Legacy decrypter validated against real jasypt 1.9.3 output (fixtures pinned, recipe documented).
• ✓ Format-marker dispatch is unambiguous: the $hoist-aes1$ prefix uses $ which cannot appear in Base64, so no legacy ciphertext can collide with the new format.
• ✓ BCrypt detection uses length == 60 && startsWith('$2') — also disjoint from Base64-only legacy hashes.
• ✓ Real-app end-to-end smoke verified against Toolbox (this branch + Add Playwright E2E testing setup toolbox#856) covering the migration matrix (legacy read, key-configured write/promotion, unconfigured-key write rejection, legacy user auth, new BCrypt user auth).
• ⚠️ Apps that use jasypt for purposes other than BasicPasswordEncryptor in a User domain class are not specifically addressed in the upgrade notes — they would also get a compile failure on the version bump. No such usage is known among XH apps but worth a grep org.jasypt pass on each consumer at upgrade time.
• ⚠️ The hoist-react admin-UI form behavior for pwd re-save (does it always send value when the user clicks Save?) is not exercised by this PR. The expected migration path — open and save — was verified at the API level here; the UI flow should be smoke-tested before tagging the release.

🤖 Generated with Claude Code

[amcclain]

Downstream consumer PR (draft, blocked on this one shipping): xh/toolbox#856 — Add Playwright E2E testing setup. Demonstrates the User.groovy → HoistPasswordEncoder swap from the v41 upgrade notes against a real consuming app, and was the surfacing context for the original jasypt bug.