jsr VS butterfloat

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?

You can just use npm and ship node_modules on your website. It's probably "huge" so you probably want to clean out dev dependencies first (`npm prune --omit=dev` is one way to clean that) and you might find it useful to search for big binaries to filter out and redundant directories that you don't need (libraries that still include all of UMD and CommonJS and ESM builds even though you only need one), and there may still be libraries that don't directly load in the browser and you need to spot bundle with a tool like esbuild to a vendor directory.

Mostly the only other glue you need after that is an import map.

I find this flow useful (ship an optionally pruned node_modules, spot build specific vendor libraries, add import map), especially for lightweight development/testing, and so I did document it specifically from start to finish for one of my projects, it includes a vendor build one-liner:

https://worldmaker.net/butterfloat/#/getting-started?id=setu...

(The Example section after the Dev Environment one shows the import map at the top of the example HTML if you are looking for that. I forgot that's where it was when re-reading this.)

Vanilla JS is better these days than when React first arrived. ES Modules are natively supported in browsers now and give you much of a component system.

Though to be fair, rather than using Vanilla JS alone I did recently write my own React-looking but not React-like view engine: https://worldmaker.net/butterfloat/#/

I've been taking a similar, but somewhat different approach to upgrading some old Knockout projects to mostly Vanilla JS+RxJS.

Here's one example app: https://github.com/WorldMaker/compradprog/blob/main/main.tsx

One of the obvious differences is that I'm still using TSX, but it is very different from React, it just looks a lot like React at first glance.

Also, because I was doing it across at least a couple of projects, I started it from the beginning as its own small framework and have been trying to document it: https://github.com/WorldMaker/butterfloat/tree/main

It's still very much in early "prerelease" stages, but feedback is welcome.

Just because on most modern hardware file I/O has millisecond latency and feels synchronous doesn't mean it is synchronous. It might feel like overkill to use Observables instead of Promises and I/O event loops or even thread-blocking faux synchronous file system calls, but there is still an asynchronous world there where it can be nice to have the full power of Observables. To be fair, my love affair with Observables started in C# in "backend" applications, so that's always been the natural fit for me and frontend and UI work has been the "side hustle" of taking stuff that I love in the backend side of the house and putting it to even more use.

I'm calling my view engine Butterfloat, and I only just finished the first documentation pass, so be gentle, but feedback is very welcome: https://github.com/WorldMaker/butterfloat