Jsr Alternatives

jsr reviews and mentions

• The new open source JavaScript s package registry
  1 project | dev.to | 29 Apr 2024

  JSR Web Page

• Creating an OG image using React and Netlify Edge Functions
  7 projects | dev.to | 16 Apr 2024

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

• Poolifier Web Worker version 0.3.15
  3 projects | news.ycombinator.com | 4 Apr 2024
• Show HN: Drop SSH private keys in exchange for keygen via PRNG and Ed25519
  1 project | news.ycombinator.com | 12 Mar 2024

  (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?

• JSR: The JavaScript Registry
  9 projects | news.ycombinator.com | 1 Mar 2024
• A note from our sponsor - SaaSHub
  www.saashub.com | 2 May 2024

  SaaSHub helps you find the best software and product alternatives Learn more →