Return to TODO.md CVS log

Up to [local] / src / usr.bin / rsync

Annotation of src/usr.bin/rsync/TODO.md, Revision 1.4

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: make the sender loop use an event handler on incoming and
        !            51:   outgoing I/O.  Right now it moves in lockstep and can be considerably
        !            52:   more responsive to requests by reading them in immediately instead of
        !            53:   having them sit in the receiver queue while it waits for disc IO.
        !            54:   This isn't *that* hard.
        !            55:
        !            56: - Hard: once the sender loop is optimised, the uploader can also queue
        !            57:   up block metadata to send on-demand instead of reading in the file
        !            58:   then sending, then reading again, then sending.
        !            59:
        !            60: In general, be careful with the last two.
        !            61: The rsync protocol is quite brittle and prone to deadlocking if senders
        !            62: or receivers send too much data and clog output buffers.
        !            63: So I suppose the hardest point, now that the protocol has been
        !            64: documented, is:
        !            65:
        !            66: - Hardest: make the entire system use a event-loop and loop over
        !            67:   buffered data with a fine-grained state machine.
        !            68:
        !            69: I guess that will wait for openrsync v2.
1.1       benno      70:
                     71: Above all, `grep FIXME *.c *.h` and start from there.