View Issue Details

IDProjectCategoryView StatusLast Update
0001263bareos-coreinstaller / packagespublic2023-11-27 10:21
Reportersiegmarb Assigned Toarogge  
Status closedResolutionfixed 
PlatformLinuxOSUbuntuOS Version16.04
Product Version18.2.9 
Summary0001263: please provide gpg repo key in v4 format
Descriptioncurrent repo key is
Release.key: PGP public key block Public-Key (old)

so Debian/Ubuntu reports:

The key(s) in the keyring /etc/apt/trusted.gpg.d/..... are ignored as the file has an unsupported filetype.

please provide the key in new format, so it can just be dropped on Debian/Ubuntu systems in

Howto do:

Import key once locally:
gpg --import Release.key
export again:
gpg --output bareos.gpg --export 118283D9A7862CEE

file hwraid.gpg

bareos.gpg: GPG key public ring, created Tue Jan 15 14:47:51 2019

Upload to ftp/http.

thank you :)
TagsNo tags attached.




2020-08-04 09:52

manager   ~0004029

Sounds reasonable.
I'll have to add that to the automated repository generation process, so it might not be as easy as you think, but I'll see what I can do.


2020-12-16 15:36

manager   ~0004070

right now, we're creating the Release.key with "--export --armor --output Release.key", so I guess you just need the key without the ASCII-armor.
I can add another export using "--export --output Release.gpg", but I wonder how we should name the file.
Release.gpg doesn't really cut it, as context is lost when you drop it into /etc/apt/trusted.gpg.d/
Then we could probably do bareos.gpg, however, during upgrade or testing you may want to have multiple gpg keys installed at once (i.e. for the current version and the version you're upgrading to).

Does it make sense to have files like "bareos-<keyid>.gpg"? Or should we just provide a bareos.gpg that contains all our keys (I don't think that is a great idea, because you would trust older keys, too)?

Any thoughts on this?


2023-10-24 09:21

manager   ~0005474

In the meantime we overhauled repository setup and now provide a script that does it.
Does your original issue still exist with the current repositories, or did we already fix your problem?


2023-11-27 10:21

manager   ~0005531

As there was no feedback, I guess this problem doesn't exist with the newer repository format anymore.

Issue History

Date Modified Username Field Change
2020-07-14 11:55 siegmarb New Issue
2020-08-04 09:52 arogge Assigned To => arogge
2020-08-04 09:52 arogge Status new => acknowledged
2020-08-04 09:52 arogge Note Added: 0004029
2020-12-16 15:36 arogge Note Added: 0004070
2020-12-16 15:36 arogge Status acknowledged => feedback
2023-10-24 09:21 arogge Note Added: 0005474
2023-11-27 10:21 arogge Status feedback => resolved
2023-11-27 10:21 arogge Resolution open => fixed
2023-11-27 10:21 arogge Note Added: 0005531
2023-11-27 10:21 arogge Status resolved => closed