fix(pass-style): fix #2700 ignore more safe async_hook extra properties #2701
Conversation
erights
force-pushed
the
markm-fix2700-ignore-safe-asynchook-extras
branch
from
10aac43 to
76012d0
Compare
| t.throws(() => passStyleOf(harden(p3)), { | ||
| message: 'Own @@toStringTag value must be a string: 3', | ||
| }); | ||
| t.is(passStyleOf(harden(p3)), 'promise'); |
There was a problem hiding this comment.
The change to this test case demonstrates the loosening of the @@toStringTag tests
| message: | ||
| 'Own @@toStringTag must not be enumerable: {"configurable":false,"enumerable":true,"value":"Promise p4","writable":false}', | ||
| }); | ||
| t.is(passStyleOf(harden(p4)), 'promise'); |
There was a problem hiding this comment.
The change to this test case demonstrates the loosening of the @@toStringTag tests
|
Because the observable change of #2700 that this PR allegedly fixes is only observed interactively when running the vscode debugger, this PR does not add a test case verifying the fix. Rather, I manually verified that this PR fixes #2700 by running the steps it documents. That run got well past the point where the previous problem was encountered, but then causes #2702 , which I suspect and hope is unrelated. |
|
I'm gonna have to look at this closer because the async hooks taming was supposed to handling these things |
There was a problem hiding this comment.
I believe the orignal checks are fine, it's just that they rely on @endo/init to have applied the node async_hooks patch that tames things.
See #2700 (comment)
erights
force-pushed
the
markm-fix2700-ignore-safe-asynchook-extras
branch
from
76012d0 to
08e4fc0
Compare
Closes: #2700
Refs: #2708
Description
#2700 explains how
passStyleOf's criteria for judging a promise to be passable happens to cause some failures when run under the vscode debugger. This both loosens the criteria to accept those properties that async_hooks might add to an individual promise instance, and tightens the criteria to enforce that these properties are symbol-named non-configurable non-writable own data properties with values that are obviously safe, such as primitives.Because
@@toStringTagwould normally satisfy this more general criteria, and doing so would guarantee it safe enough for all known purposes, this PR no longer makes a special case for it. By folding it into the more general check above, we no longer enforce that this property is non-enumerable, nor that the value of this property is a string.This is an alternate approach to #2708
Security Considerations
The tightened criteria above enhance safety. But the loosenings above endanger safety, and so must be carefully considered. This loosening allows properties with any symbol name, whether or not async_hooks would ever add them. Further, it loosens the restrictions on the
@@toStringTag-named property in ways that code might conceivably find confusing.Reviewers, please form your own judgement about whether such loosening actually matters. I will tighten back up whatever you request.
Scaling Considerations
none
Documentation Considerations
none for normal programmers.
For use of a debugger, this PR only removes an unpleasant surprise that would otherwise need to be explained.
Testing Considerations
none for non-debugger-based testing.
Compatibility Considerations
Both the tightenings and the loosenings are conceivably compat breaks, but are highly unlikely to matter in practice.
Upgrade Considerations
none.