Hello!
On Tue, Sep 18, 2018 at 08:12:20AM -0400, Thomas Ward wrote:
> Downstream in Ubuntu, it has been proposed to demote pcre3 and
> use pcre2 instead as it is newer.
> https://trac.nginx.org/nginx/ticket/720 shows it was marked 4
> years ago that NGINX does not support pcre2. Are there any
> plans to use pcre2 instead of pcre3?
There are no immediate plans.
When we last checked, there were no problems with PCRE, but PCRE2
wasn't available in most distributions we support, making the
switch mostly meaningless.
Also, it looks like PCRE2 is still not supported even by Exim,
which is the parent project of PCRE and PCRE2:
https://bugs.exim.org/show_bug.cgi?id=1878
As such, adding PCRE2 support to nginx looks premature.
--
Maxim Dounin
http://mdounin.ru/
Hello,
This patch applies cache locking behaviour to stale cache entries, so
in the case where the *_cache_lock directives are used, the same
locking behaviour is used for stale content as it is for new entries.
Previously, this was only done for new cache entries.
(see: http://mailman.nginx.org/pipermail/nginx/2016-January/049734.html)
This is useful when serving stale content is not permissable but sending
many requests upstream is undesriable.
This patch exposes the ngx_http_file_cache_lock function; this function
is then called in ngx_http_upstream if a cache entry has expired.
I have attached two versions of this patch, a "minimal" one that avoids
changes where not strictly necessary, and a "cleaner" version which is
more invasive but (in my opinion) cleaner.
Both patches cause no (additional) failures in the nginx test suite.
I tested with as many modules as I could reasonably enable.
Additionally, a colleague will add tests for this new behaviour in a
follow-up patch.
Regards, Elliot.
-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------
# HG changeset patch
# User Terence Honles <terence(a)honles.com>
# Date 1542840079 28800
# Wed Nov 21 14:41:19 2018 -0800
# Node ID 0763519f3dcce2c68ccd8894dcc02a4d6114b4c2
# Parent be5cb9c67c05ccaf22dab7abba78aa4c1545a8ee
better constrain IP-literal validation in ngx_http_validate_host()
The existing validation in ngx_http_validate_host() would allow a IP-literal
such as "[127.0.0.1]" which is invalid according to RFC 3986 (See Appendix A.
for the Collected ABNF). This format is intended for IPv6 and IPv-future not
IPv4.
The following changeset does the following:
- Terminates the validation loop if the state is `sw_rest` (If checking this
every character outweighs the benefit of early termination it can be
omitted).
- If a "." is found in an IPv6 literal or immediately after the initial "["
the hostname is determined to be invalid.
- If a "[" is found at any position other than the first character the
hostname is determined to be invalid.
- Adds a "sw_literal_start" state which branches to "sw_literal_ip_v6" or
"sw_literal_ip_future" depending if the character "v" is found at the start
of the IP-literal.
- If a non hex character (and not ":" because of the explicit case statement)
is found in an IPv6 literal the hostname is determined to be invalid.
- If the validation loop has not ended in either the "sw_usual" or "sw_rest"
state the hostname is determined to be invalid (This will occur in an
unterminated IP-literal)
This changeset *does not* aim to validate IPv-future as it is currently very
permissive and there is no pressing need for this validation.
diff -r be5cb9c67c05 -r 0763519f3dcc src/http/ngx_http_request.c
--- a/src/http/ngx_http_request.c Wed Nov 21 20:23:16 2018 +0300
+++ b/src/http/ngx_http_request.c Wed Nov 21 14:41:19 2018 -0800
@@ -1958,12 +1958,14 @@
static ngx_int_t
ngx_http_validate_host(ngx_str_t *host, ngx_pool_t *pool, ngx_uint_t alloc)
{
- u_char *h, ch;
+ u_char *h, c, ch;
size_t i, dot_pos, host_len;
enum {
sw_usual = 0,
- sw_literal,
+ sw_literal_start,
+ sw_literal_ip_v6,
+ sw_literal_ip_future,
sw_rest
} state;
@@ -1974,13 +1976,16 @@
state = sw_usual;
- for (i = 0; i < host->len; i++) {
+ for (i = 0; i < host->len && state != sw_rest; i++) {
ch = h[i];
switch (ch) {
case '.':
- if (dot_pos == i - 1) {
+ if (state == sw_literal_start
+ || state == sw_literal_ip_v6
+ || dot_pos == i - 1)
+ {
return NGX_DECLINED;
}
dot_pos = i;
@@ -1995,12 +2000,14 @@
case '[':
if (i == 0) {
- state = sw_literal;
+ state = sw_literal_start;
+ } else {
+ return NGX_DECLINED;
}
break;
case ']':
- if (state == sw_literal) {
+ if (state == sw_literal_ip_v6 || state == sw_literal_ip_future) {
host_len = i + 1;
state = sw_rest;
}
@@ -2015,6 +2022,17 @@
return NGX_DECLINED;
}
+ if (state == sw_literal_start) {
+ state = ch == 'v' ? sw_literal_ip_future : sw_literal_ip_v6;
+ }
+
+ if (state == sw_literal_ip_v6) {
+ c = (u_char) (ch | 0x20);
+ if (!((ch >= '0' && ch <= '9') || (c >= 'a' || c <= 'f'))) {
+ return NGX_DECLINED;
+ }
+ }
+
if (ch >= 'A' && ch <= 'Z') {
alloc = 1;
}
@@ -2023,6 +2041,10 @@
}
}
+ if (state != sw_usual && state != sw_rest) {
+ return NGX_DECLINED;
+ }
+
if (dot_pos == host_len - 1) {
host_len--;
}
A bug report originated on Debian [1] about the GeoIP module that's
shipped with NGINX's source code.
It makes note that the GeoIP database in Legacy format is not available,
deprecated in 2018 and discontinued as of 2019. This means that
non-paying customers can't get the database files. [2]
Does this impact the geoip module shipped with NGINX as the Legacy
databases are no longer available and discontinued? If so, does NGINX
have a timeline to replace this or provide alternate mechanisms?
Thomas
[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921034
[2]: https://support.maxmind.com/geolite-legacy-discontinuation-notice/
details: https://hg.nginx.org/nginx/rev/e72c8a8a8b10
branches:
changeset: 7454:e72c8a8a8b10
user: Maxim Dounin <mdounin(a)mdounin.ru>
date: Thu Jan 31 19:36:51 2019 +0300
description:
SSL: separate checks for errors in ngx_ssl_read_password_file().
Checking multiple errors at once is a bad practice, as in general
it is not guaranteed that an object can be used after the error.
In this particular case, checking errors after multiple allocations
can result in excessive errors being logged when there is no memory
available.
diffstat:
src/event/ngx_event_openssl.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diffs (20 lines):
diff --git a/src/event/ngx_event_openssl.c b/src/event/ngx_event_openssl.c
--- a/src/event/ngx_event_openssl.c
+++ b/src/event/ngx_event_openssl.c
@@ -947,10 +947,13 @@ ngx_ssl_read_password_file(ngx_conf_t *c
return NULL;
}
+ passwords = ngx_array_create(cf->temp_pool, 4, sizeof(ngx_str_t));
+ if (passwords == NULL) {
+ return NULL;
+ }
+
cln = ngx_pool_cleanup_add(cf->temp_pool, 0);
- passwords = ngx_array_create(cf->temp_pool, 4, sizeof(ngx_str_t));
-
- if (cln == NULL || passwords == NULL) {
+ if (cln == NULL) {
return NULL;
}