Sebastian Lackner
Sebastian Lackner
Since trailing garbage will be ignored, it will still be pretty difficult to interact with the program, even when using a pipe. A programmer would have to add some artificial...
Using `-extpass` to show a fancy GUI popup would work, but a lot of other things are quite difficult to achieve with the current design. * When using a pass...
On 15.11.2017 16:56, rfjakob wrote: > With the "iv database",we would have to store checksums of all blocks of all files. This seems to be pretty heavyweight to me. Not...
I agree that it is difficult to get this implemented correctly and to get it fast. Nevertheless, in my specific use-case neither performance nor storage space is the critical factor....
On 18.11.2017 17:17, rfjakob wrote: > Oh, you have a prototype already, nice! While I was not very motivated of implementing this myself, I'll not decline a pull request for...
> If I read https://tools.ietf.org/html/rfc5297#section-2.6 correctly, the MAC is in the first 16 bytes of the ciphertext in AES-SIV. Thats correct, but gocryptfs also adds the IV, so the MAC...
As you might have already noticed (see the commit above), in the meantime I have switched to an extended attribute based approach. There are no longer completely random block IVs,...
I don't think that would be better. In fact, it would make it even easier for an attacker to mess with a backup, when all hardlinked files use the same...
What also would be an option: Drop the whole `inodeTable` logic, and instead generate unique inode numbers. Then the content is transferred multiple times, but at least it is fully...
While this might be a valid issue (I also encountered this bug and am currently using some ugly workarounds :grimacing:), the problem has nothing to do with `fastapi`. Schema generation...