Require the high-level sign traits instead of `SignFn` in bindings
What changed, and why it matters
This commit is a documentation-only change in the Rust Lightning library. It adds a comment explaining that a generic signing helper trait called SignFn is intentionally not exposed to language bindings (for users of other programming languages), because each specific signing method already has its own trait and the generic wrapper is awkward to map across languages. No code behavior changed, and there is no security fix or vulnerability here.
No action required. This is a non-security, developer-experience/documentation change.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The diff adds a rustdoc comment to the SignFn trait in lightning/src/offers/merkle.rs stating it is not exported to bindings users and that per-signed-type signing function traits should be used instead. The trait remains pub for Rust callers; only the bindings generator is told to skip it. There are no logic, API, or cryptographic changes.
Changed components
lightning/src/offers/merkle.rs documentationInspect captured patch +3 / −0
diff --git a/lightning/src/offers/merkle.rs b/lightning/src/offers/merkle.rs
index 4f27130..1a38fe5 100644
--- a/lightning/src/offers/merkle.rs
+++ b/lightning/src/offers/merkle.rs
@@ -94,6 +94,9 @@ pub enum SignError {
}
/// A function for signing a [`TaggedHash`].
+///
+/// This is not exported to bindings users as signing functions should just be used per-signed-type
+/// instead.
pub trait SignFn<T: AsRef<TaggedHash>> {
/// Signs a [`TaggedHash`] computed over the merkle root of `message`'s TLV stream.
fn sign(&self, message: &T) -> Result<Signature, ()>;
Why this scored 15/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.