Security policy

Report a vulnerability using GitHub’s private vulnerability reporting (the “Report a vulnerability” button on the Security tab), rather than a public issue.

Supported versions

Security fixes target the latest release. There’s no long-term support branch.

Dependencies

Install lists what calendaring-sync and each of its extras depend on, and pyproject.toml gives the versions.

Known risks and design notes

What the store keeps

A store keeps the content of every synced object, and your edits to it, as they are. Calendar data holds personal information, such as names, places and what a meeting is about. Each scope’s id is in the store too, and an adapter’s default scope id holds the server’s address, without a login. The library never stores a password or another credential: those stay with the client you give the adapter. SQLiteStore doesn’t encrypt its file, so give it the permissions you give the calendar data itself, such as chmod 600.

Data from the server

The core never parses content: it stores and compares the bytes a server sent. The adapters that ship with calendaring-sync read what they need from it with their protocol’s parsers. The CalDAV adapter reads iCalendar content lines with icalendar, and the JMAP adapter reads JSON with the standard library. The CalDAV adapter parses a server’s XML error body with lxml, with entity expansion and network access turned off, so a hostile server can’t make it read local files or fetch other addresses.

Connections and credentials

calendaring-sync opens no connection of its own: the client library you give an adapter makes every request, with its own certificate checks and login. Point it at a server you trust, over HTTPS, as the client library’s documentation describes.

Stores you write yourself

MemoryStore’s description shows a store that saves its data with pickle. Loading a pickle runs code, so load such a file only if your application wrote it and no one else can change it.