Appease lints in remaining crates

[tamird]

• chore(xtask): appease lints
• chore(spiffe): replace tokio_stream with futures
• chore(spiffe-rustls): appease lints
• chore(spiffe-rustls-tokio): appease lints
• chore(spiffe-rustls-grpc-examples): appease lints
• chore(spiffe-fuzz): appease lints

Please see (and keep) individual commits.

---

This change is 

[tamird]

FYI so long as there are no conflicts there's no reason to merge main into this branch. Now if you merge without squashing, those empty merge commits will be in the history. :(

[maxlambrecht]

FYI so long as there are no conflicts there's no reason to merge main into this branch. Now if you merge without squashing, those empty merge commits will be in the history. :(

@tamird Thanks for the clarification, makes sense. I’ll use Rebase and merge so the commits are replayed on top of main and land as a linear history, without merge commits.

[tamird]

Anything else you'd like to see here?

[maxlambrecht]

Anything else you'd like to see here?

I haven't had the chance to do a full review yet. Maintaining this repo is best-effort alongside my day job and other commitments, so reviews sometimes take a bit of time.

I'll do a thorough pass when I can grab a proper block of time and leave consolidated feedback.

Appreciate your patience.

[maxlambrecht]

@tamird , sorry for the delayed review, and thanks for the cleanup here, this is overall solid. I appreciate the attention to linting and consistency across the workspace.

One change I’d like before merging:

• spiffe-rustls: please re-export AuthorizerConfigError (e.g., pub use error::AuthorizerConfigError;) and drop the #[expect(unnameable_types)]. Since this error is exposed via Error::source(), downstream users should be able to name and match it.

A couple of small clarifications would also help future maintainability:

• spiffe: the tokio-stream to futures switch changes the public impl Stream trait path. Could you add a short rationale in the PR description explaining the motivation?
• Makefile: for cargo deny --exclude spiffe-fuzz, could you add a brief comment explaining why this exclusion is needed (e.g., fuzzing dependencies have different license/advisory requirements)?

For future PRs, it would help reviewability to keep changes more scoped where possible (for example: lint-only, dependency changes, or behavior/API changes in separate PRs). It makes it easier to reason about impact and speeds up reviews.

Happy to re-review once these are addressed.

[tamird]

@tamird , sorry for the delayed review, and thanks for the cleanup here, this is overall solid. I appreciate the attention to linting and consistency across the workspace.

One change I’d like before merging:

• spiffe-rustls: please re-export AuthorizerConfigError (e.g., pub use error::AuthorizerConfigError;) and drop the #[expect(unnameable_types)]. Since this error is exposed via Error::source(), downstream users should be able to name and match it.

This seems like it could be done in another PR, right? Since this one doesn't change the visibility.

A couple of small clarifications would also help future maintainability:

• spiffe: the tokio-stream to futures switch changes the public impl Stream trait path. Could you add a short rationale in the PR description explaining the motivation?

My rationale is that futures is a lot more likely to be in folks' workspaces already, and that the contract for spiffe (as opposed to e.g. spiffe-rustls-tokio) was that it was not dependent on the tokio ecosystem. Now in practice that remains untrue; tokio is deeply ingrained in spiffe, but it's a step in that direction.

• Makefile: for cargo deny --exclude spiffe-fuzz, could you add a brief comment explaining why this exclusion is needed (e.g., fuzzing dependencies have different license/advisory requirements)?

I don't recall, it's been too long. That said, cargo deny did not run on that crate before this change, so this is just preserving existing behavior and adding coverage for spiffe-fuzz can easily be attempted in another PR.

For future PRs, it would help reviewability to keep changes more scoped where possible (for example: lint-only, dependency changes, or behavior/API changes in separate PRs). It makes it easier to reason about impact and speeds up reviews.

Ack. Because stacking PRs in Github isn't really a thing I tend to prefer to write a single PR with many commits. Github is not very good at reviewing these, but reviewable.io is. I've been using it for over a decade -- it's worth a look if you haven't tried it.

Happy to re-review once these are addressed.

I think there aren't any code changes required? I can edit the PR description with what I wrote above (or you can) but jI want to gently remind you to please not squash this on merge.