Crypt::Rijndael CBC decrypt rejects Chrome cookie payloads accepted by XS #1923

Summary

The DBI SQLite fetch path corrupts Chrome cookie ciphertext stored as SQLite TEXT, which later causes Crypt::Rijndael CBC decryption to fail its correct block-size check.

Exact root cause

In the fixture, encrypted_value is declared BLOB but some rows have SQLite storage class TEXT and contain arbitrary ciphertext bytes, including NUL and invalid UTF-8. In DBI.fetchrow_arrayref and fetchrow_hashref, ResultSet.getObject() returns a Java String; JDBC has already replaced invalid UTF-8 sequences with U+FFFD. The current default SQLite path then UTF-8 encodes that lossy String into a Perl byte string. The first fixture row is 67 raw bytes (v10 plus a 64-byte CBC payload), but the PerlOnJava DBI fetch returns 117 bytes. After HTTP-Cookies-Chrome removes v10, it passes 114 bytes to CBC decrypt, which correctly rejects the non-block-aligned input.

Use SQLite's raw column bytes when fetching text values, then preserve the configured Unicode behavior only for valid UTF-8. The ECB/CBC block-size check in Crypt::Rijndael is correct and should remain.

Evidence

• CPAN random run: 20261028-144340-47138
• Distribution: HTTP-Cookies-Chrome 4.001
• Failing tests: t/_get_rows.t, t/load.t, t/save.t; 8/10 subtests pass, 3/6 programs fail
• Both JVM and interpreter backends reproduce the corruption
• System Perl runs the unmodified upstream suite successfully (37 tests; t/pod_coverage.t is skipped because its optional prerequisite is absent)
• Merged implementation port: PR WIP: Add Crypt::Rijndael Java crypto backend #1154, which closed issue Port Crypt::Rijndael to PerlOnJava Java crypto backend #1105