We host some of our own software packages as debs in a repository of our own. For prototyping purposes, we’ve been running “unauthenticated”. Now we're trying to do things more correctly and do the whole GPG thing. What I’ve tried, just for test run is the following:

1) Make a key with gpg-gen

~$ gpg --list-keys
pub   4096R/BBBBB39F 2017-03-09
uid                  Someone Somebody <someone@somewhere.com>
sub   4096R/129E9336 2017-03-09

(what btw, is the SUB thing there?)

2) aptly publish... This prompts me for my passphrase for said key, so it must be doing something with the key at that point.

3) export the key using gpg —export —armor > somefile.pubkey

4) copy some file.pubkey over to a test machine

5) run sudo apt-key add somefile.pubkey

sudo apt-key list
pub   rsa4096 2017-03-09 [SC]
     E51B E216 4658 FB8B 6E42  8A09 F9BC EF4C BBBB B39F
uid           [ unknown] Someone Somebody <someone@somewhere.com>
sub   rsa4096 2017-03-09 [E]

So, it seems to have gotten in there. The sub thing shows up differently now?

6) And finally, sudo apt-get update:

~$ sudo apt-get update
Hit:1 http://ftp.us.debian.org/debian stretch InRelease
Hit:2 http://ftp.us.debian.org/debian stretch-updates InRelease     
Hit:3 http://security.debian.org stretch/updates InRelease          
Get:4 http://our.aptly.repo stretch InRelease [2317 B]
Ign:4 http://our.aptly.repo stretch InRelease            
Fetched 2317 B in 9s (256 B/s)                                                 
Reading package lists... Done
W: GPG error: http://our.aptly.repo stretch InRelease: The following signatures were invalid: E51BE2164658FB8B6E428A09F9BCEF4CBBBBB39F
W: The repository 'http://our.aptly.repo stretch InRelease' is not signed.
N: Data from such a repository can't be authenticated and is therefore potentially dangerous to use.
N: See apt-secure(8) manpage for repository creation and user configuration details.

I don’t understand what’s happening here. The offense seems to be that something is not signed? What step did I miss?


An up-to-date Debian stretch install no longer accepts SHA1 signatures. However, Aptly used SHA1 until v0.9.7 (relevant PR, note that it was also backported to v0.9.6.1). I suspect the version of Aptly you're using is older than that. If so, consider adding their repo to your sources.list.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.