NPM Revoking Classic Tokens Migrate To Trusted Publishing By November 2025

by StackCamp Team 75 views

Hey guys! It's time to talk about some important security changes happening over at NPM that might affect your projects and workflows. NPM is revoking classic tokens, and the recommendation is to migrate to Trusted Publishing before early November 2025. Let's dive into what this means for you and how to make the switch!

What's Happening with NPM?

NPM is making several security-related changes, and you might have already received an email about it. Here’s the gist of what's going on:

  • October 13: New granular tokens limited to a 90-day maximum lifetime (with a 7-day default).
  • October 13: New TOTP 2FA configurations are disabled (but existing TOTP still works).
  • Early November: All classic tokens will be permanently revoked.

Why the Change?

These changes are crucial because recent supply chain attacks have highlighted that compromised long-lived tokens are a significant vulnerability. By phasing out classic tokens, NPM aims to protect the ecosystem and your packages from malicious actors. It’s all about making NPM a safer place for everyone.

What Action Do You Need to Take?

The most critical piece of information is that all classic tokens will be permanently revoked in early November. If you're using classic tokens in any automation, CI/CD pipelines, or local development, you must migrate to granular access tokens before this deadline to avoid any disruptions. This is super important, so let's get it sorted!

Migration to Trusted Publishing: The Recommended Path

Without classic and permanently valid tokens, automatic deployment using the standard test-and-release.yml workflow will no longer work. The recommended solution is to migrate to Trusted Publishing. The good news? ioBroker tools already support this!

What is Trusted Publishing?

Trusted Publishing is a more secure way to manage your NPM packages. It leverages GitHub Actions and OpenID Connect (OIDC) to establish a trust relationship between your GitHub repository and NPM. This means you won't need long-lived tokens, reducing the risk of token compromise.

Benefits of Trusted Publishing

  • Enhanced Security: No more long-lived tokens floating around.
  • Automated Deployments: Seamless integration with GitHub Actions.
  • Improved Workflow: Streamlined publishing process.

Steps to Migrate to Trusted Publishing

Alright, let’s get down to the nitty-gritty. Here’s how you can migrate to Trusted Publishing. These steps are crucial, so follow along closely!

1. Set Up the NPM Trust Relationship

This is the foundational step, and it’s independent of your test-and-release workflow variant.

  1. Log in to npmjs.com: Use an account with publish rights for your package. Make sure you have the correct permissions!.
  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. This is where the magic happens!.
  3. Configure Trusted Publishing:

    • Scroll down to the Publishing access section. Keep scrolling, you're almost there!.

    • Click on Automate publishing with GitHub Actions or Add trusted publisher. Choose your adventure!.

    • Fill in the required information:

      • Repository owner: Your GitHub username or organization (e.g., ioBroker). Who owns this repo?.
      • Repository name: Your adapter repository name (e.g., ioBroker.your-adapter). Name that repo!.
      • Workflow name: test-and-release.yml (or the name of your release workflow). Workflow is the way to go!.
      • Environment: Leave this blank. Keep it clean!.

      IMPORTANT: All information is case-sensitive! Double-check that you've entered everything correctly. Case matters, guys!.

  4. Save the configuration. Don't forget to hit that save button!.

For more detailed information, check out:

2. Actions for Repositories Using Up-to-Date test-and-release Workflow

If you're using the iobroker/action-testing-deploy action, these steps are for you. Let's tweak that workflow!.

  1. Open test-and-release.yml: Edit this file directly on GitHub or in your development environment. Get your hands dirty!.

  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:. Spot the token!.

    • Remove this line (or comment it out by adding a # as the first character). Snip snip!.

    • Locate the block starting with permissions:. Permissions time!.

    • Add a line id-token: write. Pay attention to the correct indentation to avoid creating an invalid YAML file. Indentation is key!.

    • If the permissions block is missing altogether, add it including the contents: write line as shown in the example. Add it all in!.

      Your permissions block should now look like this:

      permissions:
  contents: write
  id-token: write

  3. Test release and deploy workflow: Test the functionality by creating a test release. Time to test the waters!.

  4. Remove the NPM_TOKEN secret: You can remove the NPM_TOKEN secret from your GitHub repository settings (optional, after confirming everything works). Clean up those secrets!.

3. Actions for Repositories Using Private, Modified, or Outdated test-and-release.yml Workflow

If you're not using the standard workflow, here's what you should do. Let's get you on track!.

  • Evaluate Using the Standard Workflow: Consider switching to the standard test-and-release workflow and follow the steps described earlier. The standard way is often the best way!.
  • If You Must Keep a Modified/Private Workflow:
    • At least consider using the action ioBroker/testing-action-deploy@v1 within your workflow. You can then follow the migration guide described previously. Baby steps are still steps!.
  • If You Really Must Use a Private Deploy Mechanism: Follow the steps described in the NPM Trusted Publishing documentation. Here are some important points:
    • Ensure that you've entered the correct workflow name when setting up Trusted Publishing. Double-check that name!.
    • Make sure you're using the newest NPM release to process the deploy. Use a dedicated npm install -g npm@latest command for the update within your workflow. The NPM packaged within your Node release might be too old. Add the NPM upgrade near the deploy command, but don't update NPM for the entire workflow, as this might cause negative side effects. Stay up-to-date!.
    • Do NOT use a token or try to log in to NPM. Use npm publish without dedicated authorization. No tokens needed!.

Upcoming PR for Standard Workflows

Good news! A tool is under development to generate a PR that adds the required changes to the standard test-and-release workflow. This means you might be able to wait a few more days to receive a PR proposing the necessary changes to your test-and-release.yml file. Help is on the way!.

Keep in mind that you will not receive a PR if you're not using the default/standard workflow. The PR is expected within the next week.

Need Help?

If you have any questions, don't hesitate to reach out! The best places to get help are the development channels at Telegram or GitHub (invites available at https://www.iobroker.dev). You can also drop a comment and mention @mcm1957. We're here to help!.

A HUGE THANKS for maintaining these adapters from all the users and me. Let's work together to create the best user experience possible! Teamwork makes the dream work!.

Your ioBroker Check and Service Bot

Deutsche Beschreibung

Hallo zusammen! Es ist an der Zeit, über wichtige Sicherheitsänderungen bei NPM zu sprechen, die eure Projekte und Arbeitsabläufe betreffen könnten. NPM widerruft klassische Token, und es wird empfohlen, bis Anfang November 2025 auf Trusted Publishing zu migrieren. Lasst uns eintauchen, was das für euch bedeutet und wie ihr den Wechsel vollzieht!

Was passiert bei NPM?

NPM nimmt mehrere sicherheitsrelevante Änderungen vor, und ihr habt möglicherweise bereits eine E-Mail darüber erhalten. Hier ist das Wesentliche:

  • 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.

Warum die Änderung?

Diese Änderungen sind entscheidend, da jüngste Angriffe auf die Lieferkette gezeigt haben, dass kompromittierte, langlebige Token eine erhebliche Schwachstelle darstellen. Durch die Abschaffung klassischer Token möchte NPM das Ökosystem und eure Pakete vor böswilligen Akteuren schützen. Es geht darum, NPM zu einem sichereren Ort für alle zu machen.

Welche Maßnahmen müsst ihr ergreifen?

Die wichtigste Information ist, dass alle klassischen Token Anfang November dauerhaft widerrufen werden. Wenn ihr klassische Token in Automatisierungen, CI/CD-Pipelines oder der lokalen Entwicklung verwendet, müsst ihr vor diesem Stichtag auf granulare Zugriffstoken migrieren, um Unterbrechungen zu vermeiden. Das ist super wichtig, also lasst es uns erledigen!

Migration zu Trusted Publishing: Der empfohlene Weg

Ohne klassische und dauerhaft gültige Token funktioniert die automatische Bereitstellung mit dem Standard-Workflow test-and-release.yml nicht mehr. Die empfohlene Lösung ist die Migration zu Trusted Publishing. Die gute Nachricht? ioBroker-Tools unterstützen dies bereits!

Was ist Trusted Publishing?

Trusted Publishing ist eine sicherere Möglichkeit, eure NPM-Pakete zu verwalten. Es nutzt GitHub Actions und OpenID Connect (OIDC), um eine Vertrauensbeziehung zwischen eurem GitHub-Repository und NPM herzustellen. Das bedeutet, dass ihr keine langlebigen Token benötigt, was das Risiko eines Token-Kompromisses verringert.

Vorteile von Trusted Publishing

  • Erhöhte Sicherheit: Keine langlebigen Token mehr, die herumschwirren.
  • Automatisierte Bereitstellungen: Nahtlose Integration mit GitHub Actions.
  • Verbesserter Workflow: Optimierter Veröffentlichungsprozess.

Schritte zur Migration zu Trusted Publishing

Gut, lasst uns ins Detail gehen. Hier erfahrt ihr, wie ihr zu Trusted Publishing migrieren könnt. Diese Schritte sind entscheidend, also folgt genau!

1. Einrichten der NPM-Vertrauensbeziehung

Dies ist der grundlegende Schritt, und er ist unabhängig von eurer test-and-release-Workflow-Variante.

  1. Bei npmjs.com anmelden: Verwendet ein Konto mit Veröffentlichungsrechten für euer Paket. Stellt sicher, dass ihr die richtigen Berechtigungen habt!.
  2. Zur Paketseite navigieren: Geht zu https://www.npmjs.com/package/YOUR-PACKAGE-NAME. Ersetzt YOUR-PACKAGE-NAME durch euren tatsächlichen Paketnamen. Klickt auf den Tab Einstellungen. Hier geschieht die Magie!.
  3. Trusted Publishing konfigurieren:

    • Scrollt nach unten zum Abschnitt Veröffentlichungszugriff. Scrollt weiter, ihr seid fast da!.

    • Klickt auf Automatisches Veröffentlichen mit GitHub Actions oder Trusted Publisher hinzufügen. Wählt euer Abenteuer!.

    • Füllt die erforderlichen Informationen aus:

      • Repository-Inhaber: Euer GitHub-Benutzername oder eure Organisation (z. B. ioBroker). Wer besitzt dieses Repo?.
      • Repository-Name: Der Name eures Adapter-Repositorys (z. B. ioBroker.your-adapter). Nennt dieses Repo!.
      • Workflow-Name: test-and-release.yml (oder der Name eures Release-Workflows). Workflow ist der richtige Weg!.
      • Umgebung: Lasst dies leer. Haltet es sauber!.

      WICHTIG: Alle Informationen sind Groß- und Kleinschreibung-sensitiv! Überprüft noch einmal, ob ihr alles korrekt eingegeben habt. Auf die Groß- und Kleinschreibung kommt es an, Leute!.

  4. Konfiguration speichern. Vergesst nicht, den Speicherbutton zu drücken!.

Für detailliertere Informationen schaut euch Folgendes an:

2. Aktionen für Repositories, die den aktuellen test-and-release-Workflow verwenden

Wenn ihr die Aktion iobroker/action-testing-deploy verwendet, sind diese Schritte für euch. Lasst uns diesen Workflow optimieren!.

  1. test-and-release.yml öffnen: Bearbeitet diese Datei direkt auf GitHub oder in eurer Entwicklungsumgebung. Werdet aktiv!.

  2. npm-token aus dem Deploy-Abschnitt entfernen:

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

      # 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. Entdeckt den Token!.

    • Entfernt diese Zeile (oder kommentiert sie aus, indem ihr ein # als erstes Zeichen hinzufügt). Schnipp schnapp!.

    • Sucht den Block, der mit permissions: beginnt. Zeit für Berechtigungen!.

    • Fügt eine Zeile id-token: write hinzu. Achtet auf die korrekte Einrückung, um eine ungültige YAML-Datei zu vermeiden. Einrückung ist entscheidend!.

    • Wenn der permissions-Block vollständig fehlt, fügt ihn einschließlich der Zeile contents: write hinzu, wie im Beispiel gezeigt. Fügt alles hinzu!.

      Euer permissions-Block sollte jetzt so aussehen:

      permissions:
  contents: write
  id-token: write

  3. Release- und Deploy-Workflow testen: Testet die Funktionalität, indem ihr ein Test-Release erstellt. Zeit, das Wasser zu testen!.

  4. NPM_TOKEN-Geheimnis entfernen: Ihr könnt das NPM_TOKEN-Geheimnis aus euren GitHub-Repository-Einstellungen entfernen (optional, nachdem ihr bestätigt habt, dass alles funktioniert). Bereinigt diese Geheimnisse!.

3. Aktionen für Repositories, die private, modifizierte oder veraltete test-and-release.yml-Workflows verwenden

Wenn ihr nicht den Standard-Workflow verwendet, solltet ihr Folgendes tun. Lasst uns euch auf den richtigen Weg bringen!.

  • Bewertet die Verwendung des Standard-Workflows: Erwägt den Wechsel zum Standard-Workflow test-and-release und befolgt die zuvor beschriebenen Schritte. Der Standardweg ist oft der beste Weg!.
  • Wenn ihr einen modifizierten/privaten Workflow beibehalten müsst:
    • Erwägt zumindest die Verwendung der Aktion ioBroker/testing-action-deploy@v1 innerhalb eures Workflows. Dann könnt ihr der zuvor beschriebenen Migrationsanleitung folgen. Kleine Schritte sind auch Schritte!.
  • Wenn ihr wirklich einen privaten Bereitstellungsmechanismus verwenden müsst: Befolgt die Schritte, die in der NPM Trusted Publishing-Dokumentation beschrieben sind. Hier sind einige wichtige Punkte:
    • Stellt sicher, dass ihr den korrekten Workflow-Namen bei der Einrichtung von Trusted Publishing eingegeben habt. Überprüft diesen Namen!.
    • Stellt sicher, dass ihr die neueste NPM-Version verwendet, um den Bereitstellungsprozess zu verarbeiten. Verwendet einen dedizierten Befehl npm install -g npm@latest für das Update innerhalb eures Workflows. Das in eurer Node-Version enthaltene NPM ist möglicherweise zu alt. Fügt das NPM-Upgrade in der Nähe des Bereitstellungsbefehls hinzu, aktualisiert NPM jedoch nicht für den gesamten Workflow, da dies negative Auswirkungen haben könnte. Bleibt auf dem neuesten Stand!.
    • Verwendet KEINEN Token und versucht NICHT, euch bei NPM anzumelden. Verwendet npm publish ohne dedizierte Autorisierung. Keine Token erforderlich!.

Kommender PR für Standard-Workflows

Gute Nachrichten! Ein Tool zur Generierung eines PRs, das die erforderlichen Änderungen am Standard-test-and-release-Workflow vornimmt, befindet sich in Entwicklung. Das bedeutet, dass ihr möglicherweise noch ein paar Tage warten könnt, um einen PR zu erhalten, der die notwendigen Änderungen an eurer test-and-release.yml-Datei vorschlägt. Hilfe ist unterwegs!.

Beachtet, dass ihr keinen PR erhaltet, wenn ihr nicht den Standard-Workflow verwendet. Der PR wird innerhalb der nächsten Woche erwartet.

Braucht ihr Hilfe?

Wenn ihr Fragen habt, zögert nicht, euch zu melden! Die besten Orte, um Hilfe zu erhalten, sind die Entwicklungs-Kanäle auf Telegram oder GitHub (Einladungen unter https://www.iobroker.dev verfügbar). Ihr könnt auch einen Kommentar hinterlassen und @mcm1957 erwähnen. Wir sind hier, um zu helfen!.

EIN RIESIGES DANKESCHÖN für die Pflege dieser Adapter von allen Benutzern und mir. Lasst uns zusammenarbeiten, um das bestmögliche Benutzererlebnis zu schaffen! Gemeinsam sind wir stark!.

Euer ioBroker Check and Service Bot