Fixing the Cursor (and Other) Apt Repository NO_PUBKEY Error

09 Nov, 2026

You install Cursor (or some other .deb), everything seems fine, then the next sudo apt update greets you with:

W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. 
GPG error: https://downloads.cursor.com/aptrepo stable InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 42A1772E62E492D6
W: Failed to fetch https://downloads.cursor.com/aptrepo/dists/stable/InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 42A1772E62E492D6
W: Some index files failed to download. They have been ignored, or old ones used instead.

This happens more often than it should with third-party packages. The .deb installer adds the repository entry but doesn't always correctly install or reference the signing key. The result is a repo that apt refuses to trust.

Here's how to fix it properly, plus a couple of related annoyances that often show up at the same time.

The Proper Fix for Cursor

The official key lives at https://downloads.cursor.com/keys/anysphere.asc. The modern way to handle it is to place it in /etc/apt/keyrings/ and explicitly point the repository at it with signed-by.

# Create the keyrings directory if it doesn't exist
sudo mkdir -p /etc/apt/keyrings

# Download and install the Cursor signing key
curl -fsSL https://downloads.cursor.com/keys/anysphere.asc \
  | gpg --dearmor \
  | sudo tee /etc/apt/keyrings/cursor.gpg > /dev/null

sudo chmod 644 /etc/apt/keyrings/cursor.gpg

# Add (or replace) the repository entry, restricted to supported architectures
echo "deb [arch=amd64,arm64 signed-by=/etc/apt/keyrings/cursor.gpg] https://downloads.cursor.com/aptrepo stable main" \
  | sudo tee /etc/apt/sources.list.d/cursor.list > /dev/null

# Refresh
sudo apt update

That should clear the NO_PUBKEY error.

If You Already Have a Deb822 `.sources` File

Some installs (especially the official .deb) create a Deb822-style file instead of a one-line .list file. Check what you have:

ls -l /etc/apt/sources.list.d/cursor*
cat /etc/apt/sources.list.d/cursor*

If you see a .sources file pointing at /usr/share/keyrings/anysphere.gpg (or similar), you have two clean options:

Update the Signed-By: line in that file to match the key you just installed (/etc/apt/keyrings/cursor.gpg), or
Install the key where the existing file expects it:

curl -fsSL https://downloads.cursor.com/keys/anysphere.asc \
  | gpg --dearmor \
  | sudo tee /usr/share/keyrings/anysphere.gpg > /dev/null

sudo chmod 644 /usr/share/keyrings/anysphere.gpg

Either works. Just make sure the path in the source file and the actual key file match.

The "Skipping acquire ... i386" Notices

After fixing the key, you might see notices like these:

N: Skipping acquire of configured file 'main/binary-i386/Packages' as repository 'https://downloads.cursor.com/aptrepo stable InRelease' doesn't support architecture 'i386'
N: Skipping acquire of configured file 'main/binary-i386/Packages' as repository 'https://pkg.helium.computer/deb stable InRelease' doesn't support architecture 'i386'

These are harmless. Apt is trying to fetch an i386 index that the repository never published. They don't break updates.

You silence them by telling apt which architectures the repository actually supports. In the .list example above, the [arch=amd64,arm64 ...] part does exactly that.

For a Deb822 .sources file, add this line:

Architectures: amd64 arm64

The same approach works for other repositories (Helium, in the example above, is a common one). Their official install line already includes the architecture restriction:

echo "deb [arch=amd64,arm64 signed-by=/usr/share/keyrings/helium.gpg] https://pkg.helium.computer/deb stable main" \
  | sudo tee /etc/apt/sources.list.d/helium.list

General Pattern for Any Third-Party Apt Repo

The same problem shows up with other packages. The reliable pattern is:

Find the official key URL from the project's documentation.
Download it, dearmor it, and put it in /etc/apt/keyrings/ (or /usr/share/keyrings/ if the project's docs use that path).
Create a source entry that uses signed-by= (or Signed-By: in Deb822) pointing at that exact key file.
Restrict architectures with arch= if the repo only ships amd64/arm64.
Run sudo apt update and confirm the warnings are gone.

Avoid the old apt-key add method. It's deprecated and makes key management messier.

Quick Diagnostic Commands

When a repo is misbehaving, these help:

# See all Cursor/Helium/etc. source files
grep -R "downloads.cursor.com\|helium.computer" /etc/apt/sources.list /etc/apt/sources.list.d/

# Check what keys are actually present
ls -l /etc/apt/keyrings/ /usr/share/keyrings/

# See the exact error for one repo
sudo apt update 2>&1 | grep -i -E 'cursor|helium|NO_PUBKEY|Skipping'

Notes

If you have both a .list and a .sources file for the same repo, remove or comment out one of them so you don't have duplicates.
Grok Bot (if installed) uses a separate suite (grok-bot) in the same Cursor apt repository. The same key and architecture handling applies.
The key fingerprint for Cursor's current signing key is 380FF4BCDC34A4BD92A3565342A1772E62E492D6 if you ever want to verify it.

That's the whole thing. Once the key path and the source file agree, and architectures are restricted, apt update stays quiet and future upgrades for Cursor (or whatever repo you fixed) just work.

Written after another round of "why is the Cursor repo broken again?" on Ubuntu 24.04. Future me, you're welcome.

#linux #solutions