Annotation of src/usr.bin/rsync/TODO.md, Revision 1.5
1.1 benno 1: This is a list of possible work projects within openrsync, rated by difficulty.
2:
3: First, porting: see
4: [Porting](https://github.com/kristapsdz/openrsync/blob/master/README.md#Portability)
5: for information on this topic.
6: I've included the specific security porting topics below.
7:
8: This list also does not include adding support for features (e.g., **-u** and
1.4 benno 9: so on). The **-a** feature is probably most important, and involves a little
10: legwork in the protocol getting **-g** and **-u** passing around file modes.
11: I would rate this as easy/medium.
1.1 benno 12:
1.3 benno 13: - Easy: speed up the uid/gid mapping/remapping with a simple table.
14: Right now, the code in
15: [ids.c](https://github.com/kristapsdz/openrsync/blob/master/ids.c)
16: is simple, but could easily bottleneck with a large number of groups
17: and files with **-g**.
18:
1.2 benno 19: - Easy: add a hashtable to `blk_find()` in
1.1 benno 20: [blocks.c](https://github.com/kristapsdz/openrsync/blob/master/blocks.c)
21: for quickly looking up fast-hash matches.
22:
23: - Easy: print more statistics, such as transfer times and rates.
24:
1.2 benno 25: - Easy: tighten the [pledge(2)](https://man.openbsd.org/pledge.2) and
1.1 benno 26: [unveil(2)](https://man.openbsd.org/unveil.2) to work with **-n**, as
27: it does not touch files.
28:
29: - Easy: find the shared path for all input files and
30: [unveil(2)](https://man.openbsd.org/unveil.2) only the shared path
31: instead of each one.
32:
33: - Medium: have the log messages when multiplex writing (server mode) is
34: enabled by flushed out through the multiplex channel.
35: Right now, they're emitted on `stderr` just like with the client.
36:
37: - Medium: porting the security precautions
38: ([unveil(2)](https://man.openbsd.org/unveil.2),
39: [pledge(2)](https://man.openbsd.org/pledge.2)) to
40: [FreeBSD](https://www.freebsd.org)'s
41: [Capsicum](https://wiki.freebsd.org/Capsicum).
42: Without this in place, you're exposing your file-system to whatever is
43: coming down over the wire.
44: This is certainly possible, as openrsync makes exclusive use of the "at"
45: functions (e.g., [openat(2)](https://man.openbsd.org/openat.2)) for working
46: with files.
47:
48: - Hard: the same, but for Linux.
1.4 benno 49:
50: - Hard: once the sender loop is optimised, the uploader can also queue
51: up block metadata to send on-demand instead of reading in the file
52: then sending, then reading again, then sending.
53:
54: In general, be careful with the last two.
55: The rsync protocol is quite brittle and prone to deadlocking if senders
56: or receivers send too much data and clog output buffers.
57: So I suppose the hardest point, now that the protocol has been
58: documented, is:
59:
60: - Hardest: make the entire system use a event-loop and loop over
61: buffered data with a fine-grained state machine.
62:
63: I guess that will wait for openrsync v2.
1.1 benno 64:
65: Above all, `grep FIXME *.c *.h` and start from there.