TW
@textshell yes, put is also a problem. :| and we can not ignore non-manifest puts as we are defending against an evil client here. it could just put bad replacement...
Still don't get how one would defend against a low-level crap-chunk-putting client while being able to run delete or prune now and then (see first post).
@MK-42 yes, that's correct. repo commits do not have timestamps, so we can't consider time.
@tpo the repo checker would have the purpose of not switching to non-append-only (nao) mode if there is something weird in the repo. But it doesn't help much if it...
Thought experiment: In any mode, `Repository` (and thus also `RemoteRepository`) would have a different behaviour than before (incompatible, thus this would be in borg2 only): - any PUT to id...
@textshell @enkore @elho ^
manifest entries (incl. archive timestamps) are generated clientside and are not readable by the server, because they are encrypted.
https://github.com/borgbackup/borg/issues/1772#issuecomment-1262850865 my recent ideas still leave some problems unresolved: A malicious client could spam the repo with lots of "good looking", but fake and useless archives, making it hard for...
Theoretically, that would be possible to implement. But not sure whether it would be worth it - storage is often cheap and recompressing a whole repo takes quite some time....
A related not-yet-implemented feature would be to keep compression dicts between different chunks and not start from scratch each time. Guess if subsequent chunks are from same file / file...