safe_eval.sh fix description of safe_set_var returns.
The description was out of sync wrt return values.
1. invalid var
2. invalid val
3. var not in allowed list
safe_eval.sh: add safe_set_var
Get the log message right!
Fix default allowed chars (untabify clobbered TAB)
Add a couple more : messages to help debugging.
safe_eval.sh: add safe_set_var
Get the log message right!
Fix default allowed chars (untabify clobbered TAB)
Add a couple more : messages to help debugging.
Keep zettarepl's encrypted record call working on targets
## Problem
Replication sources call `pool.dataset.insert_or_update_encrypted_record` over midclt on the target to store the target dataset's key. That private method was removed when encryption moved to `zfs.resource.encryption`, so replicating to a target on this version would fail after the stream was received and leave the encrypted dataset without a stored key, meaning it would not unlock on reboot.
## Solution
Restored the private method on `pool.dataset` with its original payload, forwarding to `zfs.resource.encryption.store_key`. Also trimmed encryption docstrings that repeated the API model field descriptions and corrected which supplied keys get stored on unlock.
Unlock zfs resources through typed models
## Problem
Internal callers (failover, boot import, KMIP) started a private dict-based unlock job with its own private models, and results were read with dict indexing. Changing a key from a pipe also rejected valid keys with a leading zero, and change_key accepted keys and passphrases that ZFS would later refuse.
## Solution
- **Unlock**: `zfs.resource.encryption.unlock` gains `start_attachments`, and internal callers start the public job with `ZFSResourceEncryptionUnlockArgsData` and read the returned entry by attribute. `unlock_impl` is now the non-job implementation that takes the model and unwraps secrets once; pool.dataset.unlock calls it directly since it already holds the same job lock.
- **Change key**: the key must be 64 hex characters and a passphrase 8 to 512 characters; a key read from the input pipe is matched as hex text instead of round-tripped through int.
- **Cleanup**: shared `secret_value`/`ancestor_chain` and `is_internal_dataset_name` live in one place each, store_key receives the lowercase ZFS key format while hook payloads are uppercase, and the sync_keys failure is logged with its traceback.
Move dataset encryption to zfs.resource.encryption
## Problem
Dataset encryption still lived in the `pool.dataset` namespace even though `zfs.resource` is now the dataset API, and zr's own create path had to call back into `pool.dataset.insert_or_update_encrypted_record` to record keys.
## Solution
- **New `zfs.resource.encryption` sub-service** owning lock, unlock, unlock_summary, export_key, export_keys, export_replication_keys, change_key and inherit, with zr conventions (`path`, lowercase enums, `Secret` keys, `ZFS_RESOURCE_*` roles, audit). Public methods delegate to private `*_impl` methods for thread local storage, as the rest of zr does, and everything is synchronous except starting attachment delegates, whose API is async.
- **Private methods moved and renamed** (store_key, delete_keys, stored_keys, sync_keys, encryption_roots, encryption_state, replication_keys, encryption_root_mapping, unlock_impl), together with the `storage_encrypteddataset` model. Every internal caller (failover, pool create/import/export, KMIP, replication, zfs events, zr create) now calls zr directly; no `pool.dataset` alias is left.
- **`pool.dataset` encryption methods are thin shims** keeping their models, roles and pipes. They call the zr `*_impl` methods through the namespace with their own job, so no nested jobs are created, and they share zr's job locks so both APIs serialize on the same dataset. Error messages are unchanged; validation attributes now follow zr names.
- `unlock_impl` has a private Secret-typed accepts model so passphrases handed over by failover stay redacted in job listings.
- Hook names and payloads, including the uppercase key formats failover relies on, are unchanged, and nothing renamed is called across HA controllers.
Tidy dataset encryption naming and readability
## Problem
The encryption move left `zfs_resource` wording on the `pool.dataset` side (shared job lock names, the `zr_args` helper, "compatibility wrapper" docstring lines, a `PoolDataset` message raised from zr), and a lot of the moved logic was dense comprehension and `filter`/lambda one-liners that were hard to read.
## Solution
- Job lock names live once in `plugins/zfs/encryption_job_locks.py` with neutral `dataset_encryption_*` names, used by both `pool.dataset` shims and `zfs.resource.encryption`, so both APIs still serialize on the same lock per dataset.
- Shims build zr arguments with the existing `validate_model` instead of a local helper, and their docstrings no longer describe the wrapping.
- zr raises "Dataset {path} does not exist", and the key table model is renamed `EncryptedDatasetModel` (table unchanged).
- Comprehensions, generator expressions, `filter`/`map` lambdas and inline ternaries in the encryption code are plain loops and `if` blocks, with behaviour unchanged.
Type check pool.dataset encryption shims
## Context
The pool.dataset encryption methods are new code in this branch but were declared without annotation checks, so their bodies worked on raw dicts while the zfs.resource.encryption methods they wrap are type-safe.
## Solution
All shims now use `check_annotations=True` with signatures matching their models and attribute access in the bodies. Secrets are handed to the zfs.resource models as `Secret` objects rather than dumped, and keys or passphrases left out by the caller are passed as None. The option and result sub-models are exported from the API package so the shims can annotate with them. Wire arguments, results and errors are unchanged.
py-llvmlite: updated to 0.50.0
0.50.0
Highlights of this release include:
Official support for Python 3.15 and 3.15t wheels.
Expanded win-arm64 Python support to 3.12–3.14.
All Linux wheels (x86_64 and aarch64) are now tagged to be compatible with GLIBC >= 2.27.
LLVM 22 AArch64 Oryon scheduling-model patch in llvmdev recipes.
include-what-you-use: updated to 0.26
0.26
Compatible with Clang 22.
Major changes:
[iwyu] Many improvements around the understanding of types, particularly templates
[iwyu] Improve handling of builtin type traits
[mappings] Add support for distinguishing function overloads and template specializations in mappings
[mappings] Add mapping generator for Windows.h
[mappings] Add mapping generator for portable C++ standard library symbols
[mappings] Improve libc, libc++ and POSIX mappings
ccls: updated to 0.20261004
0.20261004
Support the LSP 3.17 type hierarchy: textDocument/prepareTypeHierarchy, typeHierarchy/supertypes and typeHierarchy/subtypes. For a virtual method, supertypes/subtypes are the overridden/overriding methods. $ccls/inheritance is unchanged.
Find references and call hierarchy on a constructor now include calls through forwarding functions such as std::make_unique<A>(...) and std::vector<A>::emplace_back(...).
Hover on an auto variable in a function template shows the deduced type when the template has exactly one instantiation. Locals and parameters of template instantiations are no longer indexed as duplicate symbols. For a sugared deduced type, hover adds the desugared type (// aka ...), as clangd does.
Type hierarchy: a class that derives from a type alias now shows up under the aliased base.
-ivfsoverlay is honored again with LLVM 22+. Before this, it was silently dropped, and --warning-suppression-mappings= could crash.
Adapt to LLVM 22, 23 and 24.
[CIR] Implement ViewLikeOpInterface for multiple Ops
We implement ViewLikeOpInterface for dyn_cast, ptr_stride, get_member,
get_element, get_runtime_member, base_class_addr, derived_class_addr,
and memonic. Although there is no user for CIR internally as
decouplePointer returns the base and offset instead of the base
directly, it is still useful for external project to do aliasing
analysis for MemRef.
