APT repo questions

Sonatype Nexus Repository
1

Hello,

I’m setting up my first APT repo on NexusOSS. It is working, but I don’t get a few things:

  • Why does it need a private key ? I would rather expect it needs the public key, to publish it under KEY.gpg. Apparently it isn’t for signing the uploaded packages either.
  • How to provide the standard KEY.gpg ?

Thx !

1 Like
2

Because cryptographically signing a DEB is exactly like cryptographically signing an email.

Joe Random User verifies the signature using your public key, but you sign the DEB using your private key.

And then you publish your public key on a key server, or share it via Slack or DM or email, or on a website like I do here: https://gpgkeys.lobosstudios.com .

3

Keep in mind that you upload an unsigned DEB to Nexus. Nexus is actually signing your DEB for you, with the key you provide.

If you already have things working, I’m not sure why you asked question 2, but I’ll answer it anyhow:

  • you generate the key pair - GnuPG is the easiest way to do that, and it’s available for every major platform
  • you export an ASCII-armored copy of the private key
  • you load it into a text editor and copy it to the clipboard
  • last step: you paste it into the textarea titled “Signing Key” in your repo settings
1 Like
4

Hello Steve,

Many thanks for helping me ! :slight_smile:

The auto-sign feature was a scenario that would make sense to get the private key for. However, I just double checked, but download an uploaded unsigned .deb file still yields an unsigned .deb file. I’ve downloaded it straight from the ui. Not via apt (firewall issues). Maybe that’s the problem ?

For the key setup I’ve copy/pasted into the signing key field:
-----BEGIN PGP PRIVATE KEY BLOCK-----
…
-----END PGP PRIVATE KEY BLOCK-----

And put the passphrase into the passphrase field. I don’t see any errors in the log, so I assume this is the correct setup. Or is it ?

As for the other question, this is about the public key people need to import for the packages to be installed. Isn’t the usual location at the root path, named KEY.gpg ? I might be wrong there though.

5

That’s not how signing in debian repositories works. The deb files are never changed by the upload or signing process. It’s the index of files (Release) that gets signed. The Release file lists all Packages lists and their hashes (usually sha256, sometimes others as-well). Packages lists list all deb packages and their hashes and dependencies and metadata like description. When apt does an update it downloads those lists and finds out the hash of the debian files. When you later ask apt to download those debian files, it checks the hash, making sure the deb hasn’t been tampered with.

1 Like
6

I have problem with APT metadata on hosted repository.
I have created multiple APT hosted repositories but on some of them I don’t have “binary-amd64” packages.

Error on client:
apt update command:
N: Skipping acquire of configured file ‘main/binary-amd64/Packages’ as repository ‘http:///repository/apt-bionic-ansible bionic InRelease’ doesn’t support architecture ‘amd64’
N: Skipping acquire of configured file ‘main/binary-amd64/Packages’ as repository 'http://*/repository/apt-hosted bionic InRelease’ doesn’t support architecture ‘amd64’

Only 2 of 6 repos have this problem.

How to get rid of this messages on client?
Is there any way to add some dummy .deb file on repo to create missing metadata files?

7

I have created dummy.deb with “amd64” arhitecture file and pushed it to every apt hosted repository.
Now metadata for amd64 is created and now client does not get this warnings.