Quality: Mitigate TextDecoder hardening failure in Node.js

[maptoan]

✨ Code Quality

Problem

Add a mitigation for TextDecoder instances in Node.js to prevent harden from failing when encountering the kLatin1FastPath symbol property. This involves ensuring that the property is not treated as a target for freezing or is handled via a proxy/accessor that allows the internal Node.js state to remain mutable.

Severity: high
File: packages/ses/src/lockdown-shim.js

Solution

Add a mitigation for TextDecoder instances in Node.js to prevent harden from failing when encountering the kLatin1FastPath symbol property. This involves ensuring that the property is not treated as a target for freezing or is handled via a proxy/accessor that allows the internal Node.js state to remain mutable.

Changes

• packages/ses/src/lockdown-shim.js (modified)

Most PRs should close a specific Issue. All PRs should at least reference one or more Issues. Edit and/or delete the following lines as appropriate (note: you don't need both refs and closes for the same one):

Closes: #XXXX
Refs: #XXXX

Description

Add a description of the changes that this PR introduces and the files that are the most critical to review.

Security Considerations

Does this change introduce new assumptions or dependencies that, if violated, could introduce security vulnerabilities? How does this PR change the boundaries between mutually-suspicious components? What new authorities are introduced by this change, perhaps by new API calls?

Scaling Considerations

Does this change require or encourage significant increase in consumption of CPU cycles, RAM, on-chain storage, message exchanges, or other scarce resources? If so, can that be prevented or mitigated?

Documentation Considerations

Give our docs folks some hints about what needs to be described to downstream users. Backwards compatibility: what happens to existing data or deployments when this code is shipped? Do we need to instruct users to do something to upgrade their saved data? If there is no upgrade path possible, how bad will that be for users?

Testing Considerations

Every PR should of course come with tests of its own functionality. What additional tests are still needed beyond those unit tests? How does this affect CI, other test automation, or the testnet?

Compatibility Considerations

Does this change break any prior usage patterns? Does this change allow usage patterns to evolve?

Upgrade Considerations

What aspects of this PR are relevant to upgrading live production systems, and how should they be addressed?

Include *BREAKING*: in the commit message with migration instructions for any breaking change.

Delete guidance from pull request description before merge (including this!)

---

🤖 About this PR

This pull request was generated by ContribAI, an AI agent
that helps improve open source projects. The change was:

1. Discovered by automated code analysis
2. Generated by AI with context-aware code generation
3. Self-reviewed by AI quality checks

If you have questions or feedback about this PR, please comment below.
We appreciate your time reviewing this contribution!

Closes #2813

[changeset-bot]

⚠️ No Changeset found

Latest commit: 104a237

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR