auth.cache = ("max-age" => "600")
vhostdb.cache = ("max-age" => "600")
If specified with an empty array, default max-age is 600 secs (10 mins)
auth.cache = ()
vhostdb.cache = ()
(Note: cache expiration occurs every 8 seconds, so maximum cache time
might be up to max-age + 8 seconds)
x-ref:
"mod_auth caching"
https://redmine.lighttpd.net/issues/2805
Fixes the following error when building with -Dwith_maxminddb=true:
meson.build:916:1: ERROR: Unknown variable "libmaxminddb".
A full log can be found at meson-logs/meson-log.txt
Signed-off-by: Rosen Penev <rosenp@gmail.com>
libmariadb is what should be used as only the library portion is used.
Fixes compilation under OpenWrt.
Note that mariadb.pc is a superset that links to libmariadb.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
fix theoretical NULL dereference identified by Coverity Scan
possible for PROPFIND with specific atypical choices in lighttpd.conf:
- possible for getcontenttype if no content type matches resource
and no default type configured in lighttpd.conf
- possible for getetag if etag disabled in lighttpd.conf
(pedantic; no impact)
upon error, server will exit, so the impact of momentarily leaking fd
has no impact. This commit holds the fd in srv->stdin_fd to address
Coverity warning about leaking fd when using server.bind = "/dev/stdin"
add warning at server startup when mod_mysql_vhost is loaded
mod_vhostdb_mysql subsumes mod_mysql_vhost. Individual mod_mysql_vhost
directives map one-to-one to keywords in vhostdb.mysql = (...) directive
(expansion of buffer_string_lenth() inline function and CONST_BUF_LEN()
macro, which always check for NULL, appears to cause the analyzer to
believe that a pointer might be NULL in cases where it otherwise can
not be NULL)
x-ref:
http://clang-analyzer.llvm.org/faq.html
Prefer some WolfSSL native APIs when building with WolfSSL.
However, some functionality in WolfSSL is available only through the
WolfSSL compatibility layer for OpenSSL, so the effort to create a
native mod_wolfssl halted here.
webdav.opts = ("unsafe-propfind-follow-symlink" => "enable")
This option is unsafe and unsupported. This option enables non-standard
behavior. If it works for you, great. If it does not work for you,
then too bad.
WebDAV resource and collection concepts do not have an equivalence
to unix symlinks. If "unsafe-propfind-follow-symlink" is "enable",
then lighttpd mod_webdav PROPFIND handling will follow symlinks
if and only if webdav.is_readonly = "enable" is also set.
Allowing symlinks is unsafe in the general case. Using WebDAV methods
to MOVE a relative symlink does not update the symlink relative target.
LOCK is on the resource (e.g. a symlink), not the target of the symlink.
COPY replaces the resource (e.g. a symlink), not the target of the
symlink. There are only a few examples of possibly many more reasons
why using symlinks in a WebDAV-writable collection is unsafe.
provide option to override GnuTLS priority string
ssl.openssl.ssl-conf-cmd = ("gnutls-override" => "...")
will *entirely* replace the priority string constructed by mod_gnutls.
Admin is responsible to ensure that the override is complete.
debugging:
A non-zero value for debug.log-ssl-noise = x *in the global scope*
will cause mod_gnutls to print the GnuTLS priority string to the
error log at startup. debug.log-ssl-noise = 0 in $SERVER["socket"]
scopes can then be used to disable runtime ssl log noise, or
debug.log-ssl-noise can be removed from the global scope after debugging
difference from mod_openssl:
Admin should schedule an independent job to periodically
generate a new STEK before prior STEK lifetime expires.
Only one STEK is active at a time in mod_gnutls.
(more details in prior commit message for mod_openssl)
difference from mod_openssl:
Admin should schedule an independent job to periodically
generate a new STEK up to 2 times during key lifetime
(mbedtls internals store up to 2 keys)
(more details in prior commit message for mod_openssl)
ssl.stek-file to specify session ticket encryption key (STEK)
If ssl.stek-file is specified, it overrides builtin STEK rotation.
STEK file is checked for changes (stat()) once every 64 seconds.
STEK file should be stored in non-persistent storage,
e.g. /dev/shm/lighttpd/stek-file (in memory)
with appropriate permissions set to keep stek-file from being
read by other users. Where possible, systems should also be
configured without swap.
Admin should schedule an independent job to periodically
generate a new STEK up to 3 times during key lifetime
(lighttpd stores up to 3 keys)
format of binary file is:
4-byte - format version (always 0; for use if format changes)
4-byte - activation timestamp
4-byte - expiration timestamp
16-byte - session ticket key name
32-byte - session ticket HMAC encrpytion key
32-byte - session ticket AES encrpytion key
STEK file can be created with a command such as:
dd if=/dev/random bs=1 count=80 status=none | \
perl -e 'print pack("iii",0,time()+300,time()+86400),<>' \
> STEK-file.$$ && mv STEK-file.$$ STEK-file
The above delays activation time by 5 mins (+300 sec) to allow file to
be propagated to other machines. (admin must handle this independently)
If STEK generation is performed immediately prior to starting lighttpd,
admin should activate keys immediately (without +300).
server ticket encryption key (STEK) rotation occurs every 28800 seconds
(8 hours) and upon lighttpd server restart. While lighttpd is running,
(3) encryption keys are preserved, so tickets expire after 1 day.
If using lighttpd with multiple lighttpd workers, then restarting
lighttpd keeps the STEK in sync between lighttpd workers, though
restarting lighttpd three times a day might not be palatable.
Work is in progress to allow admin to supply new encryption keys.
Glenn Strauss
Rosen Penev