Vdirsyncer in its current state has been working for me reliable for quite some time now, and I’m very happy how this has shaped up.
Since the last status update, a lot of polishing has happened, and I’ve completed support for failure scenarios that could lead to data corruption.
Code that writes data into a vdir no uses atomic writes. Data is first written
to a new, temporary, file, and then that file is linked to the appropriate path.
If a catastrophic failure happens mid-way (e.g.: a power failure), then the file
with either remain in its original state, or in its final state, but it will
never end up with half of the data written and half missing.
Right now, the main “protections” that are missing are to avoid deleting all items when a collection is fully emptied on one side and disable deletion of deleted collections. During everyday usage, none of these should be relevant, but if you ever delete a calendar entirely with the expectation that “vdirsyncer will just download it again”, the current result might not be what you expect. Personally, I often create short-term todo lists which I later delete, so I collection auto-deletion has been convenient for me.
davcli now supports communicating with a server with a username and no
password, or with no authentication at all.
I’ve dropped support for “item properties” in the storage abstractions. The intent for these was to eventually support synchronising emails. The subtle differences between emails and calendars has led me to conclude that this is a bad idea. Mailboxes don’t have properties, but emails do. However, calendars have properties, and events do not. Additionally, emails are immutable, whereas events are mutable. Having a single sync algorithm that supports both adds unwanted complexity, and a unsatisfactory implementation for both.
I have also implemented a simple readiness notification mechanism, so that a service manger knows when vdirsyncer has transitioned from “starting up” to “running”. Once it has reached its running state it should not exit and will continuously (try to) synchronise periodically.
Finally, I’ve tagged a 0.1.0 release of ab-tidy, the little helper which renames vcard files to match the name of the person inside. I have a few other tiny tool in mind that I’d like to implement in the near future.
Security audit
The grant provided by NLNet and NGI Zero also includes a security audit of vdirsyncer.
During our initial discussion of scope and expectations, I realised that service
discovery assumes that your local DNS resolver is a validating one. In cases
where the local resolver is not a validating one, vdirsyncer is vulnerable to an
active MITM attack via DNS spoofing. I have since included a clear explanation
of this expectation in a SECURITY.md file which will eventually become part of
the documentation. I have also included a mention of this in libdav API
documentation in and in davcli’s readme.
Aside from this, the security audit has found another interesting issue which
has now been addressed: Files created in a vdir were created with the
executable bit set. It’s hard to imagine how this could be exploited in
practice, but it’s still a valid bug, and has since been fixed.