NPM Token Revocation: Migrate To Trusted Publishing Now!
Hey guys! 👋 Let's dive into an important update from NPM that might affect your workflows. NPM is making some significant security changes, and it's crucial to get up to speed to avoid any disruptions. The main takeaway? Classic tokens are being revoked, and you need to migrate to Trusted Publishing ASAP, like early November 2025.
What's Happening with NPM?
NPM is rolling out several security enhancements, and you might have already received an email about it. If not, here’s the gist of what’s going on:
- October 13: New granular tokens with a 90-day maximum lifetime (7-day default).
- October 13: New TOTP 2FA configurations disabled (existing TOTP still works).
- Early November: All classic tokens will be permanently revoked. 😱
This means if you're using classic tokens in any automation, CI/CD pipelines, or local development, you need to switch to granular access tokens before early November. Otherwise, your publishing processes will be disrupted. Nobody wants that, right?
Why the Change?
NPM is taking these steps because of recent supply chain attacks. Compromised long-lived tokens are a major vulnerability, and these changes are essential to protect the NPM ecosystem and your packages from malicious actors. It's all about keeping our community safe and sound! 🛡️
Why Migrate to Trusted Publishing?
The big kahuna here is that classic tokens, which are permanently valid, are going away. This means the standard test-and-release.yml
workflow for automatic deployment will stop working if you don't make the switch. So, migrating to Trusted Publishing is not just recommended; it's essential.
Luckily, ioBroker tools already support Trusted Publishing, making the transition smoother. Let's get into the actions you need to take.
Steps to Migrate to Trusted Publishing
Migrating might sound daunting, but it's totally manageable. Here’s a breakdown of what you need to do, step by step.
1. Set Up NPM Trust Relationship
This part is independent of your specific test-and-release
workflow variant. Here’s how to configure it in your NPM account:
- Log in to npmjs.com: Use an account with publish rights for your package.
- Navigate to your package page:
- Go to
https://www.npmjs.com/package/YOUR-PACKAGE-NAME
(replaceYOUR-PACKAGE-NAME
with your actual package name). - Click on the "Settings" tab.
- Go to
- Configure Trusted Publishing:
- Scroll down to the "Publishing access" section.
- Click on "Automate publishing with GitHub Actions" or "Add trusted publisher."
- Fill in the required information:
- Repository owner: Your GitHub username or organization (e.g.,
ioBroker
). - Repository name: Your adapter repository name (e.g.,
ioBroker.your-adapter
). - Workflow name:
test-and-release.yml
(or the name of your release workflow). - Environment: Leave blank.
- Repository owner: Your GitHub username or organization (e.g.,
- Save the configuration.
For more detailed information, you can check out:
2. Actions for Repositories Using Up-to-Date test-and-release
Workflow with iobroker/action-testing-deploy
If you're using the standard workflow, you'll need to tweak your test-and-release.yml
file.
- Open
test-and-release.yml
: Edit this file directly on GitHub or in your development environment. - Remove
npm-token
from the deploy section:- Locate the job named
'deploy'
. It should look something like this:
- Locate the job named
# Deploys the final package to NPM
deploy:
needs: [check-and-lint, adapter-tests]
# Trigger this step only when a commit on any branch is tagged with a version number
if: |
contains(github.event.head_commit.message, '[skip ci]') == false &&
github.event_name == 'push' &&
startsWith(github.ref, 'refs/tags/v')
runs-on: ubuntu-latest
# Write permissions are required to create Github releases
permissions:
contents: write
steps:
- uses: ioBroker/testing-action-deploy@v1
with:
node-version: '20.x'
# Uncomment the following line if your adapter cannot be installed using 'npm ci'
# install-command: 'npm install'
build: true
npm-token: ${{ secrets.NPM_TOKEN }}
github-token: ${{ secrets.GITHUB_TOKEN }}
* Find the line starting with `'npm-token:'`.
* Remove this line (or comment it out by adding a `'#'` as the first character).
* Locate the block starting with `'permissions:'`.
* Add a line `'id-token: write'`. Make sure the indentation is correct to avoid an invalid YAML file.
* If the `'permissions:'` block is missing, add it, including the `'contents: write'` line as shown above.
- Test the release and deploy workflow: Create a test release to check if everything works as expected. ✅
- (Optional) Remove the
NPM_TOKEN
secret: After confirming everything works, you can remove theNPM_TOKEN
secret from your GitHub repository settings. Less clutter, more peace of mind! 🧘
3. Actions for Repositories Using Private, Modified, or Outdated test-and-release.yml
Workflow
If you're not using the standard workflow, here are some recommendations:
- Evaluate using the standard workflow: It might be worth switching to the standard
test-and-release
workflow and following the steps outlined above. - If you must keep a modified/private workflow: Consider using the
ioBroker/testing-action-deploy@v1
action within your workflow. You can still follow the migration guide mentioned earlier. - If you really need a private deploy mechanism: Follow the steps in the NPM Trusted Publishing documentation. Here are some key points to keep in mind:
- Make sure you enter the correct workflow name when setting up Trusted Publishing.
- Use the latest NPM release for the deploy process. Use a dedicated
npm install -g npm@latest
command within your workflow. - Do not use a token or try to log in to NPM. Use
npm publish
without dedicated authorization.
PR Coming Soon for Standard Workflows!
Good news! 🎉 A tool is in the works to generate a PR that will add the required changes to the standard test-and-release
workflow. This means you might be able to sit tight for a few more days and receive a PR with the necessary updates to your test-and-release.yml
file.
Note: You won't receive a PR if you're not using the default/standard workflow. The PR is expected to land within the next week, so keep an eye out!
Need Help?
If you've got questions or hit a snag, don't hesitate to reach out! The best places to get help are:
- Development channels on Telegram
- GitHub (invites available at https://www.iobroker.dev)
Feel free to drop a comment and mention @mcm1957
.
Huge thanks to everyone maintaining these adapters! Your hard work is super appreciated by all users. Let's work together to make the user experience even better! 🤝
Your ioBroker Check and Service Bot
Deutsche Beschreibung (German Description)
Hallo zusammen! 👋 Es gibt wichtige Neuigkeiten von NPM, die eure Workflows betreffen könnten. NPM nimmt einige wesentliche Sicherheitsänderungen vor, und es ist wichtig, auf dem Laufenden zu bleiben, um Störungen zu vermeiden. Die wichtigste Erkenntnis? Klassische Token werden widerrufen, und ihr müsst so schnell wie möglich zu Trusted Publishing migrieren, am besten bis Anfang November 2025.
Was passiert bei NPM?
NPM führt mehrere Sicherheitsverbesserungen ein, und ihr habt möglicherweise bereits eine E-Mail dazu erhalten. Wenn nicht, hier die Zusammenfassung:
- 13. Oktober: Neue granulare Token mit einer maximalen Lebensdauer von 90 Tagen (Standard 7 Tage).
- 13. Oktober: Neue TOTP 2FA-Konfigurationen deaktiviert (bestehende TOTP funktionieren weiterhin).
- Anfang November: Alle klassischen Token werden dauerhaft widerrufen. 😱
Das bedeutet, wenn ihr klassische Token in Automatisierungen, CI/CD-Pipelines oder der lokalen Entwicklung verwendet, müsst ihr vor Anfang November auf granulare Zugriffstoken umsteigen. Andernfalls werden eure Veröffentlichungsprozesse unterbrochen. Das will doch niemand, oder?
Warum die Änderung?
NPM unternimmt diese Schritte aufgrund der jüngsten Angriffe auf die Lieferkette. Kompromittierte, langlebige Token sind eine große Schwachstelle, und diese Änderungen sind unerlässlich, um das NPM-Ökosystem und eure Pakete vor böswilligen Akteuren zu schützen. Es geht darum, unsere Community sicher zu halten! 🛡️
Warum zu Trusted Publishing migrieren?
Der wichtigste Punkt ist, dass klassische Token, die dauerhaft gültig sind, verschwinden werden. Das bedeutet, dass der Standard-Workflow test-and-release.yml
für die automatische Bereitstellung nicht mehr funktioniert, wenn ihr nicht umsteigt. Die Migration zu Trusted Publishing ist also nicht nur empfehlenswert, sondern unerlässlich.
Glücklicherweise werden Trusted Publishing bereits von ioBroker-Tools unterstützt, was den Übergang erleichtert. Schauen wir uns die Aktionen an, die ihr durchführen müsst.
Schritte zur Migration zu Trusted Publishing
Die Migration klingt vielleicht entmutigend, ist aber durchaus machbar. Hier ist eine Aufschlüsselung der Schritte, die ihr durchführen müsst.
1. NPM-Vertrauensbeziehung einrichten
Dieser Teil ist unabhängig von eurer spezifischen Workflow-Variante test-and-release
. So konfiguriert ihr sie in eurem NPM-Konto:
- Bei npmjs.com anmelden: Verwendet ein Konto mit Veröffentlichungsrechten für euer Paket.
- Zur Paketseite navigieren:
- Geht zu
https://www.npmjs.com/package/YOUR-PACKAGE-NAME
(ersetztYOUR-PACKAGE-NAME
durch euren tatsächlichen Paketnamen). - Klickt auf den Tab "Settings".
- Geht zu
- Trusted Publishing konfigurieren:
- Scrollt nach unten zum Abschnitt "Publishing access".
- Klickt auf "Automate publishing with GitHub Actions" oder "Add trusted publisher."
- Füllt die erforderlichen Informationen aus:
- Repository owner: Euer GitHub-Benutzername oder eure Organisation (z. B.
ioBroker
). - Repository name: Der Name eures Adapter-Repositorys (z. B.
ioBroker.your-adapter
). - Workflow name:
test-and-release.yml
(oder der Name eures Release-Workflows). - Environment: Leer lassen.
- Repository owner: Euer GitHub-Benutzername oder eure Organisation (z. B.
- Konfiguration speichern.
Weitere Informationen findet ihr unter:
2. Aktionen für Repositories, die einen aktuellen test-and-release
-Workflow mit iobroker/action-testing-deploy
verwenden
Wenn ihr den Standard-Workflow verwendet, müsst ihr eure Datei test-and-release.yml
anpassen.
test-and-release.yml
öffnen: Bearbeitet diese Datei direkt auf GitHub oder in eurer Entwicklungsumgebung.npm-token
aus dem Abschnitt deploy entfernen:- Sucht den Job namens
'deploy'
. Er sollte so aussehen:
- Sucht den Job namens
# Deploys the final package to NPM
deploy:
needs: [check-and-lint, adapter-tests]
# Trigger this step only when a commit on any branch is tagged with a version number
if: |
contains(github.event.head_commit.message, '[skip ci]') == false &&
github.event_name == 'push' &&
startsWith(github.ref, 'refs/tags/v')
runs-on: ubuntu-latest
# Write permissions are required to create Github releases
permissions:
contents: write
steps:
- uses: ioBroker/testing-action-deploy@v1
with:
node-version: '20.x'
# Uncomment the following line if your adapter cannot be installed using 'npm ci'
# install-command: 'npm install'
build: true
npm-token: ${{ secrets.NPM_TOKEN }}
github-token: ${{ secrets.GITHUB_TOKEN }}
* Findet die Zeile, die mit `'npm-token:'` beginnt.
* Entfernt diese Zeile (oder kommentiert sie aus, indem ihr ein `'#'` als erstes Zeichen hinzufügt).
* Sucht den Block, der mit `'permissions:'` beginnt.
* Fügt eine Zeile `'id-token: write'` hinzu. Achtet darauf, dass die Einrückung korrekt ist, um eine ungültige YAML-Datei zu vermeiden.
* Wenn der Block `'permissions:'` fehlt, fügt ihn einschließlich der Zeile `'contents: write'` wie oben gezeigt hinzu.
- Release- und Deploy-Workflow testen: Erstellt ein Test-Release, um zu überprüfen, ob alles wie erwartet funktioniert. ✅
- (Optional)
NPM_TOKEN
-Geheimnis entfernen: Nachdem ihr bestätigt habt, dass alles funktioniert, könnt ihr dasNPM_TOKEN
-Geheimnis aus euren GitHub-Repository-Einstellungen entfernen. Weniger Unordnung, mehr Ruhe! 🧘
3. Aktionen für Repositories, die einen privaten, modifizierten oder veralteten test-and-release.yml
-Workflow verwenden
Wenn ihr nicht den Standard-Workflow verwendet, sind hier einige Empfehlungen:
- Prüfen, ob der Standard-Workflow verwendet werden kann: Es könnte sich lohnen, auf den Standard-Workflow
test-and-release
umzusteigen und die oben beschriebenen Schritte auszuführen. - Wenn ihr einen modifizierten/privaten Workflow beibehalten müsst: Erwägt die Verwendung der Aktion
ioBroker/testing-action-deploy@v1
in eurem Workflow. Ihr könnt trotzdem der oben genannten Migrationsanleitung folgen. - Wenn ihr wirklich einen privaten Bereitstellungsmechanismus benötigt: Befolgt die Schritte in der NPM Trusted Publishing documentation. Hier sind einige wichtige Punkte, die ihr beachten solltet:
- Stellt sicher, dass ihr den korrekten Workflow-Namen bei der Einrichtung von Trusted Publishing eingebt.
- Verwendet die neueste NPM-Version für den Bereitstellungsprozess. Verwendet einen dedizierten Befehl
npm install -g npm@latest
in eurem Workflow. - Verwendet kein Token und versucht nicht, euch bei NPM anzumelden. Verwendet
npm publish
ohne dedizierte Autorisierung.
PR für Standard-Workflows kommt bald!
Gute Nachrichten! 🎉 Ein Tool ist in Arbeit, um einen PR zu generieren, der die erforderlichen Änderungen am Standard-Workflow test-and-release
vornimmt. Das bedeutet, dass ihr möglicherweise noch ein paar Tage warten und einen PR mit den notwendigen Aktualisierungen für eure Datei test-and-release.yml
erhalten könnt.
Hinweis: Ihr erhaltet keinen PR, wenn ihr nicht den Standard-Workflow verwendet. Der PR wird voraussichtlich innerhalb der nächsten Woche eintreffen, also haltet die Augen offen!
Benötigt ihr Hilfe?
Wenn ihr Fragen habt oder auf ein Problem stoßt, zögert nicht, euch zu melden! Die besten Anlaufstellen für Hilfe sind:
- Entwicklerkanäle auf Telegram
- GitHub (Einladungen unter https://www.iobroker.dev verfügbar)
Ihr könnt gerne einen Kommentar hinterlassen und @mcm1957
erwähnen.
Vielen Dank an alle, die diese Adapter pflegen! Eure harte Arbeit wird von allen Benutzern sehr geschätzt. Lasst uns zusammenarbeiten, um die Benutzererfahrung noch besser zu machen! 🤝
Euer ioBroker Check and Service Bot