Obnam issueshttps://gitlab.com/obnam/obnam/-/issues2023-11-28T20:29:37Zhttps://gitlab.com/obnam/obnam/-/issues/214Treat server storage (or even server API) as oblivious RAM2023-11-28T20:29:37ZAlexander Batischeveual.jp@gmail.comTreat server storage (or even server API) as oblivious RAMI believe I voiced similar ideas here somewhere, but I can't find it now. This is also outside of the current threat model, so maybe put it at the very end of the backlog :smile:
In short, the server operator can tell which chunks are ...I believe I voiced similar ideas here somewhere, but I can't find it now. This is also outside of the current threat model, so maybe put it at the very end of the backlog :smile:
In short, the server operator can tell which chunks are part of the current live data, because that's the ones that the client requests every time it makes a backup. They might use this meta-data for something. I just stumbled upon a theoretical solution for this — https://en.wikipedia.org/wiki/Oblivious_RAM. The task there is to make the storage (RAM) oblivious to the access patterns of the original program; this is achieved by various schemes that hide/obfuscate the pattern by turning it into a different pattern.https://gitlab.com/obnam/obnam/-/issues/213Needs mini-benchmarks for different aspects2022-10-05T07:25:59ZLars WirzeniusNeeds mini-benchmarks for different aspectsWe have a benchmark suite for the Obnam system as whole. This is great. It is, however, too coarse for doing benchmarks of smaller aspects, such as "how fast is the server at chunk lookups".
It would be great to have smaller benchmarks...We have a benchmark suite for the Obnam system as whole. This is great. It is, however, too coarse for doing benchmarks of smaller aspects, such as "how fast is the server at chunk lookups".
It would be great to have smaller benchmarks for that.https://gitlab.com/obnam/obnam/-/issues/212Shouldn't treat recreated CACHEDIR.TAG files as new2022-07-14T17:46:34ZAlexander Batischeveual.jp@gmail.comShouldn't treat recreated CACHEDIR.TAG files as new```
$ obnam --version
obnam-backup 0.7.1
```
Here's what I see at the end of a backup from time to time:
```
New CACHEDIR.TAG files since the last backup:
- "/home/minoru/src/newsboat/target/CACHEDIR.TAG"
You can configure Obnam to ign...```
$ obnam --version
obnam-backup 0.7.1
```
Here's what I see at the end of a backup from time to time:
```
New CACHEDIR.TAG files since the last backup:
- "/home/minoru/src/newsboat/target/CACHEDIR.TAG"
You can configure Obnam to ignore all such files by setting `exclude_cache_tag_directories` to `false`.
status: OK
warnings: 0
duration: 419
file-count: 338532
generation-id: 87eb7c87-b3b9-467a-b316-00cf1ee1310a
ERROR: found CACHEDIR.TAG files that aren't present in the previous backup, might be an attack
```
The error occurs because I run `cargo clean && cargo build`, which creates a new CACHEDIR.TAG. Obnam notices this and complains.
I think Obnam has to understand that all CACHEDIR.TAGs are equivalent, and complain only when a tag is created where it didn't exist before (including a situation where a *file* existed but had wrong contents).https://gitlab.com/obnam/obnam/-/issues/210Stores file metadata wastefully2022-05-03T06:20:43ZLars WirzeniusStores file metadata wastefullyFor any given backup, most of the metadata for each file is likely to be the same, but we store them separately for each file system entry.
Of the metadata we store, the following is likely to be duplicated among many files:
```rust
...For any given backup, most of the metadata for each file is likely to be the same, but we store them separately for each file system entry.
Of the metadata we store, the following is likely to be duplicated among many files:
```rust
kind: FilesystemKind,
mode: u32,
uid: u32,
gid: u32,
user: String,
group: String,
```
We could have a new table, `common_file_metadata`, where we store every unique set of metadata listed above, and then store a row number into the common table for each file, as well as any metadata not in the common table.
This might let us make the size of the generation SQLite database smaller. Needs experimenting.https://gitlab.com/obnam/obnam/-/issues/205Server should use new database abstraction2022-04-17T07:16:00ZLars WirzeniusServer should use new database abstraction`src/db.rs` should fit what the server does.`src/db.rs` should fit what the server does.https://gitlab.com/obnam/obnam/-/issues/204Should allow restricting what a client can do2022-04-05T04:46:39ZLars WirzeniusShould allow restricting what a client can doAs a user of Obnam, I would like to restrict what a client can do so that, for example, if an attacker gets access to my laptop, they can only make new backups, but not restore backups, and not delete backups.As a user of Obnam, I would like to restrict what a client can do so that, for example, if an attacker gets access to my laptop, they can only make new backups, but not restore backups, and not delete backups.https://gitlab.com/obnam/obnam/-/issues/201Lacks support for translations2022-03-28T07:38:12ZLars WirzeniusLacks support for translationsIt'd be good to have at least basic support for i18n and l10n in Obnam.It'd be good to have at least basic support for i18n and l10n in Obnam.https://gitlab.com/obnam/obnam/-/issues/199Server API or database changes require starting over with an empty repository2022-04-17T07:16:01ZLars WirzeniusServer API or database changes require starting over with an empty repositoryThis MUST be fixed so that Obnam can evolve without forcing users to start over with their backups.
There are two aspects here: the HTTP API (both client and server need to support multiple versions), and the server database (server nee...This MUST be fixed so that Obnam can evolve without forcing users to start over with their backups.
There are two aspects here: the HTTP API (both client and server need to support multiple versions), and the server database (server needs to handle schema changes).https://gitlab.com/obnam/obnam/-/issues/198Doesn't handle ext2/3/4 specific file metadata2022-03-13T09:51:09ZLars WirzeniusDoesn't handle ext2/3/4 specific file metadataFor example, the immutable flag.For example, the immutable flag.https://gitlab.com/obnam/obnam/-/issues/197Doesn't handle extended attributes2022-03-13T09:49:47ZLars WirzeniusDoesn't handle extended attributesObnam neither stores, nor restores file extended attributes. It should.Obnam neither stores, nor restores file extended attributes. It should.https://gitlab.com/obnam/obnam/-/issues/196Doesn't handle Posix ACL2022-03-13T09:47:58ZLars WirzeniusDoesn't handle Posix ACLObnam neither stores, nor restores Posix access control lists (ACL). It should.Obnam neither stores, nor restores Posix access control lists (ACL). It should.https://gitlab.com/obnam/obnam/-/issues/195Doesn't handle sparse files efficiently2022-03-20T09:52:53ZLars WirzeniusDoesn't handle sparse files efficientlyObnam doesn't backup or restore sparse files well. It should store holes as holes, not blocks of zeroes, and restore holes by using seek, not by writing zeroes.
Sparse files are common for, say, virtual machine images, and are sufficien...Obnam doesn't backup or restore sparse files well. It should store holes as holes, not blocks of zeroes, and restore holes by using seek, not by writing zeroes.
Sparse files are common for, say, virtual machine images, and are sufficiently common that Obnam should handle them well.https://gitlab.com/obnam/obnam/-/issues/193Stores chunkids in text format2022-03-06T08:05:09ZLars WirzeniusStores chunkids in text formatThey're UUIDs, and could be stored in half the space by using binary.They're UUIDs, and could be stored in half the space by using binary.https://gitlab.com/obnam/obnam/-/issues/191Doesn't backup/restore file capabilities2022-02-14T11:21:38ZLars WirzeniusDoesn't backup/restore file capabilitieshttps://gitlab.com/obnam/obnam/-/issues/189File system iteration and filtering is complicated2022-02-06T13:24:31ZLars WirzeniusFile system iteration and filtering is complicatedWe use the `walkdir` crate to iterate over the file system, but we hide it behind our own abstraction, `FsIter`. We then add some filtering support filtering cache directories. The result is a bit complicated and the logic of how filteri...We use the `walkdir` crate to iterate over the file system, but we hide it behind our own abstraction, `FsIter`. We then add some filtering support filtering cache directories. The result is a bit complicated and the logic of how filtering decisions are made is a little hard to follow, at least for me.
I think a tidier approach would be to drop `FsIter` and use `walkdir` directly, and use its `FilterEntry` to do the filtering. This way, the caller sees a more common iterator in use. Something like:
```rust
for entry in WalkDir::new(&root)
.into_iter()
.filter_entry(|e| !unwanted(e))
{
let entry = entry?;
println!("{}", entry.path().display());
}
fn unwanted(e: &DirEntry) -> bool {
e.file_name() == ".git"
}
```
Opinions?https://gitlab.com/obnam/obnam/-/issues/186No authentication in server HTTP API2022-09-28T08:48:56ZLars WirzeniusNo authentication in server HTTP APIThe server needs some kind of access control on its HTTP API. At minimum, simple access tokens that allows only one client to use the API. Later on, a more nuanced, more fine grained access control mechanism that supports many, mutually ...The server needs some kind of access control on its HTTP API. At minimum, simple access tokens that allows only one client to use the API. Later on, a more nuanced, more fine grained access control mechanism that supports many, mutually distrustful clients/users will be added, but a simple mechanism would be enough to get us started.https://gitlab.com/obnam/obnam/-/issues/180Chunk metadata should be in AAD, not in headers?2023-03-17T15:18:25ZLars WirzeniusChunk metadata should be in AAD, not in headers?We use AEAD for encrypting chunks, and the additional associated cleartext data would be the perfect place to store the chunk's metadata. Wouldn't it?We use AEAD for encrypting chunks, and the additional associated cleartext data would be the perfect place to store the chunk's metadata. Wouldn't it?Iteration ending 2022-01-23https://gitlab.com/obnam/obnam/-/issues/176Doesn't report version with much detail2023-03-17T15:18:32ZLars WirzeniusDoesn't report version with much detailSomething like git-testament would give more detail than Obnam currently has. This would be useful for obnam-benchmark to report.Something like git-testament would give more detail than Obnam currently has. This would be useful for obnam-benchmark to report.Iteration ending 2022-01-23https://gitlab.com/obnam/obnam/-/issues/175All in one crate2022-01-07T08:46:41ZLars WirzeniusAll in one crateObnam is currently a single crate. Would it make sense to split it? And maybe to add helper crates? Possible crates:
* client
* server
* any code shared between client and server
* summain, which mainly exists for testing Obnam
* obnam-...Obnam is currently a single crate. Would it make sense to split it? And maybe to add helper crates? Possible crates:
* client
* server
* any code shared between client and server
* summain, which mainly exists for testing Obnam
* obnam-benchmarkhttps://gitlab.com/obnam/obnam/-/issues/153Depends on vulnerable chrono2022-03-13T08:32:49ZLars WirzeniusDepends on vulnerable chronohttps://rustsec.org/advisories/RUSTSEC-2020-0159
https://github.com/chronotope/chrono/issues/499https://rustsec.org/advisories/RUSTSEC-2020-0159
https://github.com/chronotope/chrono/issues/499