Give Your Dependencies a Rest

NPM version 11.10.0 (Feb 2026) can now consider the relative age of a package before installing it through the introduction of a new min-release-age config flag.

Limiting package installation based on age is known as dependency cooldown, specifically useful as a low-effort defense to address the rise in supply chain attacks.

You can add the following to your user home directory, or per-project .npmrc file:

min-release-age=7

or set it globally with:

npm config set min-release-age=7 --location=global

On MacOS, the exact global path location depends on how you installed Node.js

  • Homebrew: /opt/homebrew/etc/npmrc (Apple Silicon) or /usr/local/etc/npmrc (Intel)
  • Node Official Installer: /usr/local/etc/npmrc
  • NVM (Node Version Manager): $HOME/.nvm/versions/node/v[version number]/etc/npmrc

Once set, in this example, NPM won’t install any package version that was released less than 7 days ago. A 7-day safety margin should help cover weekends and holidays when security responses might be slower.

Note: This previously could be accomplished using the before flag, but min-release-age allows using a constant relative date integer. As such, the two flags are mutually exclusive.

Verifying a DKIM TXT Record and Key Length

After reading the Wired story last week about Zachary Harris discovering a widespread vulnerability related to the use of weak cryptographic DKIM keys (less than 1024 bits) by companies like Google, eBay, Yahoo, Twitter and PayPal, and the subsequent CERT warning (VU#268267), I decided to write a quick tool to check DKIM TXT records and determine their key length:

DKIM KEY Checker ➜ 

This tool grabs your DKIM DNS TXT record and uses OpenSSL to parse the contained public key to determine its key length.

DigitalOcean provides cloud products for every stage of your journey. Get started with $200 in free credit!

GitHub SSH Public Key Fingerprint Checking

A security vulnerability was discovered at GitHub back in 2012 that made it possible for an attacker to add new SSH keys to arbitrary GitHub user accounts. Although there was no known malicious activity using this exploit, they took the responsible step to email all their users that have SSH keys associated with their account to verify and approve them before they could be used to clone/pull/push repositories over SSH again.

Continue reading GitHub SSH Public Key Fingerprint Checking