chore: add tfhe dylint

[kc1212]

Description of changes

Integrate tfhe lints to our repo. At the moment I've disabled the serialize_without_versionize lint because we have many types that are serialized but not versioned, a vast majority of them are false positives, but we should investigate more in future work - https://github.com/zama-ai/kms-internal/issues/3032. Also I renamed XYZVersioned to XYZVersions to ensure invalid_versionize_dispatch passes. One final thing is I removed the linting pass for kind-testing, since we're already doing it in the normal CI pipeline.

Issue ticket number and link

Closes zama-ai/kms-internal#3027

PR Checklist

I attest that all checked items are satisfied. Any deviation is clearly justified above.

• Title follows conventional commits (e.g. chore: ...).
• Tests added for every new pub item and test coverage has not decreased.
• Public APIs and non-obvious logic documented; unfinished work marked as TODO(#issue).
• unwrap/expect/panic only in tests or for invariant bugs (documented if present).
• No dependency version changes OR (if changed) only minimal required fixes.
• No architectural protocol changes OR linked spec PR/issue provided.
• No breaking deployment config changes OR devops label + infra notified + infra-team reviewer assigned.
• No breaking gRPC / serialized data changes OR commit marked with ! and affected teams notified.
• No modifications to existing versionized structs OR backward compatibility tests updated.
• No critical business logic / crypto changes OR ≥2 reviewers assigned.
• No new sensitive data fields added OR Zeroize + ZeroizeOnDrop implemented.
• No new public storage data OR data is verifiable (signature / digest).
• No unsafe; if unavoidable: minimal, justified, documented, and test/fuzz covered.
• Strongly typed boundaries: typed inputs validated at the edge; no untyped values or errors cross modules.
• Self-review completed.

Dependency Update Questionnaire (only if deps changed or added)

Answer in the Cargo.toml next to the dependency (or here if updating):

1. Ownership changes or suspicious concentration?
2. Low popularity?
3. Unusual version jump?
4. Lacking documentation?
5. Missing CI?
6. No security / disclosure policy?
7. Significant size increase?

More details and explanations for the checklist and dependency updates can be found in CONTRIBUTING.md

[github-actions]

Consolidated Tests Results 2026-05-22 - 12:26:37

Test Results

7 passed

Details

7 tests
not captured
junit-to-ctrf
build-and-test test-reporter #2368
chore: add tfhe dylint #601

test-reporter: Run #2368

Tests 📝	Passed ✅	Failed ❌	Skipped ⏭️	Pending ⏳	Other ❓	Flaky 🍂	Duration ⏱️
7	7	0	0	0	0	0	not captured

🎉 All tests passed!

Tests

View All Tests

Test Name	Status	Flaky	Duration
k8s_test_crs_uniqueness	✅		38.7s
k8s_test_insecure_keygen_encrypt_and_public_decrypt	✅		1m 52s
k8s_test_insecure_keygen_encrypt_multiple_types	✅		2m 7s
k8s_test_keygen_and_crs	✅		1m 52s
k8s_test_keygen_uniqueness	✅		4m 39s
k8s_test_centralized_insecure	✅		59.0s
nightly_full_gen_tests_default_k8s_centralized_sequential_crs	✅		1.8s

_{🍂 No flaky tests in this run.}

Github Test Reporter by CTRF 💚

🔄 This comment has been updated

[dvdplm]

I am a little skeptical to introducing dylint on a broader scale. I am worried about the maintenance complexity and I think that the dylint we do have has not been very useful to us. We have ended up disabling it in a lot of places. I really like the idea of custom lints, but the actual implementation seems stuck on nightlies forever. Is it one of those things that seem great on paper but ends up being more of a burden in practice?

Setting my own bias aside for a second I think the code here is fine.

Questions:

1. I prefer explicit cargo commands in our CI configs over Makefile. This is just my bias but I think it is good to be consistent and explicit. Why is a make command better?
2. Does having two sources for dylints mean we have to compile two separate toolchains? Both locally and in CI?
3. There's a mention of a "warning-only" initial roll-out. Is that correct? I think warnings are just going to be ignored and that if we do this, we should go all-in.

[kc1212]

I am a little skeptical to introducing dylint on a broader scale. I am worried about the maintenance complexity and I think that the dylint we do have has not been very useful to us. We have ended up disabling it in a lot of places. I really like the idea of custom lints, but the actual implementation seems stuck on nightlies forever. Is it one of those things that seem great on paper but ends up being more of a burden in practice?

I think it has been useful and it's catching a few things with the tfhe-rs ones. It's also not a big maintenance burden at the moment as we're not maintaining our own lints, so tfhe-rs needs to make sure the lints are working with whatever toolchain they decide to use. While some are addressed in this PR, I made an issue here https://github.com/zama-ai/kms-internal/issues/3032 for the other stuff we need to look at.

Setting my own bias aside for a second I think the code here is fine.

Questions:

1. I prefer explicit `cargo` commands in our CI configs over Makefile. This is just my bias but I think it is good to be consistent and explicit. Why is a make command better?

For me, when the cargo command needs a lot of flags or environment variables, it's better to put it in a script or makefile I think. Then it can be reused without copying a long command in many places

2. Does having two sources for dylints mean we have to compile two separate toolchains? Both locally and in CI?

Yes, I think two toolchains are used.

3. There's a mention of a "warning-only" initial roll-out. Is that correct? I think warnings are just going to be ignored and that if we do this, we should go all-in.

Changed it to go all out. The commend might be wrong because I've seen more than one CI failures due to dylint.

[dvdplm]

I am still somewhat skeptical to this but the only way we can know if the hassle outweighs the benefit is trying it out. Code is fine, no objections there.

Let's try it!