• last updated 17 mins ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Avoid calls to deprecated NaviServer functions

  1. … 3 more files in changeset.
rework register_icanuse "domDoc asTclValue" since w cannot use apm_version_names_compare during startup

make use of new NaviServer command: ns_joinurl

the implementation provides a fallback when used with older versions of

NaviServer

  1. … 1 more file in changeset.
Use tdom 0.9.5 feature when available

Prefer the builtin json2dict implementation of tDOM when available

  1. … 2 more files in changeset.
merge from oacs-5-10

  1. … 8099 more files in changeset.
Use "ns_mkdtemp" when available to create temporary directories

  1. … 1 more file in changeset.
added icanuse handler for "ns_info meminfo"

fixed icanuse-test for deleting samesite cookies

Updated icanuse registry

- added "ns_ip", "ns_subnetmatch", and "ns_server hosts"

- sorted commands alphabetically

Added support for relative redirects

RFC 2616 requires an absolute URI in the "Location" header field. So

if someone calls "ns_returnredirect /", NaviServer transforms it on

the fly into an absolute URL by prefixing it with the location

(e.g. https://openacs.org/). NaviServer (and OpenACS) has some complex

code to compute the location value, especially when virtual servers

are involved (or for "host-node mapped" subsites in OpenACS). The

situation is further complicated when running behind a reverse proxy

and/or in a containerized environment. In such cases, the location is

computed from the "host" request header field, which must be

validated, otherwise an attacker could hijack a session and redirect

it to a spoofed site.

The situation changed 10 years ago (June 2014) with the introduction

of RFC 7231, which allows relative redirects (see

https://www.rfc-editor.org/rfc/rfc7231#section-7.1.2). Using relative

redirects greatly simplifies configuration and closes the attack

vector using the host header field. RFC 7231 has been superseded by

RFC 9110 (June 2022), which also supports relative redirects via the

"location" response header field (see

https://www.rfc-editor.org/rfc/rfc9110#field.location).

Since OpenACS prefixed always the URL with a location, when it

encounters are relative URL in a "ad_returnredirect", this change

makes use of the new feature of NaviServer 5.

Make sure to use a current version of NaviServer, where the support

was added recently.

  1. … 1 more file in changeset.
Base "ad_conn behind_proxy_p" on "ns_conn details" when available

  1. … 1 more file in changeset.

Use GNU grep when available

GNU grep is now used for the lookup of message keys using the

"--include=" parameter. This improves the speed of the command

significantly and reduces the number of external dependencies (no

"find", or "xargs" needed).

  1. … 1 more file in changeset.
use "ns_set stats" when available in memory statistics of ::xo::stats

  1. … 1 more file in changeset.
added standard parameterizations for Argon2 when supported.

  1. … 2 more files in changeset.
added support for icanuse "ns_crypto::scrypt"

it looks as if this was lost over time

Set "softrecreate" in nsf o avoid full cleanup on redefinition of classes

improve resolution in fallback case

added icanuse rule for ns_parsehtml

Use NaviServer feature "ns_deletecookie ... -samesite $samesite ..." when available.

  1. … 2 more files in changeset.
use "ns_strcoll" for ordered composite when available

  1. … 1 more file in changeset.
include timing information in DEBUG lines only, when nsf was configured properly with it

  1. … 1 more file in changeset.
use icanuse machinery for "ns_reflow_text -offset"

  1. … 1 more file in changeset.
Modernize parameter parsing (query and includelet paramters)

- handle invalid UTF-8 exception that might be triggered by

"ns_parsequery" in newer versions of NaviServer

- the new code is about 4 times faster than the old one

- replaced array by dict

- don't create helper procs on the fly but use "nsf::parseargs" if possible

- added icanuse rules for

* "nsf::parseargs -asdict"

* "ns_parsequery -charset"

  1. … 1 more file in changeset.
security::locations: return configured servers from the driver/servers section

additionally, improve caching

  1. … 1 more file in changeset.
added icanuse for "ns_pg pid"

provide as well a minimal compatibility for "-size" parameter on ns_baseunit

  1. … 1 more file in changeset.
added a partial backwards compatibility implementation of for ns_baseunit (as used in request processor)

  1. … 1 more file in changeset.
Use "ns_baseunit", when available for size calculation of parititoned caches

Generalize ::acs::try_cache (such it can be use not only for "...cache eval..."

  1. … 3 more files in changeset.
added support for "ns_trim -prefix".

The command is predefined in NaviServer; if not available, a comatibility version is added.

This change also mitigates a potential memory-leak problem in nsv_dict with certain

versions of NaviServer which might lead on busy sites to problems.

  1. … 3 more files in changeset.
Stronger password hashes for OpenACS

This change introduces the possibility to use either the classical

OpenACS password hash algorithm "salted-sha1" or the SCRAM passord

function "scram-sha-256". The latter can be used by (a) using the

most recent version of NaviServer (from Sept 28, 2021 or newer) and

(b) by configuring the password hash preferences via Kernel package

parameter "PasswordHashAlgorithm". The package parameter can contain a

list of multiple hash algorithms in preference order. The most

preferred available algorithm is chosen.

By default, the "PasswordHashAlgorithm" is "salted-sha1", and the

behavior is as before. After upgrading to the new version of acs-tcl

and acs-kernel, the preference list can be configured. When a user

logs in and the preferred available algorithm is different from the

previously used algorithm, the upgrade is performed for the user

automatically.

The usage of SHA1 in OpenACS is easily target of security audits (see

[1]). The biggest danger is that if somebody gets full access to the

"users" table (e.g. when decommissioning a hard disk). In this case

the hashes can be attacked with dictionaries by using some crypto

hardware (when someone gets raw access to the DB, one has usually some

other big problems). However, by using the "scram-sha-256" hash

function this danger is substantially reduced. This function computes

a password hash using PBKDF2 (Password-Based Key Derivation Function

2). This function is used to reduce vulnerabilities of brute-force

attacks against password hashes. The hash function of SCRAM is PBKDF2

[RFC2898] with HMAC as the pseudorandom function (PRF) and with dkLen

== output length of HMAC == output length of the digest function. So,

it uses a better hash algorithm (sha-256 vs. sha1) and applies this a

high number of times (15K times for a password hash computation).

NaviServer supports as well the even better SCRYPT algorithm, but this

is only available when NaviServer is compiled with OpenSSL 3.0 or

newer. On the contrary, scram-sha-256 (actually PKCS5_PBKDF2_HMAC) is

available since OpenSSL 1.0.0 (2015).

All the improved hash functions require NaviServer with its tight

integration to the crypto functions of OpenSSL.

[1] https://openacs.org/forums/message-view?message_id=5522562

  1. … 6 more files in changeset.