Your message dated Fri, 21 Jun 2019 12:54:12 +0200
with message-id <[email protected]>
and subject line Re: Bug#930798: radicale: silently falls back to defaults
(without authn) when running with config for 1.x under uwsgi
has caused the Debian Bug report #930798,
regarding radicale: silently falls back to defaults (without authn) when
running with config for 1.x under uwsgi
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.)
--
930798: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930798
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: radicale
Version: 2.1.11-6
Severity: normal
Dear Maintainer,
* What led up to the situation?
I have a stretch-based radicale installation running under uwsgi with
the attached uwsgi configuration. Under stretch, everything is
operating correctly and radicale authenticates against the LDAP
service specified in the configuration.
* What exactly did you do (or not do) that was effective (or
ineffective)?
I upgraded from stretch to buster while having apt-listchanges and
apt-listbugs installed. I modified the uwsgi configuration to use
python3 instead of python27 (since radicale is now python3 based) and
reloaded the uwsgi-emperor.
* What was the outcome of this action?
The upgrade passed without any notice from apt-listchanges or
apt-listbugs regarding radicale.
radicale was operating, but it was not performing any authentication;
every password was accepted for every user name, opening the server up
for denial of service by unauthorized users (by spamming data on it)
and possibly opening up access to existing data (if the configuration
fits).
* What outcome did you expect instead?
I expect either:
(1) radicale to fail to start and/or operate at all, due to the
obviously invalid configuration. This is the case when I run radicale
manually from the command line (it already chokes at the `well-known`
section, not to mention that there’s no LDAP support anymore).
(2) a prominent warning via apt-listchanges that the configuration
format has changed drastically, that LDAP is not supported anymore, and
that attempting to run radicale with an invalid configuration may lead
to it running without any authentication at all.
At this stage in the release cycle, (2) may be the way to go (and is fully
sufficient In My Opinion).
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
Versions of packages radicale depends on:
ii adduser 3.118
ii init-system-helpers 1.56+nmu1
ii lsb-base 10.2019051400
ii python3 3.7.3-1
ii python3-radicale 2.1.11-6
Versions of packages radicale recommends:
ii ssl-cert 1.0.39
Versions of packages radicale suggests:
pn apache2 <none>
pn apache2-utils <none>
pn libapache2-mod-proxy-uwsgi <none>
pn python3-bcrypt <none>
pn python3-passlib <none>
pn uwsgi <none>
ii uwsgi-plugin-python3 2.0.18-1
-- Configuration Files:
/etc/radicale/config changed:
[encoding]
request = utf-8
stock = utf-8
[well-known]
caldav = /
carddav = /
[auth]
type = LDAP
ldap_url = ldap://192.168.10.1/
ldap_base = ou=Account,dc=zombofant,dc=net
ldap_attribute = uid
ldap_filter = (objectClass=inetOrgPerson)
[storage]
type = multifilesystem
filesystem_folder = /var/lib/radicale/collectionsfnord
[rights]
type = from_file
file = /etc/radicale/rights
/etc/uwsgi-emperor/vassals/radicale.ini
[uwsgi]
http-socket = 0.0.0.0:9001
processes = 1
threads = 1
auto-procname = true
procname-prefix-spaced = [radicale]
harakiri = 30
need-plugin = python27
wsgi-file = /usr/share/radicale/radicale.wsgi
enable-threads = true
offload-threads = 1
-- no debconf information
--- End Message ---
--- Begin Message ---
[ replying to bugreport - not only discretely ]
Quoting Jonas Schäfer (2019-06-21 07:34:34)
> Hi namesake :)
>
> On Donnerstag, 20. Juni 2019 22:53:46 CEST you wrote:
> > Thanks for reporting this issue!
> >
> > Which exact package version did you upgrade from?
>
> I made a reproducer based on the current debian:stretch docker image, which
> appears to have
>
> root@9ebc9f474591:/# apt show radicale
> Package: radicale
> Version: 1.1.1+20160115-4
>
> As a test, when doing:
>
> # apt update
> # apt install radicale apt-listchanges apt-listbugs
> # sed -i 's/stretch/buster/g' /etc/apt/sources.list
> # apt update && apt dist-upgrade -y
>
> There is a listchanges entry,
Thanks for confirming that indeed the NEWS entry appears.
> but I’m not sure if this could be made clearer
> (and I think I missed this one when building my reproducer case):
>
> > Most importantly, data stored with Radicale 1.x is unreadable,
> > and need to be exported using Radicale 1.1.6 before switching to
> > Radicale 2.x.
>
> I think it should mention that the configuration is not compatible and
> depending on how it’s ran, it can expose the radicale storage
> unauthenticatedly (apparently, the data format is always incompatible, so at
> least existing user’s data won’t be exposed? in any case it allows
> unauthorized users to write data to the servers disk).
Only a Radicale setup _deviating_ from the conffiles shipped with the
Debian package exposes data wrongly after package upgrade, right? And
package upgrade involves manual migration of data, right?
I am not convinced it is sensible to try cover in detail how
customizations may be affected by the change when a) package stops
working until manually adapted, and b) NEWS entry hints about "several
incompatible changes" which should clue advanced users into reading
upstream documentation for details on how it affect customizations.
Hereby closing this bugreport. Please notice that although flagged as
closed you are still welcome to post to the bugreport e.g. providing
further arguments and try convince me to change my mind on this.
Kind regards,
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
--- End Message ---
