Update README.md to reflect getKeyInfoContent changes #470

dozgunyal · 2024-05-06T21:33:00Z

Changes in #445 was not reflected in the documentation.
This PR attempts to fix it.

Summary by CodeRabbit

Documentation
- Updated documentation clarifying the default behavior for SignedXml configuration options related to key information and certificate handling.

Changes in node-saml#445 was not reflected in the documentation. This PR fixes it.

srd90 · 2024-05-06T23:09:16Z

README.md

- `getKeyInfoContent` - function - default `noop` - a function that returns the content of the KeyInfo node
- `getCertFromKeyInfo` - function - default `SignedXml.getCertFromKeyInfo` - a function that returns the certificate from the `<KeyInfo />` node
+- `getKeyInfoContent` - function - default `SignedXml.getKeyInfoContent` - a function that returns the content of the KeyInfo node
+- `getCertFromKeyInfo` - function - default `noop` - a function that returns the certificate from the `<KeyInfo />` node


It seems that production code still provides possibility to use unsecure implementation (SignedXml.getCertFromKeyInfo):
Quote from version 6.0.0:

xml-crypto/src/signed-xml.ts

Lines 217 to 223 in 0ed7ab2

static getCertFromKeyInfo(keyInfo?: Node | null): string | null {

if (keyInfo != null) {

const cert = xpath.select1(".//*[local-name(.)='X509Certificate']", keyInfo);

if (isDomNode.isNodeLike(cert)) {

return utils.derToPem(cert.textContent ?? "", "CERTIFICATE");

}

}

I.e. aforementioned implementation was not removed from production code meaning that anyone could use it as a value to getCertFromKeyInfo option.

Maybe README.md should state something like

DO NOT at any circumstances configure SigndXml.getCertFromKeyInfo as a value to getCertFromKeyInfo because that SHALL trigger this Critical vulnerability: CVE-2024-32962 aka GHSA-2xp3-57p7-qf4v

or same in markdown

DO NOT at any circumstances configure `SigndXml.getCertFromKeyInfo` as a value to `getCertFromKeyInfo` because that SHALL trigger this **Critical** vulnerability: CVE-2024-32962 aka [GHSA-2xp3-57p7-qf4v](https://github.com/node-saml/xml-crypto/security/advisories/GHSA-2xp3-57p7-qf4v)

@cjbarth quick grepping of xml-crypto codebase didn't reveal any usage for SignedXml.getCertFromKeyInfo other than test codes (which could have test code specific implementation of getCertFromKeyInfo) and

xml-crypto/src/signed-xml.ts

Line 57 in 0ed7ab2

getCertFromKeyInfo = SignedXml.getCertFromKeyInfo;

which might be possible to be replaced with SignedXml.noop

If I'm reading this correctly, and my greping is correct, nothing in the entire node-saml project depends on this. If it weren't for the fact that this is part of the spec, we could probably remove it entirely. However, since it is part of the spec, I feel like we have to leave this particular foot-gun in place. I'm open to discussion on this.

I fail to see any mention at the spec that forces anyone to have dead code in their projects / production codebase.

Anyone is able to implement their own foot gun instead of blindly setting aforementioned static foot gun implementation to configuration option. In that case they have full visibility to (they coded/copy pasted it and reviewed that with peer developers) and responsibility of implications of foot gun implementation.

Alternatively someone could just set from node-saml's / xml-crypto's point of view dead code foot gun implementation for whatever reason to that configuration option and forget it and if not even peer reviewers bother to deep dive to internals of recognized/de-facto nodejs xml-crypto library to see and figure out all implications then that unlucky project might be in a world of trouble.

I'd be up for a breaking change that changes this to noop() and removes relavant test. If you need to get your cert from the KeyInfo, that is on you as a consumer. Does that seem reasonable? @ahacker1-securesaml, does that also seem reasonable to you?

I agree with srd90, we should remove the insecure implementation of: static getCertFromKeyInfo.
Using this function would allow the XML signature to be validated with any certificate/public key, even those that you don't trust.
This negates the entire chain of trust.

With regards to a breaking change: There's no way to use the SignedXml.getCertFromKeyInfo and still be secure. If they are using it, then they are insecure. So it's best to remove it, even if it incurs a breaking change.

Ok, I'm up for that. Let's just move this default implementation to noop and leave it for the consumer. If KeyInfo were signed or this was a trusted internal system (which still has issues, but...), then They can roll their own code, even pulling from a previous release and maintaining it themselves.

I am using my mobile device so unable to deep dive into code...BUT my concern was that while documentation regarding getCertFromKeyInfo is updated to reflect implementation (default value is now documented to noop) codebase still ships SignedXml.getCertFromKeyInfo static function (which can be used to break chain of trust if configured to signedxml).

If I read your ( @cjbarth ) comments correctly you are now (at the latest comment) talking about getKeyInfoContent configuration option (instead of getCertFromKeyInfo configuration option) and SignedXml.getKeyInfoContent static function (instead of SignedXml.getCertFromKeyInfo static function).

I am unable to deep dive into code so dunno if there is some issues regarding that. My point has been that SignedXml.getCertFromKeyInfo should be removed from codebase (at least from packaged/production codebase).

Yes, thank you @srd90 for your precision. I agree, what we're talking about is SignedXml.getCertFromKeyInfo.

cjbarth · 2025-07-21T16:22:12Z

@dozgunyal , would you be open to changing your PR to remove the SignedXml.getCertFromKeyInfo stuff and adjust the default property to point to our implementation of noop instead as per the discussion?

cjbarth · 2025-10-17T21:22:45Z

@dozgunyal , are you willing to make the adjustments?

coderabbitai · 2025-10-17T21:22:57Z

Walkthrough

Documentation update swapping default values for two SignedXml options: getKeyInfoContent now defaults to SignedXml.getKeyInfoContent instead of noop, while getCertFromKeyInfo now defaults to noop instead of the SignedXml method.

Changes

Cohort / File(s)	Change Summary
Documentation Updates `README.md`	Updated default value documentation for `getKeyInfoContent` (now `SignedXml.getKeyInfoContent`) and `getCertFromKeyInfo` (now noop), reversing previous defaults

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Poem

🐰 The defaults dance and swap about,
Two functions twirl without a doubt!
Now noop and SignedXml align,
Documentation reads so fine,
Hoppy changes, clean and bright! 🌟

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The pull request title "Update README.md to reflect getKeyInfoContent changes" is clearly related to the changeset. It accurately reflects the stated primary objective found in the PR description, which explicitly mentions updating "README.md to reflect the getKeyInfoContent changes" from PR #445. The title is specific about the file being modified (README.md) and the primary change being documented (getKeyInfoContent). While the changeset also includes updates to getCertFromKeyInfo documentation, the PR's stated focus and description center on getKeyInfoContent as the main change, making the title an accurate summary of the primary objective. The title is concise and avoids vague language.
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.

✨ Finishing touches

🧪 Generate unit tests (beta)

Create PR with unit tests
Post copyable unit tests in a comment

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

coderabbitai

Actionable comments posted: 0

🧹 Nitpick comments (2)

README.md (2)
264-264: Clarify the meaning of "noop" default value.

The term "noop" is not immediately clear to all users. Based on the example at line 153 (getCertFromKeyInfo: () => null), "noop" appears to mean a function that returns null or does nothing. Consider clarifying this term or using more explicit language like "function that returns null" or "disabled by default".

Apply this diff to improve clarity:
-- `getCertFromKeyInfo` - function - default `noop` - a function that returns the certificate from the `<KeyInfo />` node
+- `getCertFromKeyInfo` - function - default `noop` (disabled; must provide your own implementation) - a function that returns the certificate from the `<KeyInfo />` node
264-264: Add explicit security warning about CVE-2024-32962.

The past review discussion (PR #445 context) identified a critical security vulnerability (CVE-2024-32962 / GHSA-2xp3-57p7-qf4v) when SignedXml.getCertFromKeyInfo is used. While the default is now correctly set to noop, users could still manually configure the vulnerable implementation. The documentation should include an explicit security warning to prevent misuse.

Consider adding a security note near the getCertFromKeyInfo option or in a dedicated security section. For example:
- `getCertFromKeyInfo` - function - default `noop` - a function that returns the certificate from the `<KeyInfo />` node
+- `getCertFromKeyInfo` - function - default `noop` - a function that returns the certificate from the `<KeyInfo />` node
+  **Security Warning:** Do **not** use `SignedXml.getCertFromKeyInfo` for this option, as it allows XML signatures to be validated with arbitrary certificates, bypassing the chain of trust. This would trigger CVE-2024-32962 / GHSA-2xp3-57p7-qf4v. Provide your own safe implementation if needed.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 8e692cf and 96222e0.

📒 Files selected for processing (1)

README.md (1 hunks)

dozgunyal · 2025-10-17T21:34:30Z

@dozgunyal , are you willing to make the adjustments?

Hi, sorry, I will try to send it this weekend.

Update README.md to reflect getKeyInfoContent changes

fff3d2f

Changes in node-saml#445 was not reflected in the documentation. This PR fixes it.

srd90 reviewed May 6, 2024

View reviewed changes

Merge branch 'master' into dozgunyal-patch-1

96222e0

coderabbitai bot reviewed Oct 17, 2025

View reviewed changes

	static getCertFromKeyInfo(keyInfo?: Node \| null): string \| null {
	if (keyInfo != null) {
	const cert = xpath.select1(".//*[local-name(.)='X509Certificate']", keyInfo);
	if (isDomNode.isNodeLike(cert)) {
	return utils.derToPem(cert.textContent ?? "", "CERTIFICATE");
	}
	}

Update README.md to reflect getKeyInfoContent changes #470

Are you sure you want to change the base?

Update README.md to reflect getKeyInfoContent changes #470

Uh oh!

Conversation

dozgunyal commented May 6, 2024 • edited by coderabbitai bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary by CodeRabbit

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cjbarth commented Jul 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cjbarth commented Oct 17, 2025

Uh oh!

coderabbitai bot commented Oct 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Walkthrough

Changes

Estimated code review effort

Poem

Pre-merge checks and finishing touches

Uh oh!

coderabbitai bot left a comment

Choose a reason for hiding this comment

Uh oh!

dozgunyal commented Oct 17, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

dozgunyal commented May 6, 2024 •

edited by coderabbitai bot

Loading

cjbarth commented Jul 21, 2025 •

edited

Loading

coderabbitai bot commented Oct 17, 2025 •

edited

Loading