You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit da5b083
Browse filesBrowse the repository at this point in the historyBrowse files
* fix: resolve XML-Enc elements by DOM traversal instead of XPath
decryptKeyInfo located elements with XPath expressions that were built by
string concatenation and scoped by a leading "//". Both properties made the
lookups behave differently from how they read.
"//" is descendant-or-self over the whole document regardless of the context
node passed to select(), so lookups that appear scoped were document-wide:
- the wrapped key was taken from the first CipherValue anywhere in the
document rather than from the EncryptedKey being processed
- DigestMethod was resolved by an absolute path, so with several
EncryptedKey elements it could return a digest declared by one key while
the ciphertext came from another
- the absolute DigestMethod path also matched nothing for documents using
EncryptedData/KeyInfo/RetrievalMethod, where EncryptedKey sits outside
KeyInfo, silently defaulting oaepHash to sha1
Predicates were also assembled by concatenating the RetrievalMethod URI into
the expression text, so an Id containing a quote changed what the expression
meant instead of being compared as a value.
lib/dom-select.js walks the DOM explicitly. Document values are compared,
never concatenated into anything that gets parsed, and scope is a node
enforced by the walk itself. EncryptionMethod and CipherValue are now read
from one resolved EncryptedKey, so they always describe the same key.
Two input-validation changes come with this:
- a RetrievalMethod URI must be a same-document fragment reference.
substring(1) removed the first character whatever it was, so "/ek1" and
"Xek1" both resolved to Id "ek1".
- a duplicated Id is reported rather than resolved to its first match.
Duplicate Ids are invalid XML and resolving them makes the result depend
on document order.
xpath moves to devDependencies; the runtime no longer parses expressions.
Verified with a packed tarball installed via --omit=dev, where
require('xpath') throws MODULE_NOT_FOUND and both fixtures still decrypt.
65 passing (44 before). Each property is pinned by a test that also asserts
the previous XPath behaviour for contrast, and 11 mutations of the traversal
and the guards were each confirmed to fail a named test.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix: replace leftover xpath calls with dom.child; align OAEP test fixtures with
mgf1=sha1
* fix: okta sibling case
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
0 commit comments