Hello, I've implemented some changes, most notably initial support for restores. I haven't updated the README yet.
The CLI is still subject of change, I believe it should be refactored. I am tracking many ideas in Github issues. There are two notable groups: * Help-wanted (currently two issues): https://github.com/v6ak/qubes-incremental-backup-poc/labels/help%20wanted * [WIP] Goals – long-term meta-tasks that show visions. They will link related issues. https://github.com/v6ak/qubes-incremental-backup-poc/labels/goal Now, I will respond to some comments: Ad leaking data to the attacker: Hmm, it is not in limitations, it is in goals. So, I'll have to rephrase it differently. But in goals, I definitely agree that it sounds weird. It sounds like it was a goal to leak the data, not to limit the leaks to something reasonable. Ad pruning old backups: Good point, I'll add it. AFAIK, this is always matter of some tradeoff. Ad Duplicati: I've taken a brief look at it. The backup design looks good. What I am somewhat worried about is encryption: By default, it uses AESCrypt format, which don't seem to be well-known. I am always skeptical when reading that something uses strong AES-256 encryption without further details – I tend to imaginate ECB or fixed-IV CTR without any authentication, maybe you know why… It is hard to find any details on AESCrypt, even the format description is not very verbose – it does not even mention mode of operation. I felt like reverse engineer when I finally found “CBC” in the source code. And I still don't know important details about authentication. I know there are two HMACs, but I don't know if it is mac-then-encrypt, mac-and-encrypt or encrypt-and-mac. Also, list of vulnerabilities (not very visible) does not suggest a good design: https://www.aescrypt.com/wishlist.html . And there is more to review, e.g. what implementation of AES is used and if it has any side channels. In general, I would like to avoid AESCrypt format at all. Duplicati can also use GPG. Sure, even GPG can be used wrongly (most obvious: allowing to interchange various backup files within one VM – not much practical if they are large blocks), but I feel better with GPG that with AESCrypt. Unfortunately, I see it only with use of asymmetric encryption, which is not what I would want – not only for encryption strength against quantum computers, but also for implementation hassle – this would probably require generating and storing some extra keypair per VM (barring the fact it would be rather pair of pairs – for authentication and encryption). But maybe Duplicati can be somehow convinced to use GPG with symmetric encryption. There is one more concern with Duplicati: How would we split it between BDVM (backup DVM) and BackupStorageVM? Is this possible without recompilation of the whole Duplicati? In Duplicity, I add a backup backend to BDVM that forwards everything to another backend in BackupStorageVM. So, BDVM loads dynamically my backend and qrexec handler in BackupStorageVM loads the desired Duplicity backend. I am almost sure this is somehow possible with Duplicati, but I am unsure about the effort required for this. Do you have any ideas about mentioned implementation concerns related do Dupicati? A side note on potential backup-block-level malleability: Not only this is a minor concern today, it should become non-concern when Merkle-tree-based whole-backup authentication is implemented. On BTRFS/ZFS/LVM I don't know much about differences between them when used as pools for block devices. You might have a point, but discuss it in a separate thread, please. A note relevant for backup: It should be easy to add support for ZFS/BTRFS, I believe. You can see the current implementation for LVM: https://github.com/v6ak/qubes-incremental-backup-poc/blob/f9291b3fbec459cbc2f44279f7a31a3613a49811/qubesvmtools.py#L29-L38L86-L109 https://github.com/v6ak/qubes-incremental-backup-poc/blob/f9291b3fbec459cbc2f44279f7a31a3613a49811/qubesvmtools.py#L29-L38L86-L109 Regards, Vít Šesták 'v6ak' -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/129210a1-6f11-4182-9d07-e79936424f8d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
