Package: errands Version: 46.2.8-1 Severity: important Tags: security upstream Forwarded: https://github.com/mrvladus/Errands/issues/401 X-Debbugs-Cc: Debian Security Team <[email protected]>
Having solicited informal opinions from the Debian security mailing list (attached), I'm filing this report to keep an eye on the issue. To summarize, Errands is able to synchronize a user's task and to-do list data using the CalDAV protocol, a superset of HTTP. Credentials may be retrieved from GNOME Online Accounts where setting up CalDAV is already possible, or information can be entered directly in Errands. This consists of a URL (usually HTTPS) and username/password authentication credentials. It is typical for major providers to use HTTP Basic authentication which sends credentials in plain form and relying on TLS to authenticate the server's identity and encrypt data in transit. In its source code, Errands explicitly specifies 'ssl_verify_cert=False' unconditionally when using a Python CalDAV library. It appears this allows it to accept any certificate whatsoever, even from a malicious man-in-the-middle, without notice to the user. The author doesn't remember why this was needed, but enabling certificate checking works fine for me with a server and my suspicion is the author had a particular service that wasn't doing things properly. Disabling this security check for all users unconditionally and without notice is not an appropriate fix for a compatibility issue. Any genuine client-side bug that would cause certificate verification to unduly fail is most likely in a dependency and is a concern to be separated from Errands. The author rewrote Errands in C and development focus has shifted there. For Trixie at least, this needs to be handled. I've articulated the risks on the upstream issue to encourage the author to investigate but patching this downstream is trivial. To assess if breakage is likely, a detective might wish to check bug reports for the libraries that Errands depends on (namely the CalDAV one) to see if there are known shortcomings in TLS being handled correctly. For whatever it's worth, the GNOME ecosystem has decided that disabling TLS certificate verification should never be done in legitimate usage and so (if I recall correctly) GLib/GIO and/or libsoup have been removing any parameters in their API that would allow this to be turned off or making then no-ops. As Errands is part of the GNOME Circle ecosystem and can integrate with GNOME Online Accounts, there is precedent for even a very firm stance on certificate verification. -- System Information: Debian Release: 13.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.12.57+deb13-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages errands depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-5 ii gir1.2-adw-1 1.7.6-1~deb13u1 ii gir1.2-goa-1.0 3.54.5-1~deb13u1 ii gir1.2-gtk-4.0 4.18.6+ds-2 ii gir1.2-gtksource-5 5.16.0-1 ii gir1.2-secret-1 0.21.7-1 ii gir1.2-xdp-1.0 0.9.1-1 ii python3 3.13.5-1 ii python3-caldav 1.3.9-1 ii python3-gi 3.50.0-4+b1 ii python3-pycryptodome 3.20.0+dfsg-3 errands recommends no packages. errands suggests no packages. -- no debconf information
--- Begin Message ---Hello, Errands is a graphical planning and task organizer application that supports using CalDAV to synchronize tasks from a provider. CalDAV is a set of conventions for using HTTP to access and manage calendar and task data; it's similar to what IMAP is for email. Errands is independently developed but part of the broad GNOME Circle ecosystem. I was browsing upstream issue reports for an unrelated reason and saw https://github.com/mrvladus/Errands/issues/401 which I'll crudely transcribe the dialogue of below: [2025-08-15] powerjungle (reporter): "Is there a reason TLS certificate verification is disabled by default?" Code snippet: > Errands/errands/lib/sync/providers/caldav.py, Line 89 > ssl_verify_cert=False, Description: > Doesn't seem like a safe approach. Why isn't there a checkbox at least for > the user to choose? > I am aware of the rewrite [then-work-in-progress rewrite of Errands in C > instead of Python], but until then people would still be using the the > current python package in their distros. Effectively, Errands hard-codes in its source to never attempt verification of the certificate. I'm not just referring to validation here like checking a CRL or OCSP, but even name validation, so there is no authentication at all and the user is not notified even when they explicitly give an https:// URL for the server. The author of Errands had this reply: [2025-08-15] mrvladus (maintainer): > I can't remember exactly, but I think it was breaking something so I had to > disable that. I find this even more concerning than the average case of a client accepting any TLS certificate whatsoever, for these reasons: • Errands uses HTTP Basic or Digest authentication which is common for DAV clients, but it means TLS usage is absolutely essential with the password otherwise being sent in the clear. • The calendar and task data is quite revealing on its own; it may have information about one's residence, workplace, attachments, and obligations. Unlike much groupware, a to-do list application like this is often used to record one's own thoughts or priorities with no intention of them being visible to others. Am I overreacting? If this is an issue worthy of being fixed in Trixie, I would appreciate if someone who is better with their words and making the risks understandable why this needs to be made a priority. Above all, I'm sending this mail here to gather opinions about etiquette and to learn where the bar is before making a "big deal" about something. I'm merely an Errands user; I don't maintain the package or have a stake in it otherwise. Thanks, Debian hive mind 😉
signature.asc
Description: This is a digitally signed message part
Description: S/MIME cryptographic signature
--- End Message ---
signature.asc
Description: This is a digitally signed message part
