Trust internal scikit-learn types needed for GB/HGB models

[cakedev0]

This PR description was mostly written by AI. I reviewed it before submission.

Reference Issues/PRs

This will make #498 very easy, like a 4 lines change. #498 is not a bug, but I'd say it's still a big friction for mlflow users and probably doesn't help them adopting skops.

What does this implement/fix? Explain your changes.

This PR adds support for persisting/loading the internal scikit-learn types needed by GradientBoosting and HistGradientBoosting models without surfacing them as untrusted types.

The implementation introduces a sklearn-specific internal-object path in skops/io/_sklearn.py for a small allowlist of trusted sklearn internals used by GB/HGB models.

CyHalfMultinomialLoss is serialized under the qualified module path sklearn._loss._loss.CyHalfMultinomialLoss rather than _loss.CyHalfMultinomialLoss so that trust is anchored under sklearn.. Maybe this is overkilled?

The PR also adds targeted regression tests in skops/io/tests/test_persist.py covering GradientBoosting / HistGradientBoosting variants and checking that CyHalfMultinomialLoss is serialized under the qualified sklearn module path.

AI usage disclosure:

• The code changes were developed with AI assistance in an interactive back-and-forth session.
• I asked the assistant to probe which trusted types were needed for GradientBoosting/HistGradientBoosting, explain the relevant serialization/trust code paths, review security tradeoffs, and iterate on the implementation based on my feedback.
• I reviewed the proposed changes, asked follow-up questions about the design and security properties, and requested specific adjustments such as using a qualified sklearn path for CyHalfMultinomialLoss and tightening/cleaning the sklearn-internal trust path.

[cakedev0]

I asked Codex to audit added scikit-learn classes, here is its report (TLDR: those are all simple, numeric-oriented classes, and are safe to trust).

Details

Per-class notes

Stateless numeric wrappers

These classes are thin mathematical wrappers with no meaningful mutable state and no custom deserialization hooks. In practice they only expose NumPy / SciPy computations, so trusting them does not add an obvious code-execution surface.

Classes	What they do	Safety review
sklearn._loss.link.IdentityLink, sklearn._loss.link.LogLink, sklearn._loss.link.LogitLink, sklearn._loss.link.HalfLogitLink, sklearn._loss.link.MultinomialLogit	Link functions used by the sklearn loss objects.	Safe: stateless numeric wrappers only; no eval / exec, no dynamic import, no custom __setstate__, no attacker-controlled callable invocation on load.

Small passive data containers

These objects mainly carry parameters or bounds. The main caveat is that skops restores them through __new__ plus attribute injection, so constructor-time validation is bypassed.

Classes	What they do	Safety review
sklearn._loss.link.Interval	Dataclass storing lower/upper bounds and inclusiveness flags for valid value ranges.	Safe from code execution: only scalar fields and range checks; malformed values could violate invariants, but there is no code-exec hook.

Python loss wrappers around trusted numeric backends

These classes wrap Cython loss kernels plus link objects and a few scalar flags. They do not define custom deserialization logic; in the skops path they are rebuilt by restoring plain attributes (closs, link, flags, intervals, sometimes quantile / n_classes).

Classes	What they do	Safety review
sklearn._loss.loss.HalfSquaredError, sklearn._loss.loss.AbsoluteError, sklearn._loss.loss.PinballLoss, sklearn._loss.loss.HuberLoss, sklearn._loss.loss.HalfPoissonLoss, sklearn._loss.loss.HalfGammaLoss, sklearn._loss.loss.HalfBinomialLoss, sklearn._loss.loss.HalfMultinomialLoss, sklearn._loss.loss.ExponentialLoss	Regression / classification loss objects used by GB / HGB and related estimators.	Safe: attribute-only restore pattern, no custom __setstate__, no dynamic execution logic; malformed trusted state could still cause wrong predictions or runtime errors because constructor validation is not re-run.

Cython backend object

Classes	What they do	Safety review
sklearn._loss._loss.CyHalfMultinomialLoss	Cython implementation of multiclass loss / gradient / probability kernels.	Safe in the skops path: effectively stateless here (__getstate__ is None), and skops bypasses Cython's pickle helper by reconstructing the instance via __new__, so there is no attacker-controlled function call during load.

HistGradientBoosting internals with explicit state restoration

These are the only reviewed classes with meaningful state-restoration behavior. I checked those methods directly.

Classes	What they do	Safety review
sklearn.ensemble._hist_gradient_boosting.binning._BinMapper	Stores HGB binning metadata and maps raw features to integer bins.	Safe: deserialization goes through BaseEstimator.__setstate__, which only pops _sklearn_version, warns on version mismatch, then updates __dict__; no dynamic execution.
sklearn.ensemble._hist_gradient_boosting.predictor.TreePredictor	Stores HGB tree arrays and runs fast prediction / partial dependence kernels.	Safe: custom __setstate__ only restores state and casts nodes to PREDICTOR_RECORD_DTYPE for cross-bitness compatibility; no import/eval/callback behavior.

[adrinjalali]

Questions:

• can these types not be persisted at all right now? Do they have to have a new node?
• can these not be simply added to trusted types in the trusted file?

[cakedev0]

can these types not be persisted at all right now?

They can, but with many untrusted types which is surprising for those very common scikit-learn models. And when trying to use skops with mlflow, it's really inconvenient because you have to pass the trusted types list at log_model time and not at load time. So basically, you have to do:
mlflow.sklearn.log_model(model, serialization_format="skops", skops_trusted_types=skops.io.get_untrusted_types(skops.io.dumps(model))).

Do they have to have a new node?

I don't think so. But maybe mapping _loss.CyHalfMultinomialLoss to sklearn._loss._loss.CyHalfMultinomialLoss is more convenient to do with a dedicated node (but this mapping is not necessary, just extra-caution I'd say).

Can these not be simply added to trusted types in the trusted file?

The trusted file is mostly global default trust for public-ish broad categories: primitives, containers, dtypes, ufuncs, and sklearn estimators discovered via all_estimators() so it felt off to add some version-sensitive private scikit-learn types here.

IIRC, Codex proposed this design, I challenged it and got convinced by this argument.

[cakedev0]

Note: before scikit-learn 1.4, GB/HGB use different internal things, so they still have untrusted types. For now, I decided to skip the tests, but I could probably add the necessary types instead. As you prefer.

[adrinjalali]

You can add extra trusted classes in specific loader nodes, but it doesn't really matter, they can be in the global trusted file. That's much better than adding a new loader / dumper states just for those classes.

[adrinjalali]

@copilot please apply my reviews in this PR.

[adrinjalali]

this is more of a test. Import shouldn't raise. Alternatively, we can filter out here anything which doesn't start with sklearn.

[adrinjalali]

we don't need to add a new node to support these objects. They can be simply trusted in _trusted.py, and added to a node's trusted types in the appropriate nodes.

[adrinjalali]

not sure if going through the zip file is a good idea, we should save / load and check if the loaded object is correct, with correct loaded attributes.

[adrinjalali]

Checking alternative implementation here: #513

[adrinjalali]

closed in a different PR