DEV Community: OtterCyborg

I Got Hit by Sha1-Hulud: How I Rebuilt My Development Environment from the Ashes

OtterCyborg — Thu, 27 Nov 2025 06:40:18 +0000

I Got Hit by Sha1-Hulud: How I Rebuilt My Development Environment from the Ashes

Yesterday, my MacBook started running hot. Not the usual "Chrome has 47 tabs open" kind of hot—the "something is very wrong" kind of hot. I opened Activity Monitor and saw a process called trufflehog consuming 700% CPU.
That's when I knew: I was compromised.

The Attack

It started innocently enough. I installed Postman CLI to test some APIs—a completely normal thing developers do every day. What I didn't know was that one of the npm packages in my dependency chain had been poisoned. The malware created a tunnel, exfiltrated my SSH keys, and was actively scanning my machine for secrets.
I had become another victim of Sha1-Hulud.

The Aftermath

I had to revoke everything. Every SSH key. Every API token. Every secret. Then I nuked my Mac entirely and reinstalled the OS fresh.
All of this happened in a single day. Standing in front of a blank machine yesterday evening, I had a choice: set everything up the same way I always had, or fundamentally rethink my approach to development environment security.
I chose the latter. Here's the setup I built in just a few hours.

First Principle: No Node.js on the Host

Here's the uncomfortable truth: running npm install on your host machine is playing Russian roulette. Any package in your dependency tree—or any of their dependencies—could execute arbitrary code during installation via lifecycle scripts like preinstall and postinstall.
My first rule for the new setup: No Node.js. No npm. No Bun. Nothing JavaScript on my host environment.
This might sound extreme, but consider what you're actually trusting when you run npm install:

The package author
Every maintainer of every transitive dependency
npm's infrastructure
Every developer account that has publish access to any of those packages
The security of every one of their machines and credentials

⠀That's an impossibly large attack surface.

Second Principle: Declarative, Not Imperative

I also removed Homebrew. Before you close this tab in disgust, hear me out.
Homebrew is fantastic for quickly installing tools. But it creates a sprawling web of dependencies in /usr/local that's nearly impossible to audit. After months of use, you have no idea what's actually installed or why.
Instead, I switched to Nix with a declarative configuration. Everything I need is defined in a single file:

home.packages = with pkgs; [
    # Container
    container # Apple Container

    # Rust development
    rustc
    cargo
    rustfmt
    rust-analyzer
    clippy

    # Python development
    python312
    python312Packages.pip
    python312Packages.virtualenv

    # Common development tools
    git
    bat

    # Editor
    neovim
  ];

That's it. My entire host environment is defined in roughly 20 lines. If I need to nuke and rebuild my machine again, I can be back to a working environment in minutes, not hours.
Here's what my /usr/local/bin looks like now:

ls /usr/local/bin
determinate-nixd

One binary (because I installed nix using determinate installer). Compare that to the hundreds of executables Homebrew scatters across your system.
Nix gives me several security advantages:

Reproducibility: My environment is identical every time I build it
Isolation: Packages are stored in /nix/store with unique hashes based on their entire dependency tree
Auditability: I can see exactly what's installed by reading one file
Easy rollback: Made a mistake? Roll back to any previous generation

Third Principle: Protect Your SSH Keys

Here's something I didn't fully appreciate before the attack: any program on your machine can read your SSH keys. There's no permission prompt, no confirmation dialog. If malware lands on your system, your keys are immediately compromised.
I now use Secretive, an open-source macOS app that stores SSH keys in the Secure Enclave—the same hardware security module that protects Face ID data. The private key literally cannot be exported; it never exists in accessible memory.
Even better, it requires biometric authentication for every operation. Every git push, every ssh connection requires a Touch ID confirmation. It adds a bit of friction, but that friction is the point. If malware tries to use my keys, I'll know immediately—and I can deny it.
The Secure Enclave approach means even if an attacker gets root access to my machine, they still can't extract my SSH keys. The hardware won't allow it.

Fourth Principle: Contain the Danger

I still need to work with Node.js projects. The JavaScript ecosystem isn't going anywhere, and many of the tools I use daily are built on it. The solution: containerization.
Apple recently released their own containerization framework, and it's philosophically different from Docker. Instead of running all containers in a single shared Linux VM, Apple's approach spins up a dedicated lightweight VM for each container. This provides hypervisor-level isolation—each container is as isolated as a full virtual machine, but with sub-second startup times.
For my work, I use a hybrid setup:

Web applications run entirely inside containers (npm is trapped there forever)
For Tauri apps, the web portion is containerized and served over the network
The native shell runs on my host, connecting to the containerized web server

This setup means JavaScript code never runs on my host machine. Even if a malicious npm package executes, it's sandboxed inside a container with no access to my SSH keys, no access to my credentials, nothing.

The New Workflow

Here's what development looks like now:

Clone a repo: Git prompts for Touch ID to use my Secure Enclave-protected key
Start the dev environment: Apple Container spins up an isolated Linux VM in under a second
Install dependencies: npm install runs inside the container, isolated from everything
Push changes: Another Touch ID confirmation

Is it more friction? Yes, marginally. Is it more secure? Absolutely.

Lessons Learned

The Sha1-Hulud attack taught me something uncomfortable: the convenience-first approach to development tooling is a liability. We've built an ecosystem where running a single command can execute arbitrary code from thousands of strangers.
Some might argue this is paranoid. To them, I'd point out that supply chain attacks are increasing in sophistication and frequency. The npm ecosystem specifically has been hit repeatedly—Sha1-Hulud is just the latest and most severe example.
Here's my advice for anyone who wants to take security more seriously:

Assume npm packages can and will be compromised. Treat npm install as a potentially hostile operation.
Run JavaScript in containers. It's the only way to meaningfully limit the blast radius.
Protect your SSH keys with hardware. Secretive (or a YubiKey) makes key theft orders of magnitude harder.
Make your environment declarative and reproducible. You should be able to rebuild from scratch quickly, because someday you might have to.
Accept the friction. Security that's easily bypassed isn't security.

I spent a few hours setting all this up yesterday. The next person hit by a supply chain attack will spend days—or weeks—on incident response and recovery. The math works out.

Looking Forward

Eventually, I want to get even more aggressive. Running Python directly on my host still makes me nervous; pip packages have their own security issues. The ideal end state might be a completely containerized development environment where only Nix-managed tools run on the host.
But for now, this setup represents a reasonable balance. I can still be productive while significantly reducing my attack surface.
The sandworm got me once. It won't get me again.

If you were affected by Sha1-Hulud, the key remediation steps are: revoke and regenerate all npm tokens, GitHub PATs, SSH keys, and cloud credentials. Search for repositories named "Sha1-Hulud" created under your accounts. Review for unauthorized workflows or suspicious commits. And consider whether your development environment security model is actually working for you.

Neovim: My Setup for Developer Assistant with LLMs

OtterCyborg — Sun, 11 Aug 2024 12:28:26 +0000

I've been using VS Code for years, it's awesome. I thought I would never leave it until the end of my career. But everything changed since the day my colleague presented his awesome Neovim setup. It's pretty cool, but tough for me, a newbie in the Keyboard does everything space.

I spent my whole weekend setting up my own Neovim IDE. It's even worse since there are so many outdated configs that couldn't run on my potato machine. But that's another story, in this post, I'll just share something I couldn't miss in an IDE in this Age of AI: "Copilot".

Setup

There are many options out there. In this post, I will share my current setup with https://github.com/David-Kunz/gen.nvim.

gen.nvim

Generate text using LLMs with customizable prompts

Video

Requires

Ollama with an appropriate model, e.g. llama3.1, mistral, etc. (Simple setup)
Cortex for more advanced setup, e.g., switching models between different engines & providers such as Llama.cpp, OpenAI, and Claude.
Curl

Install

First thing first, let's install the plugin:

Example with Lazy

-- Minimal configuration

{ 
  "David-Kunz/gen.nvim",
  opts = {
    model = "mistral", -- The default model to use.
  }
}

Voila! You now have the code gen plugin installed. You can now run the Ollama Mistral model on your machine to see how it works.

Select a block of code that you want to ask, then do :Gen.

Generate text using LLMs with customizable prompts

The author also published a YouTube video that explains it better, please check it out.

Let's do a more advanced setup.

It's cool, right? But that's not my current productive setup. Sometimes my low-spec machine does not have enough VRAM to run bigger models, so I have to switch to remote endpoints.

Let's customize the plugin configuration to connect to other endpoints, such as OpenAI.

{ 
  "David-Kunz/gen.nvim",
  opts = {
    model = "gpt-4o", -- The default model to use.
    host = "api.openai.com",
    port = "443",
    command = function(options)
      local body = { model = options.model, stream = true }
      return "curl --silent --no-buffer -X POST https://"
        .. options.host
        .. ":"
        .. options.port
        .. "/v1/chat/completions -d $body"
        .. " -H 'Content-Type: application/json'"
        .. " -H 'Authorization: Bearer sk-xxxx'" -- OpenAI API Key
    end,
  }
}

Let's try chatting with the model again and see how it works. This prompt is just to ensure we are making requests to the OpenAI endpoint instead of Ollama.
Prompt:

Result:

All good.

Switching between configurations is tough though...

Sometimes I like to try out new models. They can be run locally or just remotely. How can I switch between those options without reconfiguring everything again and again?

This is the one you are looking for. https://github.com/janhq/cortex

I consider this a very good candidate for my use cases, since it supports multiple engines, both local and remote.

Now for the installation, I chose the npm option since I'm more familiar with the JS ecosystem. (It turned out that I can install this package inside my JS applications as well.)

npm install -g cortexso

Let's run the server! 🚀

cortex

The server is ready! Now pull any models from the Cortex Hugging Face Repository. There are so many models that have been republished, as well as remote providers that you will want to try out.

cortex pull llama3.1
cortex pull gpt-4o

You can also pull any of your favorite HuggingFace models. E.g. cortex pull google/gemma-7b-GGUF.

Voila, now I have two models pulled.

But, isn't OpenAI's models required to run with an API Key? Here is how to set it.

cortex engines openai set apiKey sk-your_api_key_here

You forgot something, huh? We need to run the models the same way Ollama does.

cortex run llama3.1

Only local models require this run step.

Time to update our gen.nvim configurations 🚀

{ 
  "David-Kunz/gen.nvim",
  opts = {
    model = "gpt-4o", -- The default model to use.
    host = "localhost", -- The cortex server host address.
    port = "1337", -- The cortex server port number.
    command = function(options)
      local body = { model = options.model, stream = true }
      return "curl --silent --no-buffer -X POST http://"
        .. options.host
        .. ":"
        .. options.port
        .. "/v1/chat/completions -d $body"
        .. " -H 'Content-Type: application/json'"
    end,
  }
}

Let's chat with our new friend ;)

Hold on, how to switch between models? 🤔

How do you switch between models from different engines that are installed?

gen.nvim supports a model selection function to switch between models. Let's map a key for it.

map("n", "<A-m>", function()
  require("gen").select_model()
end, { desc = "Select gen.nvim model" })

But it does not work yet, since it makes requests to Ollama by default. Now we customize it to fetch models from the Cortex server.

{ 
  "David-Kunz/gen.nvim",
  opts = {
    model = "llama3.1",
    host = "localhost",
    port = "1337",
    debug = false,
    command = function(options)
      local body = { model = options.model, stream = true }
      return "curl --silent --no-buffer -X POST http://"
        .. options.host
        .. ":"
        .. options.port
        .. "/v1/chat/completions -d $body"
        .. " -H 'Content-Type: application/json'"
    end,
    list_models = function(options)
      local response =
        vim.fn.systemlist("curl --silent --no-buffer http://" .. options.host .. ":" .. options.port .. "/v1/models")
      local list = vim.fn.json_decode(response)
      local models = {}
      for key, _ in pairs(list.data) do
        table.insert(models, list.data[key].name)
      end
      table.sort(models)
      return models
    end,
  }
}

Let's try Alt + m

🤘🤘🤘 Cool, right? Seamlessly switching between models, from local to remote models and between different providers.

Conclusion

This setup allows you to leverage both local and cloud-based AI models, enhancing your coding workflow with intelligent assistance.
As you become more comfortable with this setup, consider:

Creating custom prompts for your specific development needs
Exploring different models to find the best fit for various tasks
All of the linked projects are open-source, please don't forget to drop a star and help contribute. Please try different models, create custom prompts, and adapt the configuration to your unique workflow. Happy coding!