| Age | Commit message (Collapse) | Author |
|---|
|
Fixes: https://github.com/dillo-browser/dillo/issues/66
|
|
Implements support for brotli (br) content encoding.
Fixes: https://github.com/dillo-browser/dillo/issues/377
|
|
Allows inspecting their content before adding it to a feed reader by
reading it as plain text.
|
|
See: https://www.toomanyatoms.com/software/mobilized_dillo.html
Authored-By: dogma
|
|
|
|
Following https://datatracker.ietf.org/doc/html/rfc7230#section-5.3.1,
the path must not be empty, even if we have a query:
> If the target URI's path component is empty, the client MUST send "/"
> as the path within the origin-form of request-target.
Notice URIs can have empty paths, this is a restriction of HTTP only.
Fixes: https://github.com/dillo-browser/dillo/issues/302
|
|
When performing a HTTPS request over a HTTP proxy, a direct connection
is made to the remote server, so the GET line will be received as is.
Therefore we shouldn't send the full URL but just the path.
Fixes: https://github.com/dillo-browser/dillo/issues/279
|
|
When a error causes the TLS connection to fail and stop, the conn struct
is free on Tls_close_by_key(), so writing to conn->in_connect is not
correct after that point. The solution is to only set the flag when the
it is still valid.
Reported-by: Alex <a1ex@dismail.de>
Link: https://lists.mailman3.com/hyperkitty/list/dillo-dev@mailman3.com/thread/TY2JYCIPC7IQ32U6VC7ZOV3FVFFOE5K3/
|
|
Instead use inet_addr("127.0.0.1") which is POSIX 2001 and also more
clear.
Reviewed-by: dogma
|
|
Reviewed-by: dogma
|
|
Reviewed-by: dogma
|
|
Uses the nanosvg library to add SVG support.
See: https://www.toomanyatoms.com/software/mobilized_dillo.html
Authored-By: dogma
|
|
Some website endpoints return information in JSON, which is helpful to
be read as plain text in some situations. The content can still be
downloaded to disk using the save button or the context menu.
An example is the following endpoint https://tls.browserleaks.com/tls,
which provides TLS fingerprinting information in JSON, which will change
when reloading the page (only when Dillo is linked with LibreSSL).
The original page https://tls.browserleaks.com/ uses JS and cannot be
used in Dillo.
See: https://lists.mailman3.com/hyperkitty/list/dillo-dev@mailman3.com/message/6C5K4F6NBRUDSPNPWTXLQXCK3U3SI7DM/
|
|
When a positive non-zero value is returned from SSL_read or SSL_write,
there is data read or written, so there is no need to check for errors.
Only in the case the return value is 0 or negative.
|
|
It may be returned when the server closes the connection, see:
https://www.openssl.org/docs/manmaster/man3/SSL_get_error.html
We simply handle it as if there was no error and return zero bytes read.
Fixes: https://github.com/dillo-browser/dillo/issues/175
|
|
It would be nice if X509_ALGOR could be made opaque at some point.
There is a somewhat clumsy accessor X509_ALGOR_get0() that allows
obtaining the ASN1_OBJECT sitting inside an X509_ALGOR. Use this
instead.
|
|
In Mbed TLS 3.6.0 there is support for TLSv1.3 but it requires
special handling, so for now we disable it.
See: https://gitlab.alpinelinux.org/alpine/aports/-/commit/4dc36afaa81a4d73758b29fa77981d07dbae0080.patch
Fixes: https://github.com/dillo-browser/dillo/issues/158
|
|
|
|
The function SSL_get_peer_certificate() is deprecated in 3.0.0, but
still defined as a compatibility macro.
Fixes: https://github.com/dillo-browser/dillo/issues/118
|
|
|
|
|
|
We cannot rely on the return value and the errno, the function
SSL_get_error() must be used to determine what happen and if we need to
retry again. A wrapper function translates the SSL error into a proper
errno value.
In the case a premature EOF is sent by the server, the error queue is
emptied before the error is returned.
Fixes: https://github.com/dillo-browser/dillo/issues/79
|
|
As this is the page that new users will see for the first time, we want
to show them a very simple introduction so they can reach the full help
when they need it.
|
|
They may accidentally happen if a fd callback is still attached to the
connection socket while we wait in a FTLK dialog, causing another call
to Tls_connect() which will end up in an infinite loop.
|
|
Avoids calling the callback while the TLS dialog is opened, which was
causing and infinite loop of recursive calls to Tls_connect().
Fixes: https://github.com/dillo-browser/dillo/issues/49
|
|
Instead of just assert that there are no previous TLS errors, print the
error queue and then abort. It prevents the error queue to be emptied
before having a chance to see what error was stored.
|
|
More data will be written in the SSL_Shutdown() of TLS connections,
which causes errors if the file descriptor is closed. In particular,
LibreSSL will trigger an assert.
Fixes: https://github.com/dillo-browser/dillo/issues/51
|
|
The macro hides a return path and makes it more difficult to read the
condition as it is negated.
|
|
|
|
The website is now at https://dillo-browser.github.io/ and the
repository at https://github.com/dillo-browser/dillo.
|
|
|
|
Before OpenSSL 3.0, the EVP_PKEY_get_id() was named EVP_PKEY_id().
|
|
The SSLv23_client_method() function is deprecated:
https://www.openssl.org/docs/man3.2/man3/SSLv23_client_method.html
|
|
Brings the previous OpenSSL implementation into src/IO/tls_openssl.c.
Now, the TLS functions have the implementation name as prefix, like
a_Tls_openssl_connect().
The generic interface at IO/tls.h hides the implementation which is
selected at configure time. The appropriate functions of that
implementation are called from IO/tls.c to IO/tls_<impl>.c. In this way,
support for more TLS libraries can easily be added.
In the case of mbedTLS, there are some incompatible changes from version
2 to 3, so we use some ifdefs to fix the differences.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The handshake stuff should be named handshake. What should you call
initialize/setup plus handshake, then? I don't know, but 'connect'
for now, anyway.
|
|
as mentioned in the previous commit msg
|
|
Johannes reported that mbed TLS didn't like the connect() to be ongoing
still when the tls handshake was started on osx or dragonfly.
For an earlier version of the fix (which failed), it was basically free
to iterate through the IP address list upon connect() failure, so that
was implemented, and now I'm artificially breaking this patch into two
pieces to commit that separately.
|
|
You can trust an intermediate certificate in a chain, so let's be careful
with words here. It would of course be better to tell the user which
certificate was trusted in that case, but my understanding is that I would
have to go through each certificate in the chain and try to match it against
all of the trusted certificates, like mbed tls's verification code does in
the first place. This would involve a lot of digging around in mbed tls's
structures and using resources...
|
|
|
|
|
|
algorithms
|
|
|
|
|
|
reported by Nick Warne http://lists.dillo.org/pipermail/dillo-dev/2016-July/010941.html
checking mbedtls/ssl.h usability... no
checking mbedtls/ssl.h presence... yes
configure: WARNING: mbedtls/ssl.h: present but cannot be compiled
configure: WARNING: mbedtls/ssl.h: check for missing prerequisite headers?
configure: WARNING: mbedtls/ssl.h: see the Autoconf documentation
configure: WARNING: mbedtls/ssl.h: section "Present But Cannot Be Compiled"
configure: WARNING: mbedtls/ssl.h: proceeding with the compiler's result checking for mbedtls/ssl.h... no
configure: WARNING: *** mbed TLS 2 not found. Disabling SSL/HTTPS/TLS support. ***
|
