[technion]

The hypothetical I want to pose people is, let's say your server is corrupted or I.pacted by ransomware. So you pull your gpg backups and hit restore. The data somehow looks correct and in line with expectations, but the signature fails to verify.

You can say 'well I know there was tampering, or possible one bit of bitrot' but then what? Let's say my backup was a poatgresql backup that restored correctly and had no obvious issues.

People often state backups mist be signed but just not sure how you would even respond. You cannot just not use the backup if all your backups are the same and you just had an incident. You could say "now we don't trust the data" but again what is meaningful action here?

Is it really a plausible threat that an attacker wiped put production, gained access to your backup infrastructure, but instead of just wiping it in order to force you to pay a ransom they took a new backup and quietly modified it? Surely such a person would just modify production if they wanted such a game.

[chlorion]

For me, it's about uploading files to the "cloud" such as Google Drive or Github and wanting to make sure that the data I uploaded is the same data that I am getting back. If the signatures fail I could unpack the file and manually review them to see what's up.

In your case, I think the problem is having backups that are attackable from production, and likely only having one set of backups.

>You cannot just not use the backup

What would you do if instead of tampering with the backups or production they just deleted everything outright?

[akerl_]

If I pulled a backup and it looked like it had been tampered with, I wouldn’t use the backup. Using a medium that protects against bit rot for backups, and testing the backups often enough to notice if they’ve been tampered with or malformed, are both key tenets of production systems.

[waynesonfire]

Huh? What's your concern? Yeah there was tempering, good idea you signed. Maybe go freeze your credit? I don't know, you tell me?