jsr VS bun

JSR Web Page

For example, here's an OG image for a workspace for jsr. JSR is the new JavaScript registry from the folks from Deno.

(tldr; visit https://jsr.io/@key/gen-ssh-ed25519 for details)

I have a hot take: the ~/.ssh folder should NOT contain private keys.

A private key is generated on the first day of computer setup and remains there permanently. It will have mode 600 if not misconfigured, and may also have a passphrase for protection (you do ... do you?). So, what's the catch?

During its entire lifespan, which can be months or even years, those private keys can be compromised in just a matter of seconds. This could happen if someone types "curl -d" in the command line on your behalf during a coffee break, or if an NPM package with numerous intermediate dependencies' postinstall scripts to send it elsewhere, even if guarded by a passphrase, ask yourself how confident you are that phrase you have will survive offline brute-force attacks?

ssh-agent to the rescue.

If you've enabled AddKeysToAgent and UseKeychain in your ~/.ssh/config file, you can safely remove your private key from the disk after it's automatically added to the ssh-agent (verify by ssh-add -L). This protects against all kinds of attacks, however, if you reboot your system, you'll need to set everything up again.

Thus the reproducible keygen comes into play, in a nutshell, instead of relying on entropy taken from /dev/random and letting the end user hold on to it safely forever (how?), let's use well-configured PRNG (i.e. PBKDF2 - SHA512 - 400,000 rounds in 2024 from native webcrypto in this case) with better algos (Ed25519 instead of RSA), to generate the same private key on demand on-the-fly, once the private key added onto ssh-agent, then just delete it from the disk, this greatly reduced the attack surface of the private key, no private key left means nothing to leak at the first place.

The last piece of the puzzle is coming up with a manageable salt/passphrase for PRNG, this can vary depending on your threat modeling, I will provide a few examples for inspiration, but you should choose what works best for you:

- UUID generated from system entropy, put into ~/.ssh/config as a vague comment yet you can retrieve it later on

- a strong password generated by password managers and safely stored across multiple devices

- any git commit hash that is unrelated whatsoever, this can come from one of your side projects or even some opensource project, as long as you don't lose the trace from your mental memory

- Merkle tree root hash from any given height of the blockchain

- specific version of any pkg (i.e. npm or crates) tarball's checksum

- your favorite number multiplied by the year of choice and cubed, i.e. (42 * 2024) ^ 3

- chunk of pi digits

etc...

The program is released on JSR (https://jsr.io/@key/gen-ssh-ed25519) and designed to be executed by Deno which is secure by default, it reads from command args and emits to stdout, without any file, network, or environment access.

Credit to Paul Miller by his NPM package (https://www.npmjs.com/package/ed25519-keygen) for the heavy lifting.

What is your opinion? Do you have any other suggestions or did you notice any oversights?

It has a decent compatibility with both Jest and Vitest's APIs (you can track progress here so you can use it as almost a drop-in replacement for either. Just as Node's, it has describe/it, mock, test and others, but with the expect syntax (which I find more readable). For example:

In this third and final article in the series on HTML Streaming, we will explore the practical implementation of the Diff DOM Streaming library in web browsing. This approach will allow any website using web components to retain its state during browsing. We will discuss in detail how to achieve this step by step using VanillaJS and Bun.

At Node Conference 2023, Jarred Sumner (creator of Bun) showed a demo of server components in Bun, so there is at least partial support in that ecosystem. The Bun repo provides bun-plugin-server-components as the official plugin for server components. And while I haven’t looked at it in-depth, Marz claims to be a “React Server Components Framework for Bun”.

Continuously evolving, Bun is currently optimized for MacOS and Linux, with ongoing efforts towards Windows compatibility. Tailored for resource-constrained environments like serverless functions, it emerges as an ideal solution. The Bun team is committed to achieving comprehensive Node.js compatibility and seamless integration with prevalent frameworks. For those intrigued by Bun's potential and want to give it a try, more information is available on its website at https://bun.sh/.

Let’s say you are interested in learning more about Bun and probably give it a try. Bun has a website, where you can learn more about Bun and its features (including all the benchmark data captured in this issue), and here is the link.

Looks like it, it seems the 2% are mostly odd platform specific issues that the authors' did not deem very important (my assumption for the release happening anyway). AFAIK this[1] PR tries to fix them.

[1]: https://github.com/oven-sh/bun/pull/9729

Bun has a solution for it. First of all, it already has a list of trusted dependencies. For them, Bun will execute all necessary scripts by default. Otherwise, you can add it to trustedDependecies in your package.json file. In Bun community usage of trustedDependencies is a hot topic. There are several suggestions on how to improve it.

Install Node.js (or Bun, or Deno, or whatever JS runtime you prefer) if it's not there

I think maybe I was unclear. I'm talking about writing libraries that abstract across these differences and provide a single API, as sibling describes. I already know it's possible. I made a simple filesystem abstraction here[0] and a very simple HTTP library that uses it here[1]. They both work in Node/Deno and the browser. Unfortunately I ran into issues with Bun's slice implementation[2]. But I suspect there's a much better way of detecting and using the different backends.

[0]: https://github.com/waygate-io/fs-js

[1]: https://github.com/waygate-io/http-js

[2]: https://github.com/oven-sh/bun/issues/7057