NPM Classic Token Revocation: Migrate To Trusted Publishing

Hey everyone,

Heads up! NPM is revoking classic tokens, and it's time to switch to Trusted Publishing. This is a critical security update, so let's dive into what's happening and what you need to do. If you're using classic tokens in your automation, CI/CD pipelines, or local development, you've got to migrate to granular access tokens before early November to avoid any publishing disruptions. Let's get started and make sure your workflow stays smooth!

What's Happening with NPM Tokens?

So, what's the deal? NPM is making some big changes to its security setup, and you might have already seen an email about it. The main takeaway is that classic tokens are being permanently revoked in early November. This is part of a larger effort to protect the NPM ecosystem from supply chain attacks and other vulnerabilities. These attacks often exploit compromised long-lived tokens, making this change crucial for maintaining the security of your packages and workflows. It’s all about keeping the community safe and sound, guys!

The changes are rolling out in phases. As of October 13th, NPM introduced new granular tokens with a 90-day maximum lifetime (with a 7-day default) and disabled new TOTP 2FA configurations (existing ones still work, though). The big one, though, is the revocation of all classic tokens in early November. This means that any automated deployments using the standard test-and-release.yml workflow will stop working if you're still relying on classic tokens. The good news? There's a solution: migrating to Trusted Publishing.

To put it simply, NPM is serious about security, and these changes are a necessary step. Think of it as upgrading the locks on your house – it might take a little effort upfront, but it's worth it for the peace of mind. The migration to Trusted Publishing might seem like a hassle, but it’s a forward-thinking move that aligns with best practices in the industry. Plus, ioBroker tools already support this migration, making the transition smoother for those in the ioBroker ecosystem. So, let’s buckle up and get this done!

Why Trusted Publishing is the Way to Go

Trusted Publishing is the recommended path forward, and it's good news that ioBroker tools already support it! But why is this migration so important? Without classic and permanently valid tokens, automatic deployment using the standard workflow will be disrupted. Trusted Publishing offers a more secure and streamlined approach, reducing the risk of token compromise. By switching, you're not just complying with NPM's new requirements; you're also enhancing the security posture of your projects. It's like upgrading from a regular key to a high-tech smart lock – much safer and more convenient in the long run.

The migration to Trusted Publishing is essentially about shifting from long-lived, static tokens to short-lived, dynamic credentials managed by GitHub Actions. This means that instead of storing a sensitive token in your repository's secrets, you'll be relying on GitHub's OpenID Connect (OIDC) integration with NPM. This method ensures that your publishing workflow is authenticated securely without exposing your credentials.

Think of it this way: imagine you’re sending a package. Instead of giving the delivery guy a permanent key to your house (a classic token), you give them a temporary code that works only for that specific delivery (Trusted Publishing). Once the package is delivered, the code expires, making your home much more secure. This approach significantly reduces the window of opportunity for malicious actors to exploit compromised credentials.

So, embracing Trusted Publishing is a proactive step towards a more secure and reliable publishing process. It might seem like a bit of a change, but the long-term benefits in terms of security and efficiency are well worth the effort. Let's break down the actions you need to take to make this transition.

Steps to Migrate to Trusted Publishing

Okay, let's get practical. Migrating to Trusted Publishing involves a few steps, but don't worry, it's totally manageable. Here’s a breakdown of the actions you need to take to ensure a smooth transition:

1. Set Up NPM Trust Relationship

This is the first step, and it's independent of which test-and-release workflow variant you're using. You need to configure Trusted Publishing in your NPM account. Here’s how:

1. Log in to npmjs.com: Use the account that has publishing rights for your package. This is crucial, guys! Make sure you're using the right account.
2. Navigate to your package page:
   • Go to https://www.npmjs.com/package/YOUR-PACKAGE-NAME. Replace YOUR-PACKAGE-NAME with your actual package name.
   • Click on the "Settings" tab.
3. 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 this blank.

     IMPORTANT: all information is case sensitive! Make sure you double-check everything.

4. Save the configuration.

For more detailed information, you can check out these resources:

• NPM Trusted Publishing documentation
• GitHub Actions OIDC documentation

Setting up the trust relationship is like registering your project with NPM's new security system. Once this is done, you're ready to adjust your workflow files.

2. Adapt Your Workflow File (for up-to-date test-and-release workflows)

If you're using the standard test-and-release workflow with iobroker/action-testing-deploy, you'll need to make a few changes to your workflow file. Here’s how:

1. Open test-and-release.yml: You can edit this file directly on GitHub or in your local development environment.

2. Remove npm-token from the deploy section:

   • Locate the job named deploy. It should look something like this:

   # 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 creating an invalid YAML file. If the permissions: block is missing altogether, add it including the contents: write line as shown in the example.

3. Test your release and deploy workflow: Create a test release to check if everything is working correctly.

4. (Optional) Remove the NPM_TOKEN secret: After confirming that everything works, you can remove the NPM_TOKEN secret from your GitHub repository settings. This is an extra step to ensure you’re not storing unnecessary credentials.

Making these changes is like fine-tuning your engine for a smoother ride. By removing the npm-token and adding the id-token permission, you’re enabling GitHub Actions to handle the authentication securely.

3. Handling Private, Modified, or Outdated Workflows

If your repository isn't using the standard test-and-release workflow, there are a few more things to consider:

• Evaluate using the standard workflow: If possible, switch to the standard workflow and follow the steps outlined above. This is the easiest and most recommended approach.
• Use ioBroker/testing-action-deploy@v1: If you must keep a modified or private workflow, consider using the ioBroker/testing-action-deploy@v1 action within your workflow. You can then follow the same migration guide as for the standard workflow.
• Follow NPM's Trusted Publishing documentation: If you need to use a completely private deploy mechanism, follow the steps described in the NPM Trusted Publishing documentation. Here are some important points to keep in mind:
  • Ensure you enter the correct workflow name when setting up Trusted Publishing.
  • Use the latest NPM release to process the deploy. Use a dedicated npm install -g npm@latest command within your workflow. The NPM packaged with your Node.js release might be too old.
  • Do not use a token or try to log in to NPM. Use npm publish without dedicated authorization.

For those using custom workflows, it’s a bit like navigating uncharted territory. You need to ensure that your setup aligns with NPM's requirements for Trusted Publishing, paying close attention to versioning and authentication.

A Helping Hand: Upcoming PR for Standard Workflows

Here’s some great news! A tool is being developed to generate a Pull Request (PR) that adds the required changes to the standard test-and-release workflow. This means that if you're using the standard workflow, you might be able to sit tight for a few more days and receive a PR proposing the necessary changes to your test-and-release.yml file. Keep an eye out for it! The PR is expected to land within the next week. However, note that you won't receive a PR if you're not using the default/standard workflow. So, if you've customized your workflow, you'll need to make the changes manually.

This tool is a fantastic time-saver, making the migration process even smoother. It’s like having an expert mechanic automatically tune up your car – less work for you, and better performance in the long run.

Need Help? We've Got You Covered!

If you have any questions or run into any issues during the migration process, don't hesitate to reach out! The ioBroker community is here to help. You can connect with us on our development channels on Telegram and GitHub. You can find invites at https://www.iobroker.dev. Alternatively, you can drop a comment below and mention @mcm1957. We're all in this together, and we want to make sure everyone has a smooth transition.

Think of it as a team effort – we’re all working towards a more secure and efficient publishing process. Your questions and feedback help us improve, so don’t be shy about asking for assistance.

Final Thoughts

The NPM classic token revocation is a significant step towards enhancing the security of the JavaScript ecosystem. Migrating to Trusted Publishing is essential to ensure your automated deployments continue to work seamlessly. It might seem like a bit of work initially, but the long-term benefits in terms of security and efficiency are well worth it.

So, let’s get this done, guys! By following the steps outlined in this guide, you can ensure a smooth transition to Trusted Publishing. And remember, the ioBroker community is here to support you every step of the way. Thanks a lot for maintaining your adapters and contributing to the community. Let's work together for the best user experience!

Your ioBroker Check and Service Bot

---

Deutsche Beschreibung (German Description)

Hallo zusammen,

NPM widerruft klassische Token, und es ist Zeit, auf Trusted Publishing umzusteigen! Dies ist ein wichtiges Sicherheitsupdate, daher wollen wir uns ansehen, was passiert und was ihr tun müsst. Wenn ihr klassische Token in eurer Automatisierung, CI/CD-Pipelines oder lokalen Entwicklung verwendet, müsst ihr bis Anfang November auf granulare Zugriffstoken migrieren, um Unterbrechungen bei der Veröffentlichung zu vermeiden. Lasst uns loslegen und sicherstellen, dass euer Workflow reibungslos läuft!

Was passiert mit den NPM-Token?

Also, was ist los? NPM nimmt einige große Änderungen an seiner Sicherheitskonfiguration vor, und ihr habt möglicherweise bereits eine E-Mail darüber gesehen. Die wichtigste Erkenntnis ist, dass klassische Token Anfang November dauerhaft widerrufen werden. Dies ist Teil einer umfassenderen Anstrengung, das NPM-Ökosystem vor Angriffen auf die Lieferkette und anderen Schwachstellen zu schützen. Diese Angriffe nutzen oft kompromittierte, langlebige Token aus, was diese Änderung entscheidend macht, um die Sicherheit eurer Pakete und Workflows zu gewährleisten. Es geht darum, die Community sicher und gesund zu halten!

Die Änderungen werden in Phasen ausgerollt. Seit dem 13. Oktober hat NPM neue granulare Token mit einer maximalen Lebensdauer von 90 Tagen (mit einem Standard von 7 Tagen) eingeführt und neue TOTP 2FA-Konfigurationen deaktiviert (bestehende funktionieren jedoch weiterhin). Die große Sache ist jedoch der Widerruf aller klassischen Token Anfang November. Dies bedeutet, dass alle automatisierten Bereitstellungen, die den Standard-Workflow test-and-release.yml verwenden, nicht mehr funktionieren, wenn ihr noch auf klassische Token angewiesen seid. Die gute Nachricht? Es gibt eine Lösung: die Migration zu Trusted Publishing.

Einfach ausgedrückt, NPM meint es ernst mit der Sicherheit, und diese Änderungen sind ein notwendiger Schritt. Stellt es euch wie das Aufrüsten der Schlösser an eurem Haus vor – es mag anfangs etwas Aufwand erfordern, aber es lohnt sich für den Seelenfrieden. Die Migration zu Trusted Publishing mag wie eine lästige Pflicht erscheinen, aber es ist ein zukunftsweisender Schritt, der mit den Best Practices in der Branche übereinstimmt. Außerdem unterstützen ioBroker-Tools diese Migration bereits, was den Übergang für diejenigen im ioBroker-Ökosystem reibungsloser macht. Also, lasst uns die Ärmel hochkrempeln und das erledigen!

Warum Trusted Publishing der richtige Weg ist

Trusted Publishing ist der empfohlene Weg nach vorn, und es ist eine gute Nachricht, dass ioBroker-Tools es bereits unterstützen! Aber warum ist diese Migration so wichtig? Ohne klassische und dauerhaft gültige Token wird die automatische Bereitstellung mit dem Standard-Workflow unterbrochen. Trusted Publishing bietet einen sichereren und optimierten Ansatz, der das Risiko einer Token-Kompromittierung reduziert. Durch den Wechsel haltet ihr euch nicht nur an die neuen Anforderungen von NPM, sondern verbessert auch die Sicherheit eurer Projekte. Es ist wie ein Upgrade von einem normalen Schlüssel zu einem Hightech-Smartlock – viel sicherer und bequemer auf lange Sicht.

Bei der Migration zu Trusted Publishing geht es im Wesentlichen darum, von langlebigen, statischen Token zu kurzlebigen, dynamischen Anmeldeinformationen überzugehen, die von GitHub Actions verwaltet werden. Das bedeutet, dass ihr euch nicht mehr darauf verlasst, ein sensibles Token in den Geheimnissen eures Repositorys zu speichern, sondern auf die OpenID Connect (OIDC)-Integration von GitHub mit NPM. Diese Methode stellt sicher, dass euer Veröffentlichungsworkflow sicher authentifiziert wird, ohne eure Anmeldeinformationen preiszugeben.

Stellt es euch so vor: Stellt euch vor, ihr versendet ein Paket. Anstatt dem Zusteller einen permanenten Schlüssel für euer Haus zu geben (ein klassisches Token), gebt ihr ihm einen temporären Code, der nur für diese spezielle Zustellung funktioniert (Trusted Publishing). Sobald das Paket zugestellt ist, verfällt der Code, wodurch euer Haus viel sicherer wird. Dieser Ansatz reduziert das Zeitfenster für böswillige Akteure, kompromittierte Anmeldeinformationen auszunutzen, erheblich.

Die Einführung von Trusted Publishing ist also ein proaktiver Schritt hin zu einem sichereren und zuverlässigeren Veröffentlichungsprozess. Es mag wie eine kleine Umstellung erscheinen, aber die langfristigen Vorteile in Bezug auf Sicherheit und Effizienz sind den Aufwand wert. Lasst uns die Maßnahmen aufschlüsseln, die ihr ergreifen müsst, um diesen Übergang zu vollziehen.

Schritte zur Migration zu Trusted Publishing

Okay, lasst uns praktisch werden. Die Migration zu Trusted Publishing umfasst ein paar Schritte, aber keine Sorge, es ist alles machbar. Hier ist eine Aufschlüsselung der Maßnahmen, die ihr ergreifen müsst, um einen reibungslosen Übergang zu gewährleisten:

1. Einrichten einer NPM-Vertrauensbeziehung

Dies ist der erste Schritt, und er ist unabhängig davon, welche test-and-release-Workflow-Variante ihr verwendet. Ihr müsst Trusted Publishing in eurem NPM-Konto konfigurieren. So geht's:

1. Meldet euch bei npmjs.com an: Verwendet das Konto, das über Veröffentlichungsrechte für euer Paket verfügt. Das ist entscheidend! Stellt sicher, dass ihr das richtige Konto verwendet.
2. Navigiert zu eurer Paketseite:
   • Geht zu https://www.npmjs.com/package/YOUR-PACKAGE-NAME. Ersetzt YOUR-PACKAGE-NAME durch euren tatsächlichen Paketnamen.
   • Klickt auf die Registerkarte "Einstellungen".
3. Konfigurieren von Trusted Publishing:

   • Scrollt nach unten zum Abschnitt "Veröffentlichungszugriff".

   • Klickt auf "Automatisches Veröffentlichen mit GitHub Actions" oder "Trusted Publisher hinzufügen".

   • Gebt die erforderlichen Informationen ein:

     • Repository-Inhaber: 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).
     • Umgebung: Lasst dies leer.

     WICHTIG: Alle Informationen sind groß- und kleinschreibungssensitiv! Stellt sicher, dass ihr alles doppelt überprüft.

4. Speichert die Konfiguration.

Weitere Informationen findet ihr in diesen Ressourcen:

• NPM Trusted Publishing-Dokumentation
• GitHub Actions OIDC-Dokumentation

Das Einrichten der Vertrauensbeziehung ist wie das Registrieren eures Projekts beim neuen Sicherheitssystem von NPM. Sobald dies erledigt ist, seid ihr bereit, eure Workflow-Dateien anzupassen.

2. Anpassen eurer Workflow-Datei (für aktuelle test-and-release-Workflows)

Wenn ihr den Standard-test-and-release-Workflow mit iobroker/action-testing-deploy verwendet, müsst ihr einige Änderungen an eurer Workflow-Datei vornehmen. So geht's:

1. Öffnet test-and-release.yml: Ihr könnt diese Datei direkt auf GitHub oder in eurer lokalen Entwicklungsumgebung bearbeiten.

2. Entfernt npm-token aus dem Bereitstellungsabschnitt:

   • Sucht den Job namens deploy. Er sollte ungefähr so aussehen:

   # Stellt das endgültige Paket auf NPM bereit
   deploy:
     needs: [check-and-lint, adapter-tests]
   
     # Löst diesen Schritt nur aus, wenn ein Commit in einem beliebigen Branch mit einer Versionsnummer versehen ist
     if: |
       contains(github.event.head_commit.message, '[skip ci]') == false &&
       github.event_name == 'push' &&
       startsWith(github.ref, 'refs/tags/v')
   
     runs-on: ubuntu-latest
   
     # Schreibberechtigungen sind erforderlich, um GitHub-Releases zu erstellen
     permissions:
       contents: write
   
     steps:
       - uses: ioBroker/testing-action-deploy@v1
         with:
           node-version: '20.x'
           # Entfernt die Auskommentierung der folgenden Zeile, wenn euer Adapter nicht mit 'npm ci' installiert werden kann
           # install-command: 'npm install'
           build: true
           npm-token: ${{ secrets.NPM_TOKEN }}
           github-token: ${{ secrets.GITHUB_TOKEN }}
   

   • Sucht 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. Stellt sicher, dass die Einrückung korrekt ist, um die Erstellung einer ungültigen YAML-Datei zu vermeiden. Wenn der permissions:-Block vollständig fehlt, fügt ihn einschließlich der Zeile contents: write wie im Beispiel gezeigt hinzu.

3. Testet euren Release- und Bereitstellungsworkflow: Erstellt einen Test-Release, um zu überprüfen, ob alles korrekt funktioniert.

4. (Optional) Entfernt das NPM_TOKEN-Geheimnis: Nachdem ihr bestätigt habt, dass alles funktioniert, könnt ihr das NPM_TOKEN-Geheimnis aus euren GitHub-Repository-Einstellungen entfernen. Dies ist ein zusätzlicher Schritt, um sicherzustellen, dass ihr keine unnötigen Anmeldeinformationen speichert.

Diese Änderungen vorzunehmen ist wie die Feinabstimmung eures Motors für eine reibungslosere Fahrt. Indem ihr das npm-token entfernt und die id-token-Berechtigung hinzufügt, ermöglicht ihr GitHub Actions, die Authentifizierung sicher zu handhaben.

3. Umgang mit privaten, geänderten oder veralteten Workflows

Wenn euer Repository nicht den Standard-test-and-release-Workflow verwendet, gibt es ein paar weitere Dinge zu beachten:

• Bewertet die Verwendung des Standard-Workflows: Wenn möglich, wechselt zum Standard-Workflow und befolgt die oben beschriebenen Schritte. Dies ist der einfachste und empfehlenswerteste Ansatz.
• Verwendet ioBroker/testing-action-deploy@v1: Wenn ihr einen geänderten oder privaten Workflow beibehalten müsst, solltet ihr die Aktion ioBroker/testing-action-deploy@v1 innerhalb eures Workflows verwenden. Ihr könnt dann der gleichen Migrationsanleitung wie für den Standard-Workflow folgen.
• Befolgt die Trusted Publishing-Dokumentation von NPM: Wenn ihr einen vollständig privaten Bereitstellungsmechanismus verwenden müsst, befolgt die Schritte, die in der NPM Trusted Publishing-Dokumentation beschrieben sind. Hier sind einige wichtige Punkte, die ihr beachten solltet:
  • Stellt sicher, dass ihr beim Einrichten von Trusted Publishing den korrekten Workflow-Namen eingebt.
  • Verwendet die neueste NPM-Version, um die Bereitstellung zu verarbeiten. Verwendet einen dedizierten Befehl npm install -g npm@latest innerhalb eures Workflows. Das mit eurer Node.js-Version verpackte NPM könnte zu alt sein.
  • Verwendet kein Token oder versucht, euch bei NPM anzumelden. Verwendet npm publish ohne dedizierte Autorisierung.

Für diejenigen, die benutzerdefinierte Workflows verwenden, ist es ein bisschen wie das Navigieren in unbekanntem Terrain. Ihr müsst sicherstellen, dass eure Einrichtung mit den Anforderungen von NPM für Trusted Publishing übereinstimmt, wobei ihr der Versionierung und Authentifizierung besondere Aufmerksamkeit schenken müsst.

Eine helfende Hand: Kommender PR für Standard-Workflows

Hier sind einige großartige Neuigkeiten! Es wird ein Tool entwickelt, um eine Pull Request (PR) zu generieren, die die erforderlichen Änderungen am Standard-test-and-release-Workflow hinzufügt. Dies bedeutet, dass ihr, wenn ihr den Standard-Workflow verwendet, möglicherweise noch ein paar Tage warten könnt und eine PR erhaltet, die die notwendigen Änderungen an eurer test-and-release.yml-Datei vorschlägt. Haltet die Augen offen! Der PR wird voraussichtlich innerhalb der nächsten Woche eintreffen. Beachtet jedoch, dass ihr keine PR erhaltet, wenn ihr nicht den Standard-Workflow verwendet. Wenn ihr euren Workflow angepasst habt, müsst ihr die Änderungen also manuell vornehmen.

Dieses Tool ist ein fantastischer Zeitsparer, der den Migrationsprozess noch reibungsloser macht. Es ist, als ob ein erfahrener Mechaniker euer Auto automatisch abstimmt – weniger Arbeit für euch und eine bessere Leistung auf lange Sicht.

Braucht ihr Hilfe? Wir sind für euch da!

Wenn ihr Fragen habt oder während des Migrationsprozesses auf Probleme stoßt, zögert nicht, euch zu melden! Die ioBroker-Community ist hier, um zu helfen. Ihr könnt euch über unsere Entwicklerkanäle auf Telegram und GitHub mit uns in Verbindung setzen. Einladungen findet ihr unter https://www.iobroker.dev. Alternativ könnt ihr unten einen Kommentar hinterlassen und @mcm1957 erwähnen. Wir sitzen alle im selben Boot und möchten sicherstellen, dass alle einen reibungslosen Übergang haben.

Stellt es euch als Teamarbeit vor – wir arbeiten alle auf einen sichereren und effizienteren Veröffentlichungsprozess hin. Eure Fragen und euer Feedback helfen uns, uns zu verbessern, also scheut euch nicht, um Hilfe zu bitten.

Abschließende Gedanken

Der Widerruf des klassischen NPM-Tokens ist ein bedeutender Schritt zur Verbesserung der Sicherheit des JavaScript-Ökosystems. Die Migration zu Trusted Publishing ist unerlässlich, um sicherzustellen, dass eure automatisierten Bereitstellungen weiterhin nahtlos funktionieren. Es mag anfänglich etwas Arbeit bedeuten, aber die langfristigen Vorteile in Bezug auf Sicherheit und Effizienz sind es wert.

Also, lasst es uns anpacken! Indem ihr die in diesem Leitfaden beschriebenen Schritte befolgt, könnt ihr einen reibungslosen Übergang zu Trusted Publishing sicherstellen. Und denkt daran, die ioBroker-Community ist hier, um euch bei jedem Schritt zu unterstützen. Vielen Dank für die Pflege eurer Adapter und den Beitrag zur Community. Lasst uns gemeinsam für das beste Benutzererlebnis arbeiten!

Euer ioBroker Check and Service Bot