←back to thread

27 points roggenbuck | 1 comments | | HN request time: 0.198s | source

I wanted a safer alternative to RegExp for TypeScript that uses a linear-time engine, so I built Regolith.

Why: Many CVEs happen because TypeScript libraries are vulnerable to Regular Expression Denial of Service attacks. I learned about this problem while doing undergraduate research and found that languages like Rust have built-in protection but languages like JavaScript, TypeScript, and Python do not. This library attempts to mitigate these vulnerabilities for TypeScript and JavaScript.

How: Regolith uses Rust's Regex library under the hood to prevent ReDoS attacks. The Rust Regex library implements a linear-time Regex engine that guarantees linear complexity for execution. A ReDoS attack occurs when a malicious input is provided that causes a normal Regex engine to check for a matching string in too many overlapping configurations. This causes the engine to take an extremely long time to compute the Regex, which could cause latency or downtime for a service. By designing the engine to take at most a linear amount of time, we can prevent these attacks at the library level and have software inherit these safety properties.

I'm really fascinated by making programming languages safer and I would love to hear any feedback on how to improve this project. I'll try to answer all questions posted in the comments.

Thanks! - Jake Roggenbuck

Show context
spankalee ◴[] No.45035123[source]
It's very, very weird to speak of TypeScript and JavaScript as two separate languages here.

There is no TypeScript RegExp, there is only the JavaScript RegExp as implemented in various VMs. There is no TypeScript VM, only JavaScript VMs. And there are no TypeScript CVEs unless it's against the TypeScript compiler, language server, etc.

replies(3): >>45035278 #>>45035730 #>>45036911 #
1. DemocracyFTW2 ◴[] No.45036911[source]
This bothered me too; I think it should be re-framed as a difference between different JS engines (NodeJS vs Deno) because that's what happening. TS is just a fancy way to write JavaScript after all and a lot of TS source code gets literally erased in order to obtain runnable JS. Deno has been able to execute pure JavaScript from day one while NodeJS can now also execute a subset of TS without a visible translation step, all of which makes framing NodeJS vs Deno as "JavaScript vs TypeScript" even weirder.