mirror of
https://github.com/ostreedev/ostree.git
synced 2025-01-10 05:18:30 +03:00
40 lines
1.6 KiB
Plaintext
40 lines
1.6 KiB
Plaintext
* 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
|
|
|
|
* 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.
|