rest-server

ammered by malicious traffic. Been using this for about five years, it saved my bacon a few times, no problems so far.

same day as your phone crashes. Rsync is simpler if you don't need features like encryption (at least to get started: any backup mechanism today is better than a perfect backup mechanism tomorrow).

log, but it's a big feature. S3 docs: > Object Lock can help prevent objects from being deleted or overwritten for a fixed amount of time or indefinitely. i.e. ransomware protection. Good luck wiping backups if your file hoster refuses to overwrite or delete the files. And you know Amazon didn't mess with the files because they're authenticated. Extortion is still a thing, but if people would use this, it more-or-less wipes out the attack vector of ransomware. The only risk is if the attacker is in your systems long enough to outlast your retention period and creates useless backups in the meantime so you're not tipped off. Did anyone say "test your backups"? For self-hosting, restic has a custom back-end called rest-server[2] which supports a so-called "append-only mode" (no overwriting or deleting). I worked on the docs for this[3] together with rawtaz and MichaelEischer to make this more secure, because eventually, of course, your disks are full or you want to stop paying for outdated snapshots on S3, and an attacker could have added dummy backups to fool your automatic removal script into thinking it needs to leave only the dummy backups. Using the right retention options, this attack cannot happen. Others are doing some pretty cool stuff in the backup sphere as well, e.g. bupstash[4] has public key encryption so you don't need to have the decryption keys as a backup client. [1] https://github.com/restic/restic/releases/v0.13.0 [2] https://github.com/restic/rest-server/ [3] https://restic.readthedocs.io/en/latest/060_forget.html#secu... [4] https://github.com/andrewchambers/bupstash/

I saw a it pull from a ton of domains, but also a lot form GitHub (many different authors). That's the crux: I may trust github itself and the author of this one repository (in this case, the author is actually a friend of a friend, in other cases it might just be a well-known person like cperciva or sircmpwn), and if my OS is compromised then I'm screwed anyway so the repositories are also considered mostly trusted, but I don't for a minute believe that the author of the code I'm trying to build managed to vet the 600 repositories it's pulling. Also, six hundred repositories. All this thing does is spawn an http server and handle a few API calls, acting as a dummy storage server (implementing things like 'get me this file' or 'put this file here'). > Go programs absolutely don't run arbitrary code at compile/install time I didn't actually know that, that's nice. I mean, still if I can't trust the binary then it's of little use to me personally, but any malicious code would presumably have to be called into and build servers will have an easier time serving binaries, so that's a good thing.