View Issue Details

IDProjectCategoryView StatusLast Update
0001447bareos-corefile daemonpublic2023-03-07 12:09
Reportermdc Assigned Tobruno-at-bareos  
Status resolvedResolutionwon't fix 
Platformx86_64OSCentOSOS Versionstream 8
Product Version21.1.2 
Summary0001447: Restore of unencrypted files on an encrypted fd thrown an error, bur works.
DescriptionWhen restore files from an client that stores the files unencrypted on an client that normally only runs encrypted backups, the restore will work, but an error is thrown.
Steps To ReproduceSample config:
Client A:
Client {
PKI Signatures = Yes
PKI Encryption = Yes
PKI Cipher = aes256
PKI Master Key = ".../master.key"
PKI Keypair = ".../all.keys"
Client B:
Client {
# without the cryptor config

Both can do its' backup and restore for itself to the storage. But when an restore is done, with files from client B on client A, then the files are restored as request, but for every file an error is logged:
clienta JobId 72: Error: filed/ Missing cryptographic signature for /var/tmp/bareos/var/log/journal/e882cedd07af40b386b29cfa9c88466f/user-70255@bdb4fa2d506c45ba8f8163f7e4ee7dac-0000000000b6f8c1-0005d99dd2d23d5a.journal
and the hole job is marked as failed.
Additional InformationBecause the restore itself works, I think the job should only marked as "OK with warnings" and the "Missing cryptographic signature ..." only as an warning instant of an error.
TagsNo tags attached.




2023-03-07 12:09

manager   ~0004902

Thanks you for your report. In a bug triage session, we came to the following conclusion for this case.
We understand completely the case, and agree it should be better handled by the code.

The workaround is to change your configuration as with the parameter PKI Signatures = Yes you are requesting the fact that normally you care about the signature for all data, so the job got its failing status. If you need to restore unencrypted data to that client, you should during the restore time to comment out that parameter.

On our side, nobody will work on that improvement, but feel free to propose a fix in a PR on github.

Issue History

Date Modified Username Field Change
2022-04-06 14:12 mdc New Issue
2023-03-07 12:09 bruno-at-bareos Note Added: 0004902
2023-03-07 12:09 bruno-at-bareos Assigned To => bruno-at-bareos
2023-03-07 12:09 bruno-at-bareos Status new => resolved
2023-03-07 12:09 bruno-at-bareos Resolution open => won't fix