If we need to make an exception we can do it and properly document the
reason but by default we should just use the default login class.
rc.d uses daemon or the login class provided in login.conf.d so this has
no impact there.
discussed with sthen@, tb@ and robert@
praying that my grep/sed skills did not break anything and still
believing in portbump :-)
if a port needs 2.x then set MODPY_VERSION=${MODPY_DEFAULT_VERSION_2}.
This commit doesn't change any versions currently used; it may be that
some ports have MODPY_DEFAULT_VERSION_2 but don't require it, those
should be cleaned up in the course of updating ports where possible.
Python module ports providing py3-* packages should still use
FLAVOR=python3 so that we don't have a mixture of dependencies some
using ${MODPY_FLAVOR} and others not.
py3 works so switch across.
2.x is a bit different and would probably benefit from being a separate
port rather than directly updating productivity/radicale (not least
because you need to export data from 1.1.x before migrating).
"Radicale before 1.1.2 and 2.x before 2.0.0rc2 is prone to timing oracles and
simple brute-force attacks when using the htpasswd authentication method."
MAINTAINER timed-out
ok sthen@
info. (maintainer timeout, though I didn't wait very long due to the
security issues).
- while there, remove unneeded MODPY_ADJ_FILES (spotted by shadchin@),
use BUILD_DEPENDS not LIB_DEPENDS for a python module dependency,
and fix missing VARBASE subst in the sample config file.
Note that there was a NON-BACKWARDS-COMPATIBLE change: for users who have
added a custom user rights file, previously the most permissive rights were
allowed; now the first section in the file matching the path and user
takes priority instead.
Francisco de Borja Lopez Rio.
The htpasswd parser isn't very flexible and only normally handles one
encryption method in the file. So I've also added a patch to recognise
{SHA} from the hash string so that people using this can migrate their
file to bcrypt.
Update README with new htpasswd syntax and information about bcrypt and
migrating.
OK ian@, Sergey Bronnikov (maintainer)
Tweaked from a submission from maintainer Sergey Bronnikov, ok landry@
The Radicale Project is a complete CalDAV calendar server solution,
capable of making multiple calendars available to local and remote
users, with optional authentication policies. Calendars can be
viewed and edited by a calendar client such as Sunbird or Evolution.
The Radicale Project aims to be a light solution, easy to use, easy
to install, easy to configure. As a consequence, it requires few
software dependencies and is pre-configured to work out-of-the-box.
