NPM Token Revocation: Migrate To Trusted Publishing!

Heads up, folks! NPM is making some crucial security updates that might affect your workflows. You might have already received an email from NPM outlining these changes. Let's break down what's happening and what you need to do to keep your packages running smoothly.

What will happen in the very near future?

NPM is rolling out several security-related updates. If you're an ioBroker user, you might have already received a notification about these changes. Here’s the gist of it:

• October 13: New granular tokens are now limited to a 90-day maximum lifetime (with a 7-day default). This means less risk of compromised tokens hanging around.
• October 13: New TOTP 2FA configurations are disabled (but existing TOTP setups still work). Basically, if you already use TOTP, you're good. If not, this option is temporarily off the table.
• Early November: All classic tokens will be permanently revoked. This is the big one we need to address.

The email from NPM probably looked something like this:

Dear iobroker-bot,

Important security changes are coming to npm that may affect your packages and workflows. This is the first phase of our comprehensive security improvements.

Phase 1 changes: • October 13: New granular tokens limited to 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

Action required: If you use classic tokens in any automation, CI/CD pipelines, or local development, you must migrate to granular access tokens before early November to avoid publishing disruptions.

More changes ahead: This is the first of several security updates. Additional phases will follow in the coming months, including further 2FA improvements and expanded trusted publisher support. We'll communicate each phase in advance.

Why we're making these changes: Recent supply chain attacks have shown that compromised long-lived tokens are a critical vulnerability. These phased changes are essential to protect the npm ecosystem and your packages from malicious actors.

Get full details and migration guidance: https://gh.io/npm-token-changes

Need help? • Join the discussion: https://github.com/orgs/community/discussions/174507 • Contact support: https://www.npmjs.com/support

We understand these changes require effort from you. Thank you for your partnership in making npm more secure for millions of developers worldwide.

The key takeaway? Classic tokens are going away, and we need to switch to something more secure. The deadline is early November, so let's get cracking!

Migration to Trusted Publishing recommended until early November 2025

The most critical part of the NPM mail states that all classic tokens will be permanently revoked in early November. So, what does this mean for you? If you're relying on classic, permanently valid tokens for automatic deployment using the standard test-and-release.yml workflow, things are about to change. Your current setup will stop working. The recommended solution is to migrate to Trusted Publishing. The good news is that ioBroker tools already support this!

Trusted Publishing offers a more secure way to handle deployments by linking your GitHub repository directly to your NPM account, eliminating the need for long-lived tokens. It's like giving GitHub Actions permission to publish on your behalf, but without handing over the keys to the kingdom.

So, without classic and permanently valid tokens, automatic deployment using the standard workflow test-and-release.yml will no longer work. Migration to 'Trusted Publishing' is therefore recommended and the good news is that this is already supported by ioBroker tools.

Actions needed for migration to "Trusted Publishing"

Ready to make the switch? Here’s what you need to do to migrate to Trusted Publishing. There are a few steps involved, but don't worry; we'll walk you through them.

Setup npm trust relationship (independent of test-and-release workflow variant)

First, you need to configure the trust relationship in your NPM account. This involves telling NPM that your GitHub repository is authorized to publish packages. Follow these steps:

1. Log in to npmjs.com: Use an account that has publish rights for your package. This is crucial; otherwise, you won't be able to configure Trusted Publishing.
2. Navigate to your package page:
   • Go to https://www.npmjs.com/package/YOUR-PACKAGE-NAME. Replace YOUR-PACKAGE-NAME with the actual name of your package.
   • Click on the "Settings" tab. This will take you to the configuration page for your package.
3. Configure Trusted Publishing:

   • Scroll down to the "Publishing access" section. Look for something like "Automate publishing with GitHub Actions" or "Add trusted publisher".

   • Click on that option. You'll be presented with a form to fill out.

   • 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). This is the file that defines your deployment process.
     • Environment: Leave blank. For most cases, you don't need to specify an environment.

     IMPORTANT: all information is case sensitive! Make sure you enter everything exactly as it appears on GitHub.

4. Save the configuration: Once you've filled out the form, save the configuration. This establishes the trust relationship between your NPM account and your GitHub repository.

For more information, see:

• NPM Trusted Publishing documentation
• GitHub Actions OIDC documentation

Actions for repositories using up-to-date test-and-release workflow using iobroker/action-testing-deploy

If you're using the standard test-and-release workflow with the iobroker/action-testing-deploy action, you're in luck! The migration is relatively straightforward. You'll need to tweak your workflow file.

You must adapt your workflow file test-and-release.yml.

1. Open test-and-release.yml: Edit this file either directly on GitHub or in your local development environment. Choose whichever method you're most comfortable with.
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:. This is the line you need to remove (or comment out by adding a # as the first character).

   • Locate the block starting with permissions:. If the block is missing altogether please add it including 'contents: write' line as shown in example

   • Add a line id-token: write. This grants the workflow permission to use the OIDC token for authentication. Take care of correct indentation to avoid creating an invalid yaml file.

3. Test release and deploy workflow Test functionality by creating a test release.
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 security measure to prevent the token from being accidentally used.

Actions for repositories using private, modified or outdated test-and-release.yml workflow

If your repository isn't using the standard test-and-release workflow, or if you've heavily modified it, the migration process might be a bit more involved. Here are some recommendations:

If your repository is not yet using the standard test-and-release workflow the following steps are recommended:

• Evaluate using the standard workflow: Consider switching to the standard test-and-release workflow and following the steps described above. This is the easiest and most maintainable solution.
• 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 migration guide described previously.
• Follow the NPM Trusted Publishing documentation: If you really must use a completely custom deployment mechanism, follow the steps described in the NPM Trusted Publishing documentation. Pay close attention to these points:
  • Workflow Name: Ensure that you enter the correct workflow name when setting up Trusted Publishing.
  • Latest NPM: Ensure that you're using the latest version of NPM for the deployment process. Use a dedicated npm install -g npm@latest command within your workflow to update NPM. The NPM version bundled with your Node.js release might be too old. Add the NPM upgrade near the deploy command - do not update npm for the complete workflow as this might cause negative side effects.
  • No Tokens: Do NOT use a token or try to log in to NPM. Use npm publish without dedicated authorization.

Upcoming PR for repositories using standard test-and-release.yml workflow

Good news! A tool is under development to generate a pull request (PR) that automatically adds the required changes to the standard test-and-release workflow. This means you might be able to simply accept a PR and be done with the migration.

A tool to generate a PR adding the required changes to the standard test-and-release workflow is under development. So you might wait some more days to receive a PR proposing the required changes to test-and-release.yml. Note that you will not receive a PR if you are not using the default / standard workflow. The PR is expected within the next week.

If you have any questions, reach out to the ioBroker community on Telegram or GitHub (invites are available at https://www.iobroker.dev). You can also leave a comment and mention @mcm1957.

THANKS A LOT for maintaining this adapter from me and all users. Let's work together for the best user experience.

your ioBroker Check and Service Bot

---

Deutsche Beschreibung

Was wird in naher Zukunft geschehen?

NPM ändert derzeit mehrere sicherheitsrelevante Parameter. Möglicherweise wurde bereits eine E-Mail von npm mit folgenden Informationen erhalten:

Dear iobroker-bot,

Important security changes are coming to npm that may affect your packages and workflows. This is the first phase of our comprehensive security improvements.

Phase 1 changes: • October 13: New granular tokens limited to 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

Action required: If you use classic tokens in any automation, CI/CD pipelines, or local development, you must migrate to granular access tokens before early November to avoid publishing disruptions.

More changes ahead: This is the first of several security updates. Additional phases will follow in the coming months, including further 2FA improvements and expanded trusted publisher support. We'll communicate each phase in advance.

Why we're making these changes: Recent supply chain attacks have shown that compromised long-lived tokens are a critical vulnerability. These phased changes are essential to protect the npm ecosystem and your packages from malicious actors.

Get full details and migration guidance: https://gh.io/npm-token-changes

Need help? • Join the discussion: https://github.com/orgs/community/discussions/174507 • Contact support: https://www.npmjs.com/support

We understand these changes require effort from you. Thank you for your partnership in making npm more secure for millions of developers worldwide.

Migration zu Trusted Publishing bis Anfang November 2025 empfohlen

Der wichtigste Teil der E-Mail lautet: Anfang November: Alle klassischen Token werden dauerhaft widerrufen

Ohne klassische und dauerhaft gültige Token funktioniert die automatische Bereitstellung mit dem Standard-Workflow test-and-release.yml nicht mehr. Die Migration zu 'Trusted Publishing' wird daher empfohlen, und die gute Nachricht ist, dass dies bereits von ioBroker-Tools unterstützt wird.

Erforderliche Aktionen für die Migration zu "Trusted Publishing"

Einrichtung der npm-Vertrauensbeziehung (unabhängig von der test-and-release Workflow-Variante)

Um die Migration zu Trusted Publishing zu initiieren, muss dies im NPM-Konto konfiguriert werden. Folgende Schritte sind dazu erforderlich:

1. Bei npmjs.com anmelden mit einem Konto, das Veröffentlichungsrechte für das Paket besitzt

2. Zur Paketseite navigieren:

   • Zu https://www.npmjs.com/package/YOUR-PACKAGE-NAME gehen
   • Auf den Tab "Settings" klicken

3. Trusted Publishing konfigurieren:

   • Nach unten zum Abschnitt "Publishing access" scrollen

   • Auf "Automate publishing with GitHub Actions" oder "Add trusted publisher" klicken

   • Die erforderlichen Informationen ausfüllen:

     • Repository owner: GitHub-Benutzername oder Organisation (z.B. ioBroker)
     • Repository name: Name des Adapter-Repositories (z.B. ioBroker.your-adapter)
     • Workflow name: test-and-release.yml (oder der Name des Release-Workflows)
     • Environment: Leer lassen

     ACHTUNG: Alle Eingaben sind casesensitiv! Groß-/Kleinschreibung genau beachten!

4. Konfiguration speichern

Weitere Informationen sind verfügbar unter:

• NPM Trusted Publishing documentation
• GitHub Actions OIDC Dokumentation

Aktionen für Repositories mit aktuellem test-and-release Workflow unter Verwendung von iobroker/action-testing-deploy

Die Workflow-Datei test-and-release.yml muss angepasst werden.

1. test-and-release.yml zur Bearbeitung öffnen, entweder direkt bei github.com oder in der lokalen Entwicklungsumgebung
2. npm-token aus dem deploy-Abschnitt entfernen

   • Den Job namens 'deploy' suchen. Er sollte wie folgt 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 }}
     

   • Die Zeile, die mit 'npm-token:' beginnt, suchen

   • Diese Zeile entfernen (oder auskommentieren, indem ein '#' als erstes Zeichen hinzugefügt wird)

   • Den Block, der mit 'permissions:' beginnt, suchen

   • Eine Zeile 'id-token: write' hinzufügen. Auf korrekte Einrückung achten, um eine ungültige YAML-Datei zu vermeiden. Falls der Block vollständig fehlt, diesen einschließlich der Zeile 'contents: write' wie im Beispiel gezeigt hinzufügen.

3. Release- und Deploy-Workflow testen Die Funktionalität durch Erstellen eines Test-Releases testen.
4. Das NPM_TOKEN Secret entfernen aus den GitHub-Repository-Einstellungen (optional, nachdem bestätigt wurde, dass alles funktioniert)

Aktionen für Repositories mit privaten, modifizierten oder veralteten test-and-release.yml Workflows

Falls das Repository noch nicht den Standard-test-and-release Workflow verwendet, werden folgende Schritte empfohlen:

• Prüfen, ob der Standard-test-and-release Workflow und der zuvor beschriebene Prozess verwendet werden können.
• Falls ein modifizierter / privater test-and-release Workflow beibehalten werden muss, zumindest die Verwendung der Action ioBroker/testing-action-deploy@v1 innerhalb des Workflows in Betracht ziehen. Dann kann dem zuvor beschriebenen Migrationsleitfaden gefolgt werden.
• Falls wirklich ein privater Deploy-Mechanismus verwendet werden muss, den Schritten in der NPM Trusted Publishing documentation folgen. Folgende Punkte sind dabei wichtig:
  • Sicherstellen, dass der korrekte Workflow-Name beim Einrichten von 'Trusted Publishing' eingegeben wurde
  • Sicherstellen, dass wirklich die neueste npm-Version für den Deploy-Prozess verwendet wird. Einen dedizierten 'npm install -g npm@latest' Befehl für das Update innerhalb des Workflows verwenden. Die mit der Node-Version gepackte npm-Version könnte zu alt sein. Das npm-Upgrade in der Nähe des Deploy-Befehls hinzufügen - npm nicht für den gesamten Workflow aktualisieren, da dies negative Nebeneffekte verursachen könnte.
  • KEINEN Token verwenden und NICHT versuchen, sich bei npm anzumelden. 'npm publish' ohne dedizierte Autorisierung verwenden.

Anstehender PR für Repositories mit Standard-test-and-release.yml Workflow

Ein Tool zur Generierung eines PRs, das die erforderlichen Änderungen zum Standard-test-and-release Workflow hinzufügt, befindet sich in der Entwicklung. Es kann also noch einige Tage gewartet werden, um einen PR mit den erforderlichen Änderungen an test-and-release.yml zu erhalten. Zu beachten ist, dass kein PR empfangen wird, falls nicht der Standard-Workflow verwendet wird. Der PR wird innerhalb der nächsten Woche erwartet.

Bei Fragen bitte Kontakt aufnehmen - am besten über die Entwicklungskanäle bei Telegram / Github (Einladungen verfügbar unter https://www.iobroker.dev) oder durch Hinterlassen eines Kommentars und Erwähnen von @mcm1957.

VIELEN DANK für die Pflege dieses Adapters von mir und allen Benutzern. Gemeinsam für die beste Benutzererfahrung arbeiten.

Euer ioBroker Check and Service Bot