blob: e1581f2e53473b98e5b3efac976b152a68e699ab (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
|
* Documentation
* Rethink commit objects
- Drop the a{sv} per https://bugzilla.gnome.org/show_bug.cgi?id=673012
- Do we need freeform subject/body? Or should it just be a generic
key-value store?
- Optional non-object metadata; e.g., "detached" GPG signatures which
are in the same file (to avoid double HTTP requests)
- Extended validation; SHA512+SHA256 checksum of all metadata along
with content object metadata (file size in particular) wouldn't take
too much extra time per commit, and would greatly strengthen resistance
to active hash collision attacks.
* Hybrid SSL pull (fetch refs over SSL, content via plain HTTP)
* ostree-commit: multithreaded/async (basically compute sha256 in parallel)
- Also speed up devino cache by having a big mmappable file that maps from
(device, inode) -> checksum. We need to keep the cache up to to date;
investigate something like http://www.sqlite.org/wal.html for having
a shared file.
* Indexed metadata pack objects for bare repositories at least;
no reason to inflict thousands of little metadata files on
each client.
* Efficient delta format between commit objects, somewhat like
Chromium autoupdate: set of operations to perform given previous
object set to create new objects.
* Tests of corrupted repositories, more error conditions
* Structured output from commandline? ostree --output={table,gvariant} ?
* Better output on a tty - progress bars
* Improve library
* ostree admin install: Pull in host data, such as uids and /etc/fstab
* ostree admin undeploy <osname> <tree>
* ostree admin uninstall <osname>
* Possibly move all of the "regular" commands to be "ostree repo" ? Then
we'd have: "ostree repo pull", "ostree repo ls", etc.
|
