Mathieu Hofman
@mhofman.bsky.social
Building a platform for securely executing distributed JavaScript programs @Agoric
TC39 delegate. Tinkerer.
TC39 delegate. Tinkerer.
I also had an alternative design that would allow a framework / library to track when a promise it created (e.g. a network query) becomes the eventual result of a promise it receives (e.g. userland handler that triggers the network query). But that'd require a significant JS engine and spec change.
July 26, 2025 at 12:50 AM
I also had an alternative design that would allow a framework / library to track when a promise it created (e.g. a network query) becomes the eventual result of a promise it receives (e.g. userland handler that triggers the network query). But that'd require a significant JS engine and spec change.
The approach we're taking is to forego native promises and thenables altogether, and use another object that represents an eventual result. I need to write up our design somewhere (it leverages some of the concepts for eventual send).
July 26, 2025 at 12:46 AM
The approach we're taking is to forego native promises and thenables altogether, and use another object that represents an eventual result. I need to write up our design somewhere (it leverages some of the concepts for eventual send).
It's fragile in the face of some user code refactors too. Anything that introduces a tick before these trapping thenable are adopted into a promise prevents the detection.
Having faced similar problems of trying to track the flow of eventual results, I'm confident thenable tricks isn't a solution.
Having faced similar problems of trying to track the flow of eventual results, I'm confident thenable tricks isn't a solution.
July 26, 2025 at 12:43 AM
It's fragile in the face of some user code refactors too. Anything that introduces a tick before these trapping thenable are adopted into a promise prevents the detection.
Having faced similar problems of trying to track the flow of eventual results, I'm confident thenable tricks isn't a solution.
Having faced similar problems of trying to track the flow of eventual results, I'm confident thenable tricks isn't a solution.
I really didn't expect to see then getters (ab)used like that in the wild! I'm quite suspicious of how fragile this all actually is. This is effectively another form of Zalgo being released.
July 26, 2025 at 12:27 AM
I really didn't expect to see then getters (ab)used like that in the wild! I'm quite suspicious of how fragile this all actually is. This is effectively another form of Zalgo being released.
There is a long discussion on the topic at github.com/tc39/proposa.... Besides some of the performance concerns raised, my main concern is preventing the ability of some code to confuse other code it interacts with in the same realm. Adding an object to a collection should not have side effects.
Don't understand how the solution aligns to the problem · Issue #16 · tc39/proposal-composites
The problem statement is that Map and Set don't allow clients to override equality. It seems that the straightforward solution would be to have an option to pass a comparer function to those struct...
github.com
April 24, 2025 at 4:36 PM
There is a long discussion on the topic at github.com/tc39/proposa.... Besides some of the performance concerns raised, my main concern is preventing the ability of some code to confuse other code it interacts with in the same realm. Adding an object to a collection should not have side effects.
'user" is a bit confusing here. If the hashCode / equal is a protocol implemented by the object, then the author of the object can affect all collections in which the object is added 👎. If the functions are per collection, then you lose the standard synchronization point 👎
April 24, 2025 at 4:36 PM
'user" is a bit confusing here. If the hashCode / equal is a protocol implemented by the object, then the author of the object can affect all collections in which the object is added 👎. If the functions are per collection, then you lose the standard synchronization point 👎
An equality predicate is not sufficient for collections. Something like hashCode is also needed.
The problem with those is stability. There is no way to guarantee that user code will be side effect free and produce stable results.
The problem with those is stability. There is no way to guarantee that user code will be side effect free and produce stable results.
April 21, 2025 at 5:07 PM
An equality predicate is not sufficient for collections. Something like hashCode is also needed.
The problem with those is stability. There is no way to guarantee that user code will be side effect free and produce stable results.
The problem with those is stability. There is no way to guarantee that user code will be side effect free and produce stable results.
Hey there, any update on the recordings of the presentations? Would love to reference it.
March 27, 2025 at 12:39 AM
Hey there, any update on the recordings of the presentations? Would love to reference it.
Reposted by Mathieu Hofman
Don't what a realm is in JavaScript? Ask @mhofman.bsky.social ! He is talking all about them :)
February 21, 2025 at 4:42 AM
Don't what a realm is in JavaScript? Ask @mhofman.bsky.social ! He is talking all about them :)
And even though there was no actual vulnerability, we did pay out the researcher as it was a really informative report.
December 6, 2024 at 2:48 PM
And even though there was no actual vulnerability, we did pay out the researcher as it was a really informative report.
Reminds me of an "RCE" last year where a JWT library was "vulnerable" to an object with a `toString` method. How do you think that method got there in the first place...
unit42.paloaltonetworks.com/jsonwebtoken...
unit42.paloaltonetworks.com/jsonwebtoken...
Security Issue in JWT Secret Poisoning (Updated)
We discovered a new high-severity vulnerability (CVE-2022-23529) in the popular JsonWebToken open source project.
unit42.paloaltonetworks.com
December 6, 2024 at 2:23 PM
Reminds me of an "RCE" last year where a JWT library was "vulnerable" to an object with a `toString` method. How do you think that method got there in the first place...
unit42.paloaltonetworks.com/jsonwebtoken...
unit42.paloaltonetworks.com/jsonwebtoken...
Reposted by Mathieu Hofman
my view is that large mission-critical systems that are targeted by threat actors are in fact multi-tenant systems (whether their authors realize it or not) and immutability is one of the tools for writing defensive code against potential threats running in the same process
November 30, 2024 at 2:44 AM
my view is that large mission-critical systems that are targeted by threat actors are in fact multi-tenant systems (whether their authors realize it or not) and immutability is one of the tools for writing defensive code against potential threats running in the same process
Shoot, once again I'm away!
December 2, 2024 at 4:15 PM
Shoot, once again I'm away!
Yeah I'd say in general control flow based on API calls is a weakness in TS. Possible to implement yourself but very complex, and the standard library types don't do it.
December 2, 2024 at 4:02 PM
Yeah I'd say in general control flow based on API calls is a weakness in TS. Possible to implement yourself but very complex, and the standard library types don't do it.
Oh interesting. Wondering if this has something to do with integer index properties.
November 29, 2024 at 9:07 PM
Oh interesting. Wondering if this has something to do with integer index properties.
I was seeing similar scroll resetting weirdly on back navigation on Chrome on Android, but I haven't seen it today.
November 24, 2024 at 1:56 PM
I was seeing similar scroll resetting weirdly on back navigation on Chrome on Android, but I haven't seen it today.
Reposted by Mathieu Hofman
A flag which bans TS features with runtime emit (enums, namespaces, experimental decorators, etc) will come in 5.8 to help people executing TS code via Node.js (or who want to avoid using those features for "reasons").
November 23, 2024 at 6:21 AM
A flag which bans TS features with runtime emit (enums, namespaces, experimental decorators, etc) will come in 5.8 to help people executing TS code via Node.js (or who want to avoid using those features for "reasons").
Yeah it's been a known won't fix issue since 2020: github.com/microsoft/Ty...
November 23, 2024 at 9:47 AM
Yeah it's been a known won't fix issue since 2020: github.com/microsoft/Ty...
Unfortunately TS is already not a superset of JS. Its syntax is ambiguous enough that some valid JS programs have different semantics when handled by a TS parser. Also not all TS programs can simply have their types stripped off.
November 23, 2024 at 12:24 AM
Unfortunately TS is already not a superset of JS. Its syntax is ambiguous enough that some valid JS programs have different semantics when handled by a TS parser. Also not all TS programs can simply have their types stripped off.
GitHub can recognize and hide some generated files (e.g. from protobuf), not sure what the heuristics are. To enforce they are up to date, we just have a CI job that regenerates them and a check there are no dirty files (also good to handle lock files and similar)
November 19, 2024 at 9:58 AM
GitHub can recognize and hide some generated files (e.g. from protobuf), not sure what the heuristics are. To enforce they are up to date, we just have a CI job that regenerates them and a check there are no dirty files (also good to handle lock files and similar)