Errands task manager upstream unconditionally disables TLS certificate verification for CalDAV; does this need to be addressed?

[John Scott]

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 😉
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnome-maintainers/attachments/20251210/ffea6761/attachment.sig>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6270 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnome-maintainers/attachments/20251210/ffea6761/attachment.p7s>