Your message dated Mon, 29 Dec 2025 22:57:51 +0100
with message-id <[email protected]>
and subject line
has caused the Debian Bug report #1123738,
regarding TLS certificates for CalDAV servers are always trusted and not
checked for validity
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1123738: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1123738
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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
smime.p7s
Description: S/MIME cryptographic signature
--- End Message ---
signature.asc
Description: This is a digitally signed message part
--- End Message ---
--- Begin Message ---
Version: 46.2.10-1
--- End Message ---
