[58_maintenance] [parquet] Allow more encryption algorithms (#9203)#10351
Conversation
# Which issue does this PR close? <!-- We generally require a GitHub issue to be filed for all bug fixes and enhancements and this helps us generate change logs for our releases. You can link an issue to this PR using the GitHub syntax. --> - Closes apache#9202. # Rationale for this change <!-- Why are you proposing this change? If this is already explained clearly in the issue then this section is not needed. Explaining clearly why changes are proposed helps reviewers understand your changes and offer better suggestions for fixes. --> - Iceberg [spec](https://iceberg.apache.org/gcm-stream-spec/#encryption-algorithm) supports AES key sizes of 128, 192 and 256 bits. Iceberg Rust depends on `arrow-rs` for Parquet I/O, I'd like to start supporting AES 256 with this PR. # What changes are included in this PR? <!-- There is no need to duplicate the description in the issue here but it is sometimes worth providing a summary of the individual changes in this PR. --> - `RingGcmBlockEncryptor` and `RingGcmBlockDecryptor` will pick AES-128 or AES-256 based on key size - Refactor `encryption_async.rs` and `encryption.rs` to test both AES-128 and AES-256 encrypted parquet files # Are these changes tested? <!-- We typically require tests for all PRs in order to: 1. Prevent the code from being accidentally broken by subsequent changes 2. Serve as another way to document the expected behavior of the code If tests are not included in your PR, please explain why (for example, are they covered by existing tests)? --> Yes, unit test and on AES-256 encrypted Parquet files defined in https://github.com/apache/parquet-testing/tree/master/data/aes256 # Are there any user-facing changes? <!-- If there are user-facing changes then we may require documentation to be updated before approving the PR. If there are any breaking changes to public APIs, please call them out. --> No (cherry picked from commit accb1cf)
|
Hm, what's the best way to tackle the MSRV issue? |
|
Testing a change that adds |
That made CI worse, I'll take a look in the AM. |
f5aa920 to
98f3911
Compare
|
#7290 somewhat fixed this in |
|
The failing MSRV check is not specific to this PR (which only touches Cause: no
Two fixes verified locally (
Questions for @alamb:
The C Data Interface (Java to Rust) failure appears unrelated (Java allocator leak). |
I think we should do this. |
…o-msrv --locked) (#10365) # Which issue does this PR close? <!-- No dedicated issue for the CI break; file one if a tracker is wanted. --> - Part of #10349 (58.4.0 release effort). - Unblocks #10351, whose CI surfaced this pre-existing failure. - Prior art: #7290 (Fix MSRV CI Check), same class of fix. # Rationale for this change The `Verify MSRV` job on `58_maintenance` is failing on every PR (surfaced by #10351, whose own changes are parquet-only and unrelated). Two independent, pre-existing problems, both from dependency drift: 1. **`cargo install cargo-msrv` fails to build.** Installed unlocked, cargo-msrv's transitive deps resolve to their newest versions; recent `aws-*` releases require rustc 1.94.1, newer than the CI container's rustc, so the install fails before `verify` runs. 2. **`cargo msrv verify` fails on `arrow-flight`.** We commit no `Cargo.lock`, so `verify` resolves fresh each run and picks the newest deps. `tonic 0.14.6` now requires rustc 1.88, above our 1.85 MSRV. # What changes are included in this PR? Both changes are in `.github/workflows/rust.yml` (MSRV job only): - Install cargo-msrv with `--locked`, so its transitive deps resolve to versions that build on the CI container's rustc instead of the newest published ones. - Add a `Downgrade workspace dependencies` step that pins the tonic crates to 0.14.5 (the latest release supporting rustc 1.85) before `cargo msrv verify`, following the approach in #7290. The tonic crates are downgraded in matched pairs (`tonic`/`tonic-prost`, then `tonic-build`/`tonic-prost-build`) so their inter-crate `^` requirements stay satisfiable. No source, `Cargo.toml`, or declared-MSRV changes. # Are these changes tested? Yes, verified locally against a 1.85.1 toolchain with `cargo-msrv` 0.19.3 (matching CI): - Without the pins: `cargo msrv verify` on `arrow-flight` reports `is_compatible: false` (`tonic 0.14.6` requires 1.88). - With the pins: the full CI `find` loop (`cargo msrv verify` over all 29 packages) passes. # Are there any user-facing changes? No. CI-only change; no public API, code, or declared-MSRV changes. --- **Note for reviewers:** `main` has the same latent failure -- I ran `cargo msrv verify` on `main`'s HEAD and it fails identically on `tonic 0.14.6`. Its CI is currently green only because of a cached registry index predating that release. The `--locked` fix is already on `main`; the tonic pin step is not. Suggest a follow-up applying the tonic pin step to `main` as well.
|
Merged up to hopefully get fix for |
alamb
left a comment
There was a problem hiding this comment.
Looks good -- thanks @mbutrovich and @hsiang-c and @Jefffrey (indirectly!)
I will now prepare a release candidate
This PR:
58_maintenanceline