due to the use of an invalid macro HAVE_VSYSLOG_H (a corresponding
header doesn't exist on POSIX libcs, plus there was no configure
check setting it), the code here was never compiled in, and the
portable fallback was always used. since the fallback is already
there and known to work as intended, just use it always.
closes#574
This can be used to lint shell scripts
for syntactic correctness and style.
It requires shellcheck to be installed on the host.
Signed-off-by: Michael Adam <obnox@samba.org>
it turned out that a hashmap isn't the right datastructure, as the
special-case header Set-Cookie not only can, but is even heavily
recommended to be used multiple times.
we now use a dumb list as a key-value store for this purpose, but
restrict it to max 256 entries so the linear search can always be
completed in reasonable time in case of an attack.
closes#403
github continues to deprecate actions and idioms in their CI system.
hopefully these changes will last for a while and maintaining a simple
CI task doesn't turn into a neverending story.
given the catastrophic way TALOS Intelligence "communicated" with upstream
(i.e. by probably sending a single mail to an unused email address),
it's probably best to explicitly document how to approach upstream
when a security issue is discovered.
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1889
this bug was brought to my attention today by the debian tinyproxy
package maintainer. the above link states that the issue was known
since last year and that maintainers have been contacted, but if
that is even true then it probably was done via a private email
to a potentially outdated email address of one of the maintainers,
not through the channels described clearly on the tinyproxy homepage:
> Feel free to report a new bug or suggest features via github issues.
> Tinyproxy developers hang out in #tinyproxy on irc.libera.chat.
no github issue was filed, and nobody mentioned a vulnerability on
the mentioned IRC chat. if the issue had been reported on github or
IRC, the bug would have been fixed within a day.
since accept() uses the socklen parameter as in/out, after processing
an IPv4 the socklen fed to it waiting for the next client was only
the length of sockaddr_in, so if a connection from an IPv6 came in
the client sockaddr was only partially filled in.
this caused wrongly printed ipv6 addresses in log, and failure to
match them correctly against the acl.
closes#495
* tinyproxy.conf.5: document config strings that require double quotes
String config values matched by the STR regex must be enclosed in double
quotes
Edit descriptions for brevity
conf.c: move boolean arguments comment before BOOL group
addresses #491
* Revert conf.c: move boolean arguments comment before BOOL group
* Added support to configure IPv6 upstream proxy servers using bracket syntax.
* Added regular expression for IPv6 scope identifier to re for IPv6 address.
it's not possible to use a https url in a ReversePath directive, without
removing the security provided by https, and would require adding a
dependency on a TLS library like openssl and a lot of code complexity
to fetch the requested resource via https and relay it back to the client.
in case the reversepath directive kicked in, but the protocol wasn't
recognized, and support for transparent proxying built-in, the code
wrongfully tried to turn the request into a trans request, leading
to a bogus rewritten url like http://localhost:8888https://www.endpoint.com
and an error message that we're trying to connect to the machine the
proxy runs on.
now instead use the generic code that signals an invalid protocol/url
was used.
closes#419
while at it, the function doing it was renamed from the misleading
ssl name to what it actually does.
also inlined the strings that were previously defined as macros.
addressing #152
read_request_line() is exercised on the client's fd, and it fails
when the client closed the connection. therefore it's wrong
to send an error message to the client in this situation.
additionally, the error message states that the server closed
the connection.
might fix#383
as suggested in #212, it seems the majority of people don't understand
that input was expected to be in regex format and people were using
filter lists containing plain hostnames, e.g. `www.google.com`.
apart from that, using fnmatch() for matching is actually a lot less
computationally expensive and allows to use big blacklists without
incurring a huge performance hit.
the config file now understands a new option `FilterType` which can
be one of `bre`, `ere` and `fnmatch`.
The `FilterExtended` option was deprecated in favor of it.
It still works, but will be removed in the release after the next.
