Bump node-opcua from 2.175.3 to 2.180.0

[dependabot]

Bumps node-opcua from 2.175.3 to 2.180.0.

Release notes

Sourced from node-opcua's releases.

v2.180.0

node-opcua 2.180.0

Compare: v2.179.0...v2.180.0 · 3 commits · 2 pull requests

A small hardening release, published the day after 2.179.0. Two things: the binary decoder now refuses a message that declares an array longer than the bytes behind it, or nests recursive types without end; and a namespace default role permission configured through the public API is now actually enforced for remote sessions. The default behaviour of a server that configures neither is unchanged.

⚠️ Behaviour changes to review before upgrading

Namespace default role permissions now apply to remote sessions. A server that calls namespace.setDefaultRolePermissions(...), or loads a nodeset that declares DefaultRolePermissions, will see that default enforced where it was previously ignored unless setNamespaceMetaData() was also called. A per-node RolePermissions still overrides the namespace default, and a server with no default configured keeps its permissive resolution. [0261e8739]

Decode limits are on by default. A message that declares an array of more than 1 048 576 elements on a structured-type field, an array the remaining bytes cannot hold, or more than 128 levels of nested ExtensionObject, Variant or DiagnosticInfo, is now rejected at decode time. Legitimate traffic is far below both ceilings (Part 6 §5.1.8 and §5.1.9 ask for at least 100 nesting levels). Both are static fields on BinaryStream and can be raised. [c2e0dfe85]

---

🛡️ Hardening

The decoder bounds what a message can ask for (#1579)

The generic array decoder used by every structured-type array field looped over a wire-supplied UInt32 length with no ceiling, and the three recursive types could nest without bound. Variant already had an array cap of its own; the generic path, the dynamic extension-object decoder and the recursive types did not.

• BinaryStream.maxArrayLength (default 1 MiB elements) and checkArrayLength(): an array length above the ceiling, or one that the remaining bytes cannot back since every element is at least one byte, is refused before anything is allocated. Wired into the generic decodeArray and the dynamic extension-object decoder.
• A shared nesting budget, enterNestingLevel() / exitNestingLevel() on BinaryStream, used by DiagnosticInfo.decode, Variant.decode and decodeExtensionObject. BinaryStream.maxNestingLevel defaults to 128. The counter is released on refusal, so a rejected message does not leak budget for the next one.
• ServerCapabilities.MaxArrayLength advertises the effective ceiling, the minimum of the configured value, the Variant cap and the generic cap, and the constructor raises the codec ceiling to cover a configured value larger than the default (raise-only).
• Tests in node-opcua-binary-stream, node-opcua-basic-types and node-opcua-data-model: array-length bounds, the nesting counter including the no-leak-on-refusal case, and an end-to-end nested DiagnosticInfo round trip.

Namespace default role permissions reach the enforcement path (#1580)

When a node carries no RolePermissions of its own, Part 3 §5.2.9 resolves its access control from the namespace's DefaultRolePermissions. Two inconsistencies meant a default set through the public API never reached the permission check:

• Configuration and enforcement read different places. Namespace.setDefaultRolePermissions() stored the policy in a namespace field, and BaseNode.getRolePermissions(inherited) read it there, but SessionContext.getApplicableRolePermissions read the DefaultRolePermissions metadata node instead. The two were only connected when the operator also called setNamespaceMetaData(), which throws on a namespace loaded from a NodeSet2 file. The resolver now falls back to the namespace field when the metadata node is absent or Null, so both readers agree. Node-level and user-level precedence is preserved.
• Initialization discarded declared values. ServerEngine.initialize() reset every namespace's DefaultRolePermissions and DefaultUserRolePermissions property to Null, dropping any default a nodeset had declared. It now initializes only the unset properties to a readable Null and leaves a property that already carries a value alone.
• Tests: a namespace default reaches enforcement and a per-node RolePermissions still overrides it (confirmed to fail against the previous resolver); the same through a fully initialized ServerEngine; the existing permission suites stay green.

---

🚀 Features

• server: unresolvedPermissionPolicy is a documented OPCUAServer constructor option. It decides a remote session's permission when no RolePermissions apply at any level. The default stays "allow", so nothing changes for existing servers; "deny" lets a deployment drive access entirely from declared policy. It was previously reachable only by assigning to the server field directly. [74c8ea58a]

const server = new OPCUAServer({
    unresolvedPermissionPolicy: "deny"   // default: "allow"
});

---

Pull requests

... (truncated)

Commits

• 11ad1e0 v2.180.0
• 74c8ea5 feat(server): expose unresolvedPermissionPolicy as an OPCUAServer option
• 0261e87 fix(address-space): honour namespace default role permissions on the enforcem...
• c2e0dfe feat(codec): enforce a maximum array length and bound decode nesting
• c78c6ee v2.179.0
• 602e69a chore: update packages
• 2ac9951 fix(dynamic-extension-object): report unregistered dataTypes once, by name
• da436ed test(transport): wait for the socket pair to settle, not for a fixed delay
• 0f43a1a fix(address-space): stop asking massively-used types to drop absent references
• cc88e24 fix(dynamic-extension-object): pair each DataType with its own description
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot]

Superseded by #65.