kayg commented

Owner

Owner (2026-09-28, production, after the discovery fixes f47399ad/80fa1fed): the CalDAV account now adds on macOS, but no events show, and Calendar shows 'Your calendar couldn't be created. The calendar "Calendar" could not be created on the server because of an unexpected error. The calendar was not found on the server.' Owner: 'man this needs to be tested by you!' (a macOS VM is coming).

Edge log of the Mac session (09:04 UTC, client 49.205.172.130):

PROPFIND /.well-known/caldav                     308
OPTIONS  /dav/principals/<id>/                   204
PROPFIND /dav/                                   207 (570 B)
PROPFIND /dav/principals/<id>/                   207 (617 B) ×3
MKCALENDAR /dav/calendars/<id>/BE108CEB-…/        404
PROPFIND /dav/calendars/<id>/                    207 (2260 B)

No REPORT/calendar-query ever follows. Diagnosis (orchestrator, from crates/calternal-dav/src/protocol.rs prop_response): collections return a fixed prop set (resourcetype, current-user-principal, calendar-home-set, displayname, ctag/sync-token) regardless of what was asked. Missing for Apple: DAV:current-user-privilege-set (so Calendar cannot see that Journal is writable), C:supported-calendar-component-set VEVENT on Journal, DAV:supported-report-set (calendar-query, calendar-multiget, sync-collection), DAV:owner, C:calendar-user-address-set on the principal, ICAL:calendar-color/calendar-order (nice to have), and proper 404 propstat for unknown props (RFC 4918 §9.1). With no writable VEVENT calendar, macOS creates a default one via MKCALENDAR, and the 404 aborts the account.

Fix and PROVE it (the priority is interop, not guesses):

Build an Apple request replay test: capture-equivalent PROPFIND/REPORT bodies that macOS dataaccessd and iOS send (use Apple's open-source CalendarServer test fixtures, the ccs-caldavtester scripts, published captures and SabreDAV/Radicale/Baikal compatibility notes), and assert the full exchange: discovery → principal → home listing → the collections are recognised as writable VEVENT (Journal) and VTODO (Reminders) calendars → calendar-query/sync-collection returns events → PUT a new event → DELETE it.
Implement proper PROPFIND prop handling: answer requested props, 404-propstat unknown ones, and support allprop/propname. Add the missing props above, with privileges derived from the real authorization (read/write/write-content/bind/unbind only when the user may write).
MKCALENDAR: decide the behaviour. Proposal: respond 403 with a DAV:error precondition (DAV:resource-must-be-null-style or C:calendar-collection-location-ok) rather than 404, and make sure macOS never needs it (it will not, once Journal is recognised as a writable event calendar). Alternatively, support MKCALENDAR by mapping it to a tag-backed calendar only if the design allows it; this is not decided, so do not build it.
Run real clients against a local server in CI-able tests: python caldav (the caldav package), vdirsyncer/khal, and DAVx⁵'s documented request pattern; note Thunderbird's pattern too. Everything must pass: list calendars, see events in a date range, create/edit/delete an event, create a reminder, and incremental sync with a sync-token.
Extend tests/adversarial with the new props and MKCALENDAR.
Report exact before/after XML for the home listing.
The orchestrator will verify on a real macOS VM once the owner provides it; until then the replay test is the proof.

Owner (2026-09-28, production, after the discovery fixes f47399ad/80fa1fed): the CalDAV account now adds on macOS, but **no events show**, and Calendar shows 'Your calendar couldn't be created. The calendar "Calendar" could not be created on the server because of an unexpected error. The calendar was not found on the server.' Owner: 'man this needs to be tested by you!' (a macOS VM is coming). **Edge log of the Mac session (09:04 UTC, client 49.205.172.130):** ``` PROPFIND /.well-known/caldav 308 OPTIONS /dav/principals/<id>/ 204 PROPFIND /dav/ 207 (570 B) PROPFIND /dav/principals/<id>/ 207 (617 B) ×3 MKCALENDAR /dav/calendars/<id>/BE108CEB-…/ 404 PROPFIND /dav/calendars/<id>/ 207 (2260 B) ``` No REPORT/calendar-query ever follows. **Diagnosis (orchestrator, from crates/calternal-dav/src/protocol.rs prop_response):** collections return a fixed prop set (resourcetype, current-user-principal, calendar-home-set, displayname, ctag/sync-token) regardless of what was asked. Missing for Apple: `DAV:current-user-privilege-set` (so Calendar cannot see that Journal is writable), `C:supported-calendar-component-set` VEVENT on Journal, `DAV:supported-report-set` (calendar-query, calendar-multiget, sync-collection), `DAV:owner`, `C:calendar-user-address-set` on the principal, `ICAL:calendar-color`/`calendar-order` (nice to have), and proper **404 propstat for unknown props** (RFC 4918 §9.1). With no writable VEVENT calendar, macOS creates a default one via MKCALENDAR, and the 404 aborts the account. **Fix and PROVE it (the priority is interop, not guesses):** 1. **Build an Apple request replay test**: capture-equivalent PROPFIND/REPORT bodies that macOS dataaccessd and iOS send (use Apple's open-source CalendarServer test fixtures, the `ccs-caldavtester` scripts, published captures and SabreDAV/Radicale/Baikal compatibility notes), and assert the full exchange: discovery → principal → home listing → the collections are recognised as writable VEVENT (Journal) and VTODO (Reminders) calendars → calendar-query/sync-collection returns events → PUT a new event → DELETE it. 2. Implement proper PROPFIND prop handling: answer requested props, 404-propstat unknown ones, and support `allprop`/`propname`. Add the missing props above, with privileges derived from the real authorization (read/write/write-content/bind/unbind only when the user may write). 3. **MKCALENDAR**: decide the behaviour. Proposal: respond **403 with a DAV:error precondition** (`DAV:resource-must-be-null`-style or `C:calendar-collection-location-ok`) rather than 404, and make sure macOS never needs it (it will not, once Journal is recognised as a writable event calendar). Alternatively, support MKCALENDAR by mapping it to a tag-backed calendar only if the design allows it; this is not decided, so do not build it. 4. Run real clients against a local server in CI-able tests: **python caldav** (the `caldav` package), **vdirsyncer/khal**, and **DAVx⁵'s** documented request pattern; note Thunderbird's pattern too. Everything must pass: list calendars, see events in a date range, create/edit/delete an event, create a reminder, and incremental sync with a sync-token. 5. Extend tests/adversarial with the new props and MKCALENDAR. 6. Report exact before/after XML for the home listing. The orchestrator will verify on a real macOS VM once the owner provides it; until then the replay test is the proof.

kayg commented

2026-09-28 09:07:08 +00:00

Author

Owner

Starting work on job/caldav-apple.
Base dev SHA: 7bbaf5133c.

Starting work on job/caldav-apple. Base dev SHA: 7bbaf5133c00506deb0f421ef7a75f5f3c72b859.

kayg commented

2026-09-28 09:13:04 +00:00

Author

Owner

Finding from crates/calternal-dav/src/protocol.rs: both prop_response and reminders_prop_response return a fixed set of properties without parsing the requested property list. The Journal listing does not advertise supported-calendar-component-set; neither calendar collection advertises supported-report-set, owner, or current-user-privilege-set; the principal does not advertise calendar-user-address-set. The handlers do not produce a 404 propstat for unsupported requested properties. The existing REPORT paths already implement Journal calendar-query, calendar-multiget, sync-collection, and Reminders sync-collection, so I am testing those paths together with PUT/DELETE rather than replacing their data flow.

For request shape references I inspected Apple’s archived ccs-caldavtester scripts/tests/CalDAV/propfind.xml and sync-report.xml, plus its Resource/Common/PROPFIND/propnames.xml and supported-report-set.xml fixtures. I will add a compact replay test in this crate rather than importing the full external test suite.

Finding from `crates/calternal-dav/src/protocol.rs`: both `prop_response` and `reminders_prop_response` return a fixed set of properties without parsing the requested property list. The Journal listing does not advertise `supported-calendar-component-set`; neither calendar collection advertises `supported-report-set`, `owner`, or `current-user-privilege-set`; the principal does not advertise `calendar-user-address-set`. The handlers do not produce a 404 propstat for unsupported requested properties. The existing REPORT paths already implement Journal calendar-query, calendar-multiget, sync-collection, and Reminders sync-collection, so I am testing those paths together with PUT/DELETE rather than replacing their data flow. For request shape references I inspected Apple’s archived `ccs-caldavtester` `scripts/tests/CalDAV/propfind.xml` and `sync-report.xml`, plus its `Resource/Common/PROPFIND/propnames.xml` and `supported-report-set.xml` fixtures. I will add a compact replay test in this crate rather than importing the full external test suite.

kayg commented

2026-09-28 11:49:49 +00:00

Author

Owner

Forgejo #323 — CalDAV client compatibility

Change

The DAV layer now answers the property selectors used during Apple account discovery, including allprop, propname, and explicit prop. It advertises the fixed Journal VEVENT and Reminders VTODO projections, supported reports, ownership, privileges, and calendar user addresses. Unknown requested properties receive a 404 propstat. MKCALENDAR on the fixed home is refused with the DAV calendar-collection-location-ok precondition so Apple can continue discovery instead of treating the projection as a missing calendar.

The Rust request-replay integration test uses the production router and checks discovery, sync/query, event and task writes, deletes, selector handling, and fixed-projection denial. This matches the property and sync request shapes in Apple's CalDAVTester PROPFIND fixture and sync fixture, with collection behavior guided by RFC 4791.

Client runs against the branch-built local server

python-caldav 3.3.1: principal and calendar discovery succeeded. Journal query returned 0 VEVENT; Reminders query returned 0 VTODO.
vdirsyncer 0.21.0: discover calternal exited 0 and found Journal and Reminders; sync calternal exited 0 for both collections. Discovery configured the missing local Reminders collection, then sync completed. Client/config usage follows the vdirsyncer config manual and python-caldav collection docs.

The local fixture had no events or tasks, so the client queries were empty. The two Python clients exercised discovery and reads/initial sync; the Rust replay test exercised create/update/delete.

Home listing XML before and after

Both captures are authenticated Depth 1 allprop PROPFIND responses for the same local test account and fixture. Before is from base 7bbaf5133c00506deb0f421ef7a75f5f3c72b859; after is from this branch.

Before

<?xml version="1.0" ?>
<d:multistatus xmlns:d="DAV:" xmlns:c="urn:ietf:params:xml:ns:caldav">
  <d:response>
    <d:href>/dav/calendars/01a0e783-0275-7241-92d2-ce78e1896985/</d:href>
    <d:propstat>
      <d:prop>
        <d:resourcetype>
          <d:collection/>
        </d:resourcetype>
        <d:current-user-principal>
          <d:href>/dav/principals/01a0e783-0275-7241-92d2-ce78e1896985/</d:href>
        </d:current-user-principal>
        <c:calendar-home-set>
          <d:href>/dav/calendars/01a0e783-0275-7241-92d2-ce78e1896985/</d:href>
        </c:calendar-home-set>
        <d:displayname>Journal</d:displayname>
      </d:prop>
      <d:status>HTTP/1.1 200 OK</d:status>
    </d:propstat>
  </d:response>
  <d:response>
    <d:href>/dav/calendars/01a0e783-0275-7241-92d2-ce78e1896985/journal/</d:href>
    <d:propstat>
      <d:prop>
        <d:resourcetype>
          <d:collection/>
          <c:calendar/>
        </d:resourcetype>
        <d:current-user-principal>
          <d:href>/dav/principals/01a0e783-0275-7241-92d2-ce78e1896985/</d:href>
        </d:current-user-principal>
        <c:calendar-home-set>
          <d:href>/dav/calendars/01a0e783-0275-7241-92d2-ce78e1896985/</d:href>
        </c:calendar-home-set>
        <d:displayname>Journal</d:displayname>
        <cs:getctag xmlns:cs="http://calendarserver.org/ns/">urn:calternal:journal:b7b30cf58a40895597fee0ac0ec58ae061d1876862d6e013d5fdc7f5357f3e65:0</cs:getctag>
        <d:sync-token>urn:calternal:journal:b7b30cf58a40895597fee0ac0ec58ae061d1876862d6e013d5fdc7f5357f3e65:0</d:sync-token>
      </d:prop>
      <d:status>HTTP/1.1 200 OK</d:status>
    </d:propstat>
  </d:response>
  <d:response>
    <d:href>/dav/calendars/01a0e783-0275-7241-92d2-ce78e1896985/reminders/</d:href>
    <d:propstat>
      <d:prop>
        <d:resourcetype>
          <d:collection/>
          <c:calendar/>
        </d:resourcetype>
        <d:current-user-principal>
          <d:href>/dav/principals/01a0e783-0275-7241-92d2-ce78e1896985/</d:href>
        </d:current-user-principal>
        <c:calendar-home-set>
          <d:href>/dav/calendars/01a0e783-0275-7241-92d2-ce78e1896985/</d:href>
        </c:calendar-home-set>
        <d:displayname>Reminders</d:displayname>
        <c:supported-calendar-component-set>
          <c:comp name="VTODO"/>
        </c:supported-calendar-component-set>
        <cs:getctag xmlns:cs="http://calendarserver.org/ns/">urn:calternal:reminders:65f8914cf647234bb25064dc7f40405c:710e98a6d83266de:0</cs:getctag>
        <d:sync-token>urn:calternal:reminders:65f8914cf647234bb25064dc7f40405c:710e98a6d83266de:0</d:sync-token>
      </d:prop>
      <d:status>HTTP/1.1 200 OK</d:status>
    </d:propstat>
  </d:response>
</d:multistatus>

After

<?xml version="1.0" ?>
<d:multistatus xmlns:d="DAV:" xmlns:c="urn:ietf:params:xml:ns:caldav" xmlns:cs="http://calendarserver.org/ns/">
  <d:response>
    <d:href>/dav/calendars/01a0e783-0275-7241-92d2-ce78e1896985/</d:href>
    <d:propstat>
      <d:prop>
        <d:resourcetype>
          <d:collection/>
        </d:resourcetype>
        <d:displayname>Calendars</d:displayname>
        <d:current-user-principal>
          <d:href>/dav/principals/01a0e783-0275-7241-92d2-ce78e1896985/</d:href>
        </d:current-user-principal>
        <d:current-user-privilege-set>
          <d:privilege>
            <d:read/>
          </d:privilege>
        </d:current-user-privilege-set>
        <d:owner>
          <d:href>/dav/principals/01a0e783-0275-7241-92d2-ce78e1896985/</d:href>
        </d:owner>
      </d:prop>
      <d:status>HTTP/1.1 200 OK</d:status>
    </d:propstat>
  </d:response>
  <d:response>
    <d:href>/dav/calendars/01a0e783-0275-7241-92d2-ce78e1896985/journal/</d:href>
    <d:propstat>
      <d:prop>
        <d:resourcetype>
          <d:collection/>
          <c:calendar/>
        </d:resourcetype>
        <d:displayname>Journal</d:displayname>
        <d:current-user-principal>
          <d:href>/dav/principals/01a0e783-0275-7241-92d2-ce78e1896985/</d:href>
        </d:current-user-principal>
        <d:current-user-privilege-set>
          <d:privilege>
            <d:read/>
          </d:privilege>
          <d:privilege>
            <d:write/>
          </d:privilege>
          <d:privilege>
            <d:write-content/>
          </d:privilege>
          <d:privilege>
            <d:bind/>
          </d:privilege>
          <d:privilege>
            <d:unbind/>
          </d:privilege>
        </d:current-user-privilege-set>
        <d:owner>
          <d:href>/dav/principals/01a0e783-0275-7241-92d2-ce78e1896985/</d:href>
        </d:owner>
        <d:supported-report-set>
          <d:supported-report>
            <d:report>
              <c:calendar-query/>
            </d:report>
          </d:supported-report>
          <d:supported-report>
            <d:report>
              <c:calendar-multiget/>
            </d:report>
          </d:supported-report>
          <d:supported-report>
            <d:report>
              <d:sync-collection/>
            </d:report>
          </d:supported-report>
        </d:supported-report-set>
        <c:supported-calendar-component-set>
          <c:comp name="VEVENT"/>
        </c:supported-calendar-component-set>
        <d:sync-token>urn:calternal:journal:b7b30cf58a40895597fee0ac0ec58ae061d1876862d6e013d5fdc7f5357f3e65:0</d:sync-token>
        <cs:getctag>urn:calternal:journal:b7b30cf58a40895597fee0ac0ec58ae061d1876862d6e013d5fdc7f5357f3e65:0</cs:getctag>
      </d:prop>
      <d:status>HTTP/1.1 200 OK</d:status>
    </d:propstat>
  </d:response>
  <d:response>
    <d:href>/dav/calendars/01a0e783-0275-7241-92d2-ce78e1896985/reminders/</d:href>
    <d:propstat>
      <d:prop>
        <d:resourcetype>
          <d:collection/>
          <c:calendar/>
        </d:resourcetype>
        <d:displayname>Reminders</d:displayname>
        <d:current-user-principal>
          <d:href>/dav/principals/01a0e783-0275-7241-92d2-ce78e1896985/</d:href>
        </d:current-user-principal>
        <d:current-user-privilege-set>
          <d:privilege>
            <d:read/>
          </d:privilege>
          <d:privilege>
            <d:write/>
          </d:privilege>
          <d:privilege>
            <d:write-content/>
          </d:privilege>
          <d:privilege>
            <d:bind/>
          </d:privilege>
          <d:privilege>
            <d:unbind/>
          </d:privilege>
        </d:current-user-privilege-set>
        <d:owner>
          <d:href>/dav/principals/01a0e783-0275-7241-92d2-ce78e1896985/</d:href>
        </d:owner>
        <d:supported-report-set>
          <d:supported-report>
            <d:report>
              <c:calendar-query/>
            </d:report>
          </d:supported-report>
          <d:supported-report>
            <d:report>
              <c:calendar-multiget/>
            </d:report>
          </d:supported-report>
          <d:supported-report>
            <d:report>
              <d:sync-collection/>
            </d:report>
          </d:supported-report>
        </d:supported-report-set>
        <c:supported-calendar-component-set>
          <c:comp name="VTODO"/>
        </c:supported-calendar-component-set>
        <d:sync-token>urn:calternal:reminders:65f8914cf647234bb25064dc7f40405c:710e98a6d83266de:0</d:sync-token>
        <cs:getctag>urn:calternal:reminders:65f8914cf647234bb25064dc7f40405c:710e98a6d83266de:0</cs:getctag>
      </d:prop>
      <d:status>HTTP/1.1 200 OK</d:status>
    </d:propstat>
  </d:response>
</d:multistatus>

The changed projection labels the home Calendars and advertises owner/read privilege. Journal now advertises write privileges, VEVENT support and query/multiget/sync reports. Reminders advertises the same reports and write privileges with VTODO support. Sync token and getctag remain available on both collections.

Adversarial round

Post-merge DAV-only probe completed:

DAV home listing concurrency: 6/24 returned expected rate_limited backpressure
DAV Apple property, write-capability, MKCALENDAR and adversarial probes completed

The six HTTP 429 responses had the expected {"code":"rate_limited"} envelope from bounded app-password verification capacity. The remaining discovery/property, XML, path, cross-user, MKCALENDAR, and concurrency probes passed. No 5xx response, crash, malformed property acceptance, or hostile path acceptance was observed.

Gates

$ cargo fmt --check
(no output; exit 0)
$ cargo clippy --all-targets -- -D warnings
    Finished 'dev' profile [unoptimized + debuginfo] target(s) in 41m 06s
$ cargo test
running 10 tests
test result: ok. 10 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.02s
running 1 test
test apple_caldav_request_replay_lists_and_writes_journal_and_reminders ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.02s
(exit 0; workspace test run completed)

Files and history

DAV changes: crates/calternal-dav/Cargo.toml, crates/calternal-dav/src/protocol.rs, crates/calternal-dav/tests/apple_replay.rs, Cargo.lock, tests/adversarial/attack.py, and tests/adversarial/run.sh. The required one-time merge of dev is included.

Commits: 688d1761, cb3b4d38, 710293ce, merge 70e6a70b, 3e817381, 18d27cdb.
Head: 18d27cdb67d4752c513a385e2cf22d37e075abbd.

Decisions and gaps

Journal remains the fixed writable VEVENT projection and Reminders the fixed writable VTODO projection; the home itself is read-only. MKCALENDAR cannot create new projections, so it receives 403 with the fixed-location precondition.
The adversarial probe treats correctly enveloped HTTP 429 auth-capacity responses as backpressure, rather than a DAV failure.
No physical macOS Calendar account was available for a UI login check. The client fixture was empty, and python-caldav/vdirsyncer writes were not exercised; Rust replay covers event/task write and delete paths.

# Forgejo #323 — CalDAV client compatibility ## Change The DAV layer now answers the property selectors used during Apple account discovery, including allprop, propname, and explicit prop. It advertises the fixed Journal VEVENT and Reminders VTODO projections, supported reports, ownership, privileges, and calendar user addresses. Unknown requested properties receive a 404 propstat. `MKCALENDAR` on the fixed home is refused with the DAV `calendar-collection-location-ok` precondition so Apple can continue discovery instead of treating the projection as a missing calendar. The Rust request-replay integration test uses the production router and checks discovery, sync/query, event and task writes, deletes, selector handling, and fixed-projection denial. This matches the property and sync request shapes in [Apple's CalDAVTester PROPFIND fixture](https://github.com/apple/ccs-caldavtester/blob/master/scripts/tests/CalDAV/propfind.xml) and [sync fixture](https://github.com/apple/ccs-caldavtester/blob/master/scripts/tests/CalDAV/sync-report.xml), with collection behavior guided by [RFC 4791](https://www.rfc-editor.org/rfc/rfc4791.html). ## Client runs against the branch-built local server - `python-caldav 3.3.1`: principal and calendar discovery succeeded. Journal query returned 0 VEVENT; Reminders query returned 0 VTODO. - `vdirsyncer 0.21.0`: `discover calternal` exited 0 and found Journal and Reminders; `sync calternal` exited 0 for both collections. Discovery configured the missing local Reminders collection, then sync completed. Client/config usage follows the [vdirsyncer config manual](https://vdirsyncer.pimutils.org/en/stable/config.html) and [python-caldav collection docs](https://caldav.readthedocs.io/stable/caldav/collection.html). The local fixture had no events or tasks, so the client queries were empty. The two Python clients exercised discovery and reads/initial sync; the Rust replay test exercised create/update/delete. ## Home listing XML before and after Both captures are authenticated Depth 1 allprop `PROPFIND` responses for the same local test account and fixture. Before is from base `7bbaf5133c00506deb0f421ef7a75f5f3c72b859`; after is from this branch. ### Before ```xml <?xml version="1.0" ?> <d:multistatus xmlns:d="DAV:" xmlns:c="urn:ietf:params:xml:ns:caldav"> <d:response> <d:href>/dav/calendars/01a0e783-0275-7241-92d2-ce78e1896985/</d:href> <d:propstat> <d:prop> <d:resourcetype> <d:collection/> </d:resourcetype> <d:current-user-principal> <d:href>/dav/principals/01a0e783-0275-7241-92d2-ce78e1896985/</d:href> </d:current-user-principal> <c:calendar-home-set> <d:href>/dav/calendars/01a0e783-0275-7241-92d2-ce78e1896985/</d:href> </c:calendar-home-set> <d:displayname>Journal</d:displayname> </d:prop> <d:status>HTTP/1.1 200 OK</d:status> </d:propstat> </d:response> <d:response> <d:href>/dav/calendars/01a0e783-0275-7241-92d2-ce78e1896985/journal/</d:href> <d:propstat> <d:prop> <d:resourcetype> <d:collection/> <c:calendar/> </d:resourcetype> <d:current-user-principal> <d:href>/dav/principals/01a0e783-0275-7241-92d2-ce78e1896985/</d:href> </d:current-user-principal> <c:calendar-home-set> <d:href>/dav/calendars/01a0e783-0275-7241-92d2-ce78e1896985/</d:href> </c:calendar-home-set> <d:displayname>Journal</d:displayname> <cs:getctag xmlns:cs="http://calendarserver.org/ns/">urn:calternal:journal:b7b30cf58a40895597fee0ac0ec58ae061d1876862d6e013d5fdc7f5357f3e65:0</cs:getctag> <d:sync-token>urn:calternal:journal:b7b30cf58a40895597fee0ac0ec58ae061d1876862d6e013d5fdc7f5357f3e65:0</d:sync-token> </d:prop> <d:status>HTTP/1.1 200 OK</d:status> </d:propstat> </d:response> <d:response> <d:href>/dav/calendars/01a0e783-0275-7241-92d2-ce78e1896985/reminders/</d:href> <d:propstat> <d:prop> <d:resourcetype> <d:collection/> <c:calendar/> </d:resourcetype> <d:current-user-principal> <d:href>/dav/principals/01a0e783-0275-7241-92d2-ce78e1896985/</d:href> </d:current-user-principal> <c:calendar-home-set> <d:href>/dav/calendars/01a0e783-0275-7241-92d2-ce78e1896985/</d:href> </c:calendar-home-set> <d:displayname>Reminders</d:displayname> <c:supported-calendar-component-set> <c:comp name="VTODO"/> </c:supported-calendar-component-set> <cs:getctag xmlns:cs="http://calendarserver.org/ns/">urn:calternal:reminders:65f8914cf647234bb25064dc7f40405c:710e98a6d83266de:0</cs:getctag> <d:sync-token>urn:calternal:reminders:65f8914cf647234bb25064dc7f40405c:710e98a6d83266de:0</d:sync-token> </d:prop> <d:status>HTTP/1.1 200 OK</d:status> </d:propstat> </d:response> </d:multistatus> ``` ### After ```xml <?xml version="1.0" ?> <d:multistatus xmlns:d="DAV:" xmlns:c="urn:ietf:params:xml:ns:caldav" xmlns:cs="http://calendarserver.org/ns/"> <d:response> <d:href>/dav/calendars/01a0e783-0275-7241-92d2-ce78e1896985/</d:href> <d:propstat> <d:prop> <d:resourcetype> <d:collection/> </d:resourcetype> <d:displayname>Calendars</d:displayname> <d:current-user-principal> <d:href>/dav/principals/01a0e783-0275-7241-92d2-ce78e1896985/</d:href> </d:current-user-principal> <d:current-user-privilege-set> <d:privilege> <d:read/> </d:privilege> </d:current-user-privilege-set> <d:owner> <d:href>/dav/principals/01a0e783-0275-7241-92d2-ce78e1896985/</d:href> </d:owner> </d:prop> <d:status>HTTP/1.1 200 OK</d:status> </d:propstat> </d:response> <d:response> <d:href>/dav/calendars/01a0e783-0275-7241-92d2-ce78e1896985/journal/</d:href> <d:propstat> <d:prop> <d:resourcetype> <d:collection/> <c:calendar/> </d:resourcetype> <d:displayname>Journal</d:displayname> <d:current-user-principal> <d:href>/dav/principals/01a0e783-0275-7241-92d2-ce78e1896985/</d:href> </d:current-user-principal> <d:current-user-privilege-set> <d:privilege> <d:read/> </d:privilege> <d:privilege> <d:write/> </d:privilege> <d:privilege> <d:write-content/> </d:privilege> <d:privilege> <d:bind/> </d:privilege> <d:privilege> <d:unbind/> </d:privilege> </d:current-user-privilege-set> <d:owner> <d:href>/dav/principals/01a0e783-0275-7241-92d2-ce78e1896985/</d:href> </d:owner> <d:supported-report-set> <d:supported-report> <d:report> <c:calendar-query/> </d:report> </d:supported-report> <d:supported-report> <d:report> <c:calendar-multiget/> </d:report> </d:supported-report> <d:supported-report> <d:report> <d:sync-collection/> </d:report> </d:supported-report> </d:supported-report-set> <c:supported-calendar-component-set> <c:comp name="VEVENT"/> </c:supported-calendar-component-set> <d:sync-token>urn:calternal:journal:b7b30cf58a40895597fee0ac0ec58ae061d1876862d6e013d5fdc7f5357f3e65:0</d:sync-token> <cs:getctag>urn:calternal:journal:b7b30cf58a40895597fee0ac0ec58ae061d1876862d6e013d5fdc7f5357f3e65:0</cs:getctag> </d:prop> <d:status>HTTP/1.1 200 OK</d:status> </d:propstat> </d:response> <d:response> <d:href>/dav/calendars/01a0e783-0275-7241-92d2-ce78e1896985/reminders/</d:href> <d:propstat> <d:prop> <d:resourcetype> <d:collection/> <c:calendar/> </d:resourcetype> <d:displayname>Reminders</d:displayname> <d:current-user-principal> <d:href>/dav/principals/01a0e783-0275-7241-92d2-ce78e1896985/</d:href> </d:current-user-principal> <d:current-user-privilege-set> <d:privilege> <d:read/> </d:privilege> <d:privilege> <d:write/> </d:privilege> <d:privilege> <d:write-content/> </d:privilege> <d:privilege> <d:bind/> </d:privilege> <d:privilege> <d:unbind/> </d:privilege> </d:current-user-privilege-set> <d:owner> <d:href>/dav/principals/01a0e783-0275-7241-92d2-ce78e1896985/</d:href> </d:owner> <d:supported-report-set> <d:supported-report> <d:report> <c:calendar-query/> </d:report> </d:supported-report> <d:supported-report> <d:report> <c:calendar-multiget/> </d:report> </d:supported-report> <d:supported-report> <d:report> <d:sync-collection/> </d:report> </d:supported-report> </d:supported-report-set> <c:supported-calendar-component-set> <c:comp name="VTODO"/> </c:supported-calendar-component-set> <d:sync-token>urn:calternal:reminders:65f8914cf647234bb25064dc7f40405c:710e98a6d83266de:0</d:sync-token> <cs:getctag>urn:calternal:reminders:65f8914cf647234bb25064dc7f40405c:710e98a6d83266de:0</cs:getctag> </d:prop> <d:status>HTTP/1.1 200 OK</d:status> </d:propstat> </d:response> </d:multistatus> ``` The changed projection labels the home `Calendars` and advertises owner/read privilege. Journal now advertises write privileges, VEVENT support and query/multiget/sync reports. Reminders advertises the same reports and write privileges with VTODO support. Sync token and getctag remain available on both collections. ## Adversarial round Post-merge DAV-only probe completed: ```text DAV home listing concurrency: 6/24 returned expected rate_limited backpressure DAV Apple property, write-capability, MKCALENDAR and adversarial probes completed ``` The six HTTP 429 responses had the expected `{"code":"rate_limited"}` envelope from bounded app-password verification capacity. The remaining discovery/property, XML, path, cross-user, MKCALENDAR, and concurrency probes passed. No 5xx response, crash, malformed property acceptance, or hostile path acceptance was observed. ## Gates ```text $ cargo fmt --check (no output; exit 0) $ cargo clippy --all-targets -- -D warnings Finished 'dev' profile [unoptimized + debuginfo] target(s) in 41m 06s $ cargo test running 10 tests test result: ok. 10 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.02s running 1 test test apple_caldav_request_replay_lists_and_writes_journal_and_reminders ... ok test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.02s (exit 0; workspace test run completed) ``` ## Files and history DAV changes: `crates/calternal-dav/Cargo.toml`, `crates/calternal-dav/src/protocol.rs`, `crates/calternal-dav/tests/apple_replay.rs`, `Cargo.lock`, `tests/adversarial/attack.py`, and `tests/adversarial/run.sh`. The required one-time merge of `dev` is included. Commits: `688d1761`, `cb3b4d38`, `710293ce`, merge `70e6a70b`, `3e817381`, `18d27cdb`. Head: `18d27cdb67d4752c513a385e2cf22d37e075abbd`. ## Decisions and gaps - Journal remains the fixed writable VEVENT projection and Reminders the fixed writable VTODO projection; the home itself is read-only. `MKCALENDAR` cannot create new projections, so it receives 403 with the fixed-location precondition. - The adversarial probe treats correctly enveloped HTTP 429 auth-capacity responses as backpressure, rather than a DAV failure. - No physical macOS Calendar account was available for a UI login check. The client fixture was empty, and python-caldav/vdirsyncer writes were not exercised; Rust replay covers event/task write and delete paths.

kayg commented

2026-09-28 12:32:13 +00:00

Author

Owner

Real macOS 27 Calendar verification (orchestrator, calternal-macos VM, 2026-09-28), branch head 80b17f64.
Setup: this branch served over HTTPS (a Cloudflare quick tunnel → a logging proxy → the local server; test data only), with an app password from the adversarial setup fixture.
Found and fixed (commit 80b17f64, now on this branch):

Over the unauthenticated discovery PROPFIND, the 401 challenge listed Basic and Bearer in one header; macOS did not retry with the password and instead probed /, /principals/, /calendar/dav/<id>/user/. → The challenge now lists only Basic.
The SPA fallback answered PROPFIND with 200 HTML, so macOS treated / as a DAV server and failed with 'Unable to verify account name or password'. → The fallback now returns 404 for any method other than GET/HEAD.
Now working on a real Mac: the account adds; principal → home → Journal → REPORT all 207; the Log entries show in Apple Calendar (screenshot on this issue in the next comment); the ⚠ disappears after the first refresh.
Still broken (fix in this job):
Writes from macOS fail: PUT → 422 'exactly one VEVENT is required'. macOS always sends a VTIMEZONE (with a nested STANDARD component), calendar-level X-CALENDARSERVER-ACCESS:PUBLIC, and event properties CREATED, DTSTAMP, LAST-MODIFIED, SEQUENCE, TRANSP, X-APPLE-CREATOR-IDENTITY, X-APPLE-CREATOR-TEAM-IDENTITY (plus often VALARM, URL, X-APPLE-TRAVEL-, X-APPLE-STRUCTURED-LOCATION). parse_journal_icalendar (crates/calternal-dav/src/lib.rs) rejects all of these. The exact captured request is committed as a fixture: crates/calternal-dav/tests/fixtures/macos27/put-new-event.ics (and proppatch-calendar-color.xml). Fix: accept and ignore VTIMEZONE (the TZID parameter is the IANA name, e.g. Asia/Calcutta, which chrono_tz accepts), non-semantic housekeeping props and X- props; for semantic props that cannot become a Log line (RRULE, ATTENDEE, …) answer with the proper CalDAV precondition (C:valid-calendar-object-resource / C:supported-calendar-component, 403) rather than a bare 422, so the client shows a meaningful error. Decide VALARM: ignore (Log entries have no alarms) is fine. Round trip: a GET after PUT must return an event macOS accepts (the same UID).
PROPPATCH → 405. macOS sets {http://apple.com/ns/ical/}calendar-color (and often calendar-order and displayname) on the Journal collection. Support PROPPATCH for those (store per user; return them in PROPFIND) or answer 207 with a per-property 403. Never 405.
Add both fixtures to the Apple replay test so they cannot regress, and replay the full captured macOS sequence (discovery without credentials, then with). The orchestrator will re-verify on the Mac VM before merge.

**Real macOS 27 Calendar verification (orchestrator, calternal-macos VM, 2026-09-28), branch head 80b17f64.** Setup: this branch served over HTTPS (a Cloudflare quick tunnel → a logging proxy → the local server; test data only), with an app password from the adversarial setup fixture. Found and fixed (commit 80b17f64, now on this branch): 1. Over the unauthenticated discovery PROPFIND, the 401 challenge listed **Basic and Bearer** in one header; macOS did not retry with the password and instead probed `/`, `/principals/`, `/calendar/dav/<id>/user/`. → The challenge now lists only Basic. 2. The **SPA fallback answered PROPFIND with 200 HTML**, so macOS treated `/` as a DAV server and failed with 'Unable to verify account name or password'. → The fallback now returns 404 for any method other than GET/HEAD. **Now working on a real Mac:** the account adds; principal → home → Journal → REPORT all 207; **the Log entries show in Apple Calendar** (screenshot on this issue in the next comment); the ⚠ disappears after the first refresh. **Still broken (fix in this job):** 3. **Writes from macOS fail: PUT → 422 'exactly one VEVENT is required'.** macOS always sends a VTIMEZONE (with a nested STANDARD component), calendar-level `X-CALENDARSERVER-ACCESS:PUBLIC`, and event properties CREATED, DTSTAMP, LAST-MODIFIED, SEQUENCE, TRANSP, X-APPLE-CREATOR-IDENTITY, X-APPLE-CREATOR-TEAM-IDENTITY (plus often VALARM, URL, X-APPLE-TRAVEL-*, X-APPLE-STRUCTURED-LOCATION). `parse_journal_icalendar` (crates/calternal-dav/src/lib.rs) rejects all of these. **The exact captured request is committed as a fixture: `crates/calternal-dav/tests/fixtures/macos27/put-new-event.ics`** (and `proppatch-calendar-color.xml`). Fix: accept and ignore VTIMEZONE (the TZID parameter is the IANA name, e.g. Asia/Calcutta, which chrono_tz accepts), non-semantic housekeeping props and X-* props; for semantic props that cannot become a Log line (RRULE, ATTENDEE, …) answer with the proper CalDAV precondition (`C:valid-calendar-object-resource` / `C:supported-calendar-component`, 403) rather than a bare 422, so the client shows a meaningful error. Decide VALARM: ignore (Log entries have no alarms) is fine. Round trip: a GET after PUT must return an event macOS accepts (the same UID). 4. **PROPPATCH → 405.** macOS sets `{http://apple.com/ns/ical/}calendar-color` (and often calendar-order and displayname) on the Journal collection. Support PROPPATCH for those (store per user; return them in PROPFIND) or answer 207 with a per-property 403. Never 405. 5. Add both fixtures to the Apple replay test so they cannot regress, and replay the **full captured macOS sequence** (discovery without credentials, then with). The orchestrator will re-verify on the Mac VM before merge.

kayg commented

2026-09-28 12:33:54 +00:00

Author

Owner

Starting the macOS 27 Calendar write-interop continuation on job/caldav-apple.

Base dev SHA: cde2cb813367a8ec616e2d25d3a9b9fd097038d8.
Starting HEAD: 53cca92cd2873d3250c2370802719037fa3c7cef.

I will trace the captured PUT and calendar-color PROPPATCH through the parser and DAV protocol, extend the Apple replay regression, then merge dev once before the final gates and one adversarial round. No deploy or merge into dev is planned from this job.

Starting the macOS 27 Calendar write-interop continuation on `job/caldav-apple`. Base `dev` SHA: `cde2cb813367a8ec616e2d25d3a9b9fd097038d8`. Starting HEAD: `53cca92cd2873d3250c2370802719037fa3c7cef`. I will trace the captured PUT and calendar-color PROPPATCH through the parser and DAV protocol, extend the Apple replay regression, then merge `dev` once before the final gates and one adversarial round. No deploy or merge into `dev` is planned from this job.

kayg commented

2026-09-28 12:46:37 +00:00

Author

Owner

Finding from a test-first replay of fixtures/macos27/put-new-event.ics: cargo test -p calternal-dav macos27_put_fixture_projects_to_one_zoned_log_entry -- --nocapture fails with captured macOS event should parse: "exactly one VEVENT is required". The fixture has one VEVENT plus a VTIMEZONE with nested STANDARD; parse_journal_icalendar currently rejects any parsed calendar whose flattened component table is not exactly VCALENDAR + VEVENT. The captured UID is also a bare UUID rather than the parser's required @calternal form. I am checking resource identity and GET behavior as part of the same replay before choosing the smallest compatible mapping.

Finding from a test-first replay of `fixtures/macos27/put-new-event.ics`: `cargo test -p calternal-dav macos27_put_fixture_projects_to_one_zoned_log_entry -- --nocapture` fails with `captured macOS event should parse: "exactly one VEVENT is required"`. The fixture has one VEVENT plus a VTIMEZONE with nested STANDARD; `parse_journal_icalendar` currently rejects any parsed calendar whose flattened component table is not exactly VCALENDAR + VEVENT. The captured UID is also a bare UUID rather than the parser's required `@calternal` form. I am checking resource identity and GET behavior as part of the same replay before choosing the smallest compatible mapping.

kayg referenced this issue

2026-09-28 13:01:50 +00:00

APP PASSWORDS: one-scan setup — QR → Apple configuration profile on iPhone/iPad, one-click profile on Mac, collapsible step lists #318

kayg commented

2026-09-28 13:01:50 +00:00

Author

Owner

Also seen on the real Mac: macOS sends PROPPATCH to the Reminders collection too (after installing via profile): three 405s on /dav/calendars/<id>/reminders/. Treat PROPPATCH the same way for both collections (calendar-color/order/displayname).

Also seen on the real Mac: macOS sends **PROPPATCH to the Reminders collection too** (after installing via profile): three 405s on `/dav/calendars/<id>/reminders/`. Treat PROPPATCH the same way for both collections (calendar-color/order/displayname).

kayg commented

2026-09-28 13:06:01 +00:00

Author

Owner

The captured macOS 27 write replay now passes in calternal-dav.

VTIMEZONE and its STANDARD/DAYLIGHT observances are structurally accepted; the event's IANA TZID remains the stored zone. Apple housekeeping fields, TRANSP, and X-properties are ignored. VALARM is ignored because Log entries have no alarm field. Apple's escaped trailing SUMMARY line break is removed so the Log title stays on one line.
The captured bare dashed UUID is used as the Log block identity and is returned unchanged as UID by GET. Existing compact block IDs keep their @calternal UID form.
RRULE, unrepresentable URLs, and other semantic properties return 403 with CALDAV:valid-calendar-object-resource; unsupported top-level components return 403 with CALDAV:supported-calendar-component.
PROPPATCH on fixed projections returns 207 with one 403 propstat per property. This does not persist calendar-color/order/displayname.

Verification so far: cargo test -p calternal-dav passed (11 unit tests, 1 Apple replay integration test, doc tests passed). The replay uses both macOS fixtures. The DAV adversarial script now probes multi-property PROPPATCH plus malformed and oversized bodies. I will run the post-merge adversarial round and workspace gates after merging dev once.

The captured macOS 27 write replay now passes in `calternal-dav`. - `VTIMEZONE` and its STANDARD/DAYLIGHT observances are structurally accepted; the event's IANA TZID remains the stored zone. Apple housekeeping fields, `TRANSP`, and X-properties are ignored. `VALARM` is ignored because Log entries have no alarm field. Apple's escaped trailing SUMMARY line break is removed so the Log title stays on one line. - The captured bare dashed UUID is used as the Log block identity and is returned unchanged as UID by GET. Existing compact block IDs keep their `@calternal` UID form. - RRULE, unrepresentable URLs, and other semantic properties return 403 with `CALDAV:valid-calendar-object-resource`; unsupported top-level components return 403 with `CALDAV:supported-calendar-component`. - PROPPATCH on fixed projections returns 207 with one 403 propstat per property. This does not persist calendar-color/order/displayname. Verification so far: `cargo test -p calternal-dav` passed (11 unit tests, 1 Apple replay integration test, doc tests passed). The replay uses both macOS fixtures. The DAV adversarial script now probes multi-property PROPPATCH plus malformed and oversized bodies. I will run the post-merge adversarial round and workspace gates after merging `dev` once.

kayg commented

2026-09-28 13:09:27 +00:00

Author

Owner

Merged dev once before the final gates. dev was at 9d48a3fb8ef08d44394f6d126bce2c3b605e5652; merge commit fa89736de2f20adb8c9853ea102bee5317be0091. Git completed the merge without conflicts. I am running the DAV-only adversarial round against the merged tree now.

Merged `dev` once before the final gates. `dev` was at `9d48a3fb8ef08d44394f6d126bce2c3b605e5652`; merge commit `fa89736de2f20adb8c9853ea102bee5317be0091`. Git completed the merge without conflicts. I am running the DAV-only adversarial round against the merged tree now.

kayg commented

2026-09-28 13:49:35 +00:00

Author

Owner

Completed Forgejo #323.

Branch: job/caldav-apple
Head: fa89736de2f20adb8c9853ea102bee5317be0091
The branch was pushed. git push origin job/caldav-apple returned Everything up-to-date.
Merged dev once before final gates (9d48a3fb); the merge has no conflicts.

Implemented in:

crates/calternal-dav/src/lib.rs
crates/calternal-dav/src/protocol.rs
crates/calternal-dav/tests/apple_replay.rs
tests/adversarial/attack.py

The Apple replay now exercises unauthenticated discovery, Basic-authenticated discovery, the captured macOS 27 PUT, GET-after-PUT with the same UID and timezone, unsupported-property preconditions, and PROPPATCH. The parser accepts and ignores VTIMEZONE, Apple X-properties and housekeeping fields, and VALARM. It preserves raw dashed UUID UIDs on GET. Unsupported event semantics return 403 with the matching CalDAV precondition. PROPPATCH returns 207 and one 403 propstat per requested property; it does not persist calendar-color, calendar-order, or displayname.

Gate output:

cargo fmt --check: exit 0, no output.
cargo clippy --all-targets -- -D warnings: exit 0; final output: Finished \dev` profile [unoptimized + debuginfo] target(s) in 4m 49s`.
cargo test: exit 0. DAV output:
test result: ok. 11 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.01s
test apple_caldav_request_replay_lists_and_writes_journal_and_reminders ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.03s
bun run --cwd apps/web check:
svelte-check found 0 errors and 0 warnings
bun run --cwd apps/web test:
Test Files 112 passed (112)
Tests 725 passed (725)
Duration 175.84s (transform 57%, environment 18%, import 13%, tests 8%, setup 3%)
DAV adversarial output: DAV Apple property, write-capability, MKCALENDAR and adversarial probes completed.
cargo clean: Removed 15066 files, 13.0GiB total. Removed apps/web/build and apps/web/.svelte-kit; worktree is clean.

Decisions where the design doc was silent: keep CalDAV properties outside the Journal model and use the issue-approved per-property 403 response in 207; preserve a raw dashed UUID UID exactly so Apple GET-after-PUT sees the same UID. Unsupported semantic properties use CalDAV preconditions rather than silent data loss.

Known gap: calendar-color, calendar-order, and displayname are not stored. The orchestrator's real macOS verification is still pending.

Completed Forgejo #323. Branch: `job/caldav-apple` Head: `fa89736de2f20adb8c9853ea102bee5317be0091` The branch was pushed. `git push origin job/caldav-apple` returned `Everything up-to-date`. Merged `dev` once before final gates (`9d48a3fb`); the merge has no conflicts. Implemented in: - `crates/calternal-dav/src/lib.rs` - `crates/calternal-dav/src/protocol.rs` - `crates/calternal-dav/tests/apple_replay.rs` - `tests/adversarial/attack.py` The Apple replay now exercises unauthenticated discovery, Basic-authenticated discovery, the captured macOS 27 PUT, GET-after-PUT with the same UID and timezone, unsupported-property preconditions, and PROPPATCH. The parser accepts and ignores VTIMEZONE, Apple X-properties and housekeeping fields, and VALARM. It preserves raw dashed UUID UIDs on GET. Unsupported event semantics return 403 with the matching CalDAV precondition. PROPPATCH returns 207 and one 403 propstat per requested property; it does not persist calendar-color, calendar-order, or displayname. Gate output: - `cargo fmt --check`: exit 0, no output. - `cargo clippy --all-targets -- -D warnings`: exit 0; final output: `Finished \`dev\` profile [unoptimized + debuginfo] target(s) in 4m 49s`. - `cargo test`: exit 0. DAV output: `test result: ok. 11 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.01s` `test apple_caldav_request_replay_lists_and_writes_journal_and_reminders ... ok` `test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.03s` - `bun run --cwd apps/web check`: `svelte-check found 0 errors and 0 warnings` - `bun run --cwd apps/web test`: ` Test Files 112 passed (112)` ` Tests 725 passed (725)` ` Duration 175.84s (transform 57%, environment 18%, import 13%, tests 8%, setup 3%)` - DAV adversarial output: `DAV Apple property, write-capability, MKCALENDAR and adversarial probes completed`. - `cargo clean`: `Removed 15066 files, 13.0GiB total`. Removed `apps/web/build` and `apps/web/.svelte-kit`; worktree is clean. Decisions where the design doc was silent: keep CalDAV properties outside the Journal model and use the issue-approved per-property 403 response in 207; preserve a raw dashed UUID UID exactly so Apple GET-after-PUT sees the same UID. Unsupported semantic properties use CalDAV preconditions rather than silent data loss. Known gap: calendar-color, calendar-order, and displayname are not stored. The orchestrator's real macOS verification is still pending.

kayg referenced this issue from a commit

2026-09-28 14:21:54 +00:00

Merge job/caldav-apple (#323: Apple Calendar interop — verified on a real macOS 27 Calendar: sign-in, read, PROPPATCH, write)

kayg closed this issue

2026-09-28 14:21:57 +00:00

kayg referenced this issue

2026-09-29 10:42:47 +00:00

Docs site at docs.calternal.com: choose framework, skeleton with calternal theming #415