Skip to content

Enable hashes "alloc" feature #833

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

tcharding
Copy link
Member

@tcharding tcharding commented Aug 15, 2025

The feature enabling is borked at the moment. "alloc" should enabled "alloc" if optional hashes dependency.

The bug is not showing up, my best guess is because in hashes v0.14 we probably had feature gating nested in macros called across crate boundary's and were either getting or not getting code that we thought we should or shouldn't - what ever the case may be.

In order to upgrade to hashes 0.16.0 we need to fix this.

The feature enabling is borked at the moment. "alloc" should enabled
"alloc" ifn optional `hashes` dependency.

The bug is not showing up, my best guess is because in `hashes v0.14`
we probably had feature gating nested in macros called across crate
boundary's and were either getting or not getting code that we thought
we should or shouldn't - what ever the case may be.

<insert rand about macros here>

In order to upgrade to `hashes 0.16.0` we need to fix this.
@stevenroose
Copy link
Contributor

Why is this required? I can perfectly build with --no-default-features --features hashes without this change.

This crate doesn't export any of the hashes types, only uses it to calculate a fingerprint for secrets*, so the alloc feature being enabled or disabled on the hashes dep makes no difference.

*: I just learned about this feature from looking at #832, it seems that the hashes feature is used only to directly violate this crate's own internal rule ( 😅 ):

/// Secrets should not implement neither [`Debug`] and [`Display`] traits directly,
/// and instead provide `fn display_secret<'a>(&'a self) -> DisplaySecret<'a>`
/// function to be used in different display contexts (see "examples" below).

@apoelstra
Copy link
Member

Heh, Steven beat me to the punch on this. We shouldn't need an allocator for any reason in this crate. (I'm kinda surprised we even have an alloc feature in hashes at all.)

@apoelstra
Copy link
Member

Looks like it's needed for one convenience function for Hkdf. Okay. I'd be kinda tempted to just drop that method TBH and then we wouldn't even need the feature.

@tcharding
Copy link
Member Author

Mad, thanks for the question. I did not notice that secp barely uses hashes at all. I just assumed the worse about macros etc. Closing, thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants