uplex-varnish issueshttps://code.uplex.de/groups/uplex-varnish/-/issues2023-07-07T15:23:22Zhttps://code.uplex.de/uplex-varnish/libvmod-blobdigest/issues/2Document security considerations2023-07-07T15:23:22ZGeoff SimmonsDocument security considerationsA general statement about security seems appropriate, in addition to some specific comments:
* The VMOD implements HMAC with SHA3_*, but the "double hashing" isn't necessary, since SHA3 is not vulnerable to length extension attacks. It's sufficient to just concatenate the key with a message (initialize a digest object with the key in vcl_init).
* MD5 and SHA1 are for legacy, and should not be used in new code.
* CRC32 isn't crypto.Geoff SimmonsGeoff Simmonshttps://code.uplex.de/uplex-varnish/libvmod-blobdigest/issues/1Support SHAKE128, SHAKE256 and KMAC2018-04-07T23:12:32ZGeoff SimmonsSupport SHAKE128, SHAKE256 and KMACSHAKE128 and SHAKE256 have completed standardization by NIST, but the RHash code currently doesn't implement them. Should be possible with some tweaks to the code.
KMAC hasn't completed standardization yet, although its specs are probably settled -- the comments period for the draft standard expired on Sept 30th.Geoff SimmonsGeoff Simmonshttps://code.uplex.de/uplex-varnish/varnishevent/issues/1Assertion failure when no contents from the log are specified in any format s...2018-04-07T23:12:31ZGeoff SimmonsAssertion failure when no contents from the log are specified in any format stringNoticed by Nils with: ``-g raw`` and this configuration:
```
cformat=
rformat=fixed_string
```
That would have the effect of just emitting the fixed string for every raw transaction (possibly filtered by a query) -- obviously very much a corner case, but nevertheless varnishevent shouldn't crash.
```
#2 0x0000000000404e41 in assert_fail (func=0x411031 <__func__.6111> "main", file=0x41090a "varnishevent.c", line=930,
cond=0x410580 "!VSTAILQ_EMPTY(&rdr_rec_freelist) || (!VSB_EMPTY(config.cformat) && nonrecs_wanted[VSL_t_req]) || (!VSB_EMPTY(config.bformat) && nonrecs_wanted[VSL_t_bereq]) || (!VSB_EMPTY(config.rformat) && nonrecs_"..., err_e=<optimized out>) at varnishevent.c:569
#3 0x0000000000404615 in main (argc=<optimized out>, argv=<optimized out>) at varnishevent.c:927
```https://code.uplex.de/uplex-varnish/libvmod-blobcode/issues/3blob object constructor should use the static null_blob when blob length = 02018-04-07T23:12:31ZGeoff Simmonsblob object constructor should use the static null_blob when blob length = 0Currently the blob constructor creates a BLOB whose priv pointer is NULL when the encoding is the empty string:
```
new empty = blobcode.blob(encoded="");
```
An empty BLOB is a legitimate object, but priv==NULL does not play well with other VMODs expecting a BLOB.
The static `null_blob`, whose priv pointer points to the static constant empty string, was created for this purpose, and is returned by the `decode` function when the encoding is the empty string. The constructor should use it as well.Geoff SimmonsGeoff Simmonshttps://code.uplex.de/uplex-varnish/libvmod-backend_dyn/issues/3Add functions to serialize/deserialize backend configs so that Varnish can be...2018-04-07T23:12:31ZGeoff SimmonsAdd functions to serialize/deserialize backend configs so that Varnish can be safely restarted.Something like this:
```
# Write the current backend config to a file
backend_dyn.to_file(VCL_PRIV, "/path/to/backend.cfg");
sub vcl_init {
# Read any previous dynamic config from a file
# This restores any dynamic config that may have been written before Varnish stopped previously
backend_dyn.from_file(VCL_PRIV, "/path/to/backend.cfg");
}
```
The serialization format may or may not be identical to standard VCL syntax for static backend declarations. If it is, then an initial config can be saved in the file
before initial startup as standard VCL. This would have the advantage that statically declared backend configs could be manipulated by the VMOD after all (it's just that this particular VCL source is not used as the Varnish ``-f`` arg, nor is it included the ``-f`` arg or anything that it includes).Geoff SimmonsGeoff Simmonshttps://code.uplex.de/uplex-varnish/libvmod-pcre2/issues/1RFE: support DFA matching2018-04-07T23:12:31ZGeoff SimmonsRFE: support DFA matchingThis would make it possible to all matches found from a point in the subject. The interface would look something like:
```
$Method INT .nmatches()
$Method STRING .matchn(INT)
$Function INT nmatches(PRIV_TASK)
$Function STRING matchn(INT)
```
Geoff SimmonsGeoff Simmonshttps://code.uplex.de/uplex-varnish/libvmod-pcre2/issues/2RFE: support fast-path JIT matching2018-04-07T23:12:31ZGeoff SimmonsRFE: support fast-path JIT matching``fast_jit`` becomes a match option, just pass the flag into the static match function.Geoff SimmonsGeoff Simmonshttps://code.uplex.de/uplex-varnish/libvmod-pcre2/issues/3RFE: support the start_offset param for matching and substitutions2018-04-07T23:12:31ZGeoff SimmonsRFE: support the start_offset param for matching and substitutionsGeoff SimmonsGeoff Simmonshttps://code.uplex.de/uplex-varnish/libvmod-dispatch/issues/1RFE: add .string(n) methods for the both label and sub objects2018-04-07T23:12:31ZGeoff SimmonsRFE: add .string(n) methods for the both label and sub objectsThe methods `STRING .string(INT n)` return the name of the `n`th sub or label, as provided in the `.add()` methods at initialization time.
The string can be used for logging, for assigning the names to headers for tracing purposes, etc.Geoff SimmonsGeoff Simmons