- Dillo-dev - lists.mailman3.com

Re: Updated unveil patch

by a1ex＠dismail.de

Hi Rodrigo, On Sun, 28 Jul 2024 22:45:38 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi Alex, > > On Sun, Jul 28, 2024 at 07:14:04PM +0200, a1ex(a)dismail.de wrote: > >Hi, > > > >Here is a new patch. I have done quite a bit more work on this and > >think it may be close to completion. > > Thank you for the effort! I think this is getting in good shape. > > Some preliminary comments: > ... Well, you've certainly given me a lot to think about here! I had no idea this patch would get so complicated. Thanks for the review and tips. I will try to address some of these items individually, starting from the ones I feel most capable of. This is not exactly "baby's first patch" territory anymore :) Regards, Alex

July 29, 2024

Re: Updated unveil patch

by Rodrigo Arias

Hi Soléne, Happy to see you here! On Sun, Jul 28, 2024 at 09:31:24PM +0200, Solène Rapenne wrote: >you should provide a command line argument to disable sandboxing, so in case >of a problem users can run dillo without sandboxing and see if it works better, >allowing to figure if sandboxing is the root cause of their problem. I don't think there is a need to use a command line argument, as we can add a configuration option in ~/.dillo/dillorc to disable it. >what happens if you have no ~/.dillo when you start dillo with unveil? Dillo will first try to load ~/.dillo/dillorc, if that fails it will try $prefix/etc/dillo/dillorc, and if that fails too will use the internal defaults. I propose to let the default value for the unveil in the configuration option enabled by default (which will only take effect when unveil support is compiled in). To disable it for testing purposes one can edit $prefix/etc/dillo/dillorc or copy it to ~/.dillo/dillorc and change it there (this is the default workflow for other options too). >why do you need to unveil the same directories multiple times in the >code? Dillo is composed of several plugins that work as separate programs. Including a Dillo plugin daemon (dpid) and several other builtin programs (dpis). Each of those programs is being constrained with unveil differently, as they have different requirements. Best, Rodrigo.

July 28, 2024

Re: Updated unveil patch

by Rodrigo Arias

Hi Alex, On Sun, Jul 28, 2024 at 07:14:04PM +0200, a1ex(a)dismail.de wrote: >Hi, > >Here is a new patch. I have done quite a bit more work on this and >think it may be close to completion. Thank you for the effort! I think this is getting in good shape. Some preliminary comments: Even if you compile for OpenBSD, unveil() was not introduced until OpenBSD 6.4, so there is the possibility that is not available for an user building Dillo for an old OpenBSD. I recommend you add a configure switch (in configure.ac) to enable or disable unveil(). By default you can keep it disabled and let the user enable it manually, until we have more feedback to make it enabled by default. Maybe by defining ENABLE_UNVEIL? You can take the --enable-svg and ENABLE_SVG as an example. Dillo from OpenBSD ports may enable it by default adding --enable-unveil, so users test it without having to do any extra configuration. You should also make a dillorc configure option to enable/disable the unveil feature in runtime, so it can help debug problems. You can make the dillorc option enabled by default, which will only take action when unveil support has been compiled in. >The '~/Downloads' directory has been unveiled to match the behavior of >Firefox and Chromium on OpenBSD, but Dillo's default of '/tmp' >continues to work as well. The download directory is set in the dillorc configuration file, and can be any other place. Is it viable to read the configuration first and then unveil the appropriate directory? >I have also made sure everything works fine when there is no ~/.dillo >directory, Dillo can create it, and also can access the system defaults >in '/usr/local/etc/dillo'. This is also controlled by the prefix variable, which can be set to any other directory than /usr/local. This should be passed to the code to form the complete path, an example is the DILLO_DOCDIR which is defined as: -DDILLO_DOCDIR='"$(docdir)/"' In src/Makefile.am. You'll want to use the $(sysconfdir) autoconf variable: https://www.gnu.org/prep/standards/html_node/Directory-Variables.html#Direc… >dpid is also now unveiled, as well as all of the stock plugins except >hello.dpi, I didn't see any point to that. > >Here are some other tests which I have run: > >- Regular browsing works fine >- Connect to an FTP site and download a file, also view a text file and > view an image >- Open a text and image file from /tmp and ~/Downloads >- Add/remove bookmarks >- Download a file to /tmp and ~/Downloads >- Save a page to /tmp and ~/Downloads >- View source still works >- Fonts and cursor icons are working correctly >- data: uri works correctly with text and images > >So far everything seems to be fine. I will keep testing, but would >really appreciate some help with reviewing this, there could be some >edge-cases which I missed. As this won't be a simple patch, I suggest you open a PR in GitHub, so the CI can compile your patch revisions for multiple platforms and pass the tests. Otherwise I would have to spend the time to do it myself. I'm thinking if we can automate those tests in the CI. Probably we would need to add OpenBSD as a target first, as we only have FreeBSD. >Regards, >Alex > > > >diff -upr a/dpi/bookmarks.c b/dpi/bookmarks.c >--- a/dpi/bookmarks.c Sat Jun 29 16:33:08 2024 >+++ b/dpi/bookmarks.c Sun Jul 28 16:21:05 2024 >@@ -25,6 +25,7 @@ > #include <stddef.h> > #include <string.h> > #include <unistd.h> >+#include <err.h> > #include <errno.h> > #include <ctype.h> > #include <sys/socket.h> >@@ -1616,6 +1617,16 @@ int main(void) { > socklen_t address_size; > char *tok; > Dsh *sh; >+ >+ /* Use unveil on OpenBSD */ >+ #ifdef __OpenBSD__ >+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL); >+ if (unveil(dil_loc, "rwc") == -1) { >+ err(1, "unveil failed"); The err() function is non-portable, please use Dillo MSG* macros or perror() + exit(). This should be caught by the CI. Also, ensure the indentation is kept at 3 characters (not my decision). Would it make sense to add an unveil() wrapper? This would make it easier to integrate with other platforms than OpenBSD (and you also get the error checking in one place). Something like this: void dUnveil(const char *path, const char *perm) { #ifdef USE_UNVEIL #ifdef __OpenBSD__ if (unveil(path, perm) == -1) { MSG("unveil(%s, %s) failed: %s\n", path, perm, strerror(errno)); exit(1); } #endif /* Other platforms... */ #endif } Not sure if we can make all those repeated calls into something that we can reuse for all dpis and dillo main too. >+ } >+ dFree(dil_loc); >+ unveil(NULL, NULL); >+ #endif > > /* Arrange the cleanup function for terminations via exit() */ > atexit(cleanup); >diff -upr a/dpi/cookies.c b/dpi/cookies.c >--- a/dpi/cookies.c Sat Jun 29 16:33:08 2024 >+++ b/dpi/cookies.c Sun Jul 28 16:21:05 2024 >@@ -39,6 +39,7 @@ int main(void) > #include <fcntl.h> > #include <unistd.h> > #include <errno.h> >+#include <err.h> > #include <stddef.h> > #include <string.h> > #include <stdlib.h> >@@ -1643,6 +1644,16 @@ int main(void) { > int sock_fd, code; > char *buf; > Dsh *sh; >+ >+ /* Use unveil on OpenBSD */ >+ #ifdef __OpenBSD__ >+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL); >+ if (unveil(dil_loc, "rwc") == -1) { >+ err(1, "unveil failed"); >+ } >+ dFree(dil_loc); >+ unveil(NULL, NULL); >+ #endif > > /* Arrange the cleanup function for terminations via exit() */ > atexit(cleanup); >diff -upr a/dpi/datauri.c b/dpi/datauri.c >--- a/dpi/datauri.c Sat Jun 29 16:33:08 2024 >+++ b/dpi/datauri.c Sun Jul 28 16:21:05 2024 >@@ -12,6 +12,7 @@ > */ > > #include <unistd.h> >+#include <err.h> > #include <stdio.h> > #include <stdlib.h> > #include <string.h> >@@ -289,6 +290,19 @@ int main(void) > unsigned char *data; > int rc; > size_t data_size = 0; >+ >+ /* Use unveil on OpenBSD */ >+ #ifdef __OpenBSD__ >+ if (unveil("/tmp", "rwc") == -1) { >+ err(1, "unveil failed"); >+ } >+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL); >+ if (unveil(dil_loc, "rwc") == -1) { >+ err(1, "unveil failed"); >+ } >+ dFree(dil_loc); >+ unveil(NULL, NULL); >+ #endif > > /* Initialize the SockHandler */ > sh = a_Dpip_dsh_new(STDIN_FILENO, STDOUT_FILENO, 8*1024); >diff -upr a/dpi/downloads.cc b/dpi/downloads.cc >--- a/dpi/downloads.cc Sat Jun 29 16:33:08 2024 >+++ b/dpi/downloads.cc Sun Jul 28 16:21:05 2024 >@@ -18,6 +18,7 @@ > #include <stdlib.h> > #include <string.h> > #include <unistd.h> >+#include <err.h> > #include <errno.h> > #include <fcntl.h> > #include <ctype.h> >@@ -1104,6 +1105,38 @@ static void custLabelMeasure(const Fl_Label* o, >int& W int main() > { > int ww = 420, wh = 85; >+ >+ /* Use unveil on OpenBSD */ >+ #ifdef __OpenBSD__ >+ if (unveil("/tmp", "rwc") == -1) { >+ err(1, "unveil failed"); >+ } >+ if (unveil("/etc/fonts", "r") == -1) { >+ err(1, "unveil failed"); >+ } Not sure if you may need other user-defined places for fonts. >+ if (unveil("/usr/local/bin/wget", "x") == -1) { >+ err(1, "unveil failed"); >+ } You should find wget by locating it in the $PATH, not assuming it would be here. Users may place their own wget binary somewhere else and this would break the downloads. >+ char *xauth_loc = dStrconcat(dGethomedir(), "/.Xauthority", NULL); >+ if (unveil(xauth_loc, "r") == -1) { >+ err(1, "unveil failed"); >+ } The .Xauthority file should be read from $AUTHORITY and then from there if not set. >+ dFree(xauth_loc); >+ if (unveil("/usr/local/share/fonts", "r") == -1) { >+ err(1, "unveil failed"); >+ } Trailing whitespaces here^ >+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL); >+ if (unveil(dil_loc, "rwc") == -1) { >+ err(1, "unveil failed"); >+ } I'll suggest adding another rule to protect ~/.dillo/dillorc from modification. >+ dFree(dil_loc); >+ char *dl_loc = dStrconcat(dGethomedir(), "/Downloads", NULL); Same here, the downloads directory is given by the dillorc, you cannot assume it will be set there. >+ if (unveil(dl_loc, "rwc") == -1) { >+ err(1, "unveil failed"); >+ } >+ dFree(dl_loc); >+ unveil(NULL, NULL); >+ #endif > > Fl::lock(); > >diff -upr a/dpi/file.c b/dpi/file.c >--- a/dpi/file.c Sat Jun 29 16:33:08 2024 >+++ b/dpi/file.c Sun Jul 28 16:21:05 2024 >@@ -22,6 +22,7 @@ > #include <stdlib.h> > #include <string.h> > #include <unistd.h> >+#include <err.h> > #include <sys/select.h> > #include <sys/socket.h> > #include <sys/stat.h> >@@ -1070,6 +1071,23 @@ int main(void) > socklen_t sin_sz; > int sock_fd, c_st, st = 1; > >+ /* Use unveil on OpenBSD */ >+ #ifdef __OpenBSD__ >+ if (unveil("/tmp", "rw") == -1) { >+ err(1, "unveil failed"); >+ } >+ char *dl_loc = dStrconcat(dGethomedir(), "/Downloads", NULL); >+ if (unveil(dl_loc, "rw") == -1) { >+ err(1, "unveil failed"); >+ } >+ dFree(dl_loc); >+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL); >+ if (unveil(dil_loc, "rwc") == -1) { >+ err(1, "unveil failed"); >+ } Not sure if we want to constraint file:// like this. What if we are using Dillo to read local HTML files in ~/? >+ unveil(NULL, NULL); >+ #endif >+ > /* Arrange the cleanup function for abnormal terminations */ > if (signal (SIGINT, termination_handler) == SIG_IGN) > >diff -upr a/dpi/ftp.c b/dpi/ftp.c >--- a/dpi/ftp.c Sat Jun 29 16:33:08 2024 >+++ b/dpi/ftp.c Sun Jul 28 16:21:05 2024 >@@ -29,6 +29,7 @@ > */ > > #include <unistd.h> >+#include <err.h> > #include <sys/types.h> > #include <sys/socket.h> > #include <sys/un.h> >@@ -281,6 +282,28 @@ int main(int argc, char **argv) > char *dpip_tag = NULL, *cmd = NULL, *url = NULL, *url2 = NULL; > int st, rc; > char *p, *d_cmd; >+ >+ /* Use unveil on OpenBSD */ >+ #ifdef __OpenBSD__ >+ if (unveil("/tmp", "rwc") == -1) { >+ err(1, "unveil failed"); >+ } >+ if (unveil("/usr/local/bin/wget", "x") == -1) { >+ err(1, "unveil failed"); >+ } Notice wget may need ~/.netrc to access FTP files. But maybe it is good to leave it out. >+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL); >+ if (unveil(dil_loc, "rwc") == -1) { >+ err(1, "unveil failed"); >+ } >+ dFree(dil_loc); >+ char *dl_loc = dStrconcat(dGethomedir(), "/Downloads", NULL); >+ if (unveil(dl_loc, "rwc") == -1) { >+ err(1, "unveil failed"); >+ } >+ dFree(dl_loc); >+ unveil(NULL, NULL); >+ #endif >+ > > /* wget may need to write a temporary file... */ > rc = chdir("/tmp"); >diff -upr a/dpi/vsource.c b/dpi/vsource.c >--- a/dpi/vsource.c Sat Jun 29 16:33:08 2024 >+++ b/dpi/vsource.c Sun Jul 28 16:21:05 2024 >@@ -13,6 +13,7 @@ > */ > > #include <unistd.h> >+#include <err.h> > #include <sys/types.h> > #include <stdio.h> > #include <stdlib.h> >@@ -172,6 +173,16 @@ int main(void) > int data_size; > char *dpip_tag, *cmd = NULL, *cmd2 = NULL, *url = NULL, *size_str = >NULL; char *d_cmd; >+ >+ /* Use unveil on OpenBSD */ >+ #ifdef __OpenBSD__ >+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL); >+ if (unveil(dil_loc, "r") == -1) { >+ err(1, "unveil failed"); >+ } >+ dFree(dil_loc); >+ unveil(NULL, NULL); >+ #endif > > _MSG("starting...\n"); > //sleep(20); >diff -upr a/dpid/main.c b/dpid/main.c >--- a/dpid/main.c Sat Jun 29 16:33:08 2024 >+++ b/dpid/main.c Sun Jul 28 16:21:30 2024 >@@ -19,6 +19,7 @@ > > #include <errno.h> /* for ckd_write */ > #include <unistd.h> /* for ckd_write */ >+#include <err.h> > #include <stdlib.h> /* for exit */ > #include <assert.h> /* for assert */ > #include <sys/stat.h> /* for umask */ >@@ -236,6 +237,21 @@ int main(void) > services_list = NULL; > //daemon(0,0); /* Use 0,1 for feedback */ > /* TODO: call setsid() ?? */ >+ >+ /* Use unveil on OpenBSD */ >+ #ifdef __OpenBSD__ >+ if (unveil("/usr/local/lib/dillo", "rx") == -1) { >+ err(1, "unveil failed"); >+ } Plugins can also be found on the dpi_dir directory defined by the user in the .dillo/dpidrc, so we would need to parse it first. >+ if (unveil("/usr/local/etc/dillo", "r") == -1) { >+ err(1, "unveil failed"); >+ } >+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL); >+ if (unveil(dil_loc, "rwc") == -1) { I would also protect dpidrc from writing as well as dillorc. >+ err(1, "unveil failed"); >+ } >+ unveil(NULL, NULL); I assume exec dpis don't inherit the unveil() configuration (?) >+ #endif > > /* Allow read and write access, but only for the user. > * TODO: can this cause trouble with umount? */ >diff -upr a/src/dillo.cc b/src/dillo.cc >--- a/src/dillo.cc Sat Jun 29 16:33:08 2024 >+++ b/src/dillo.cc Sun Jul 28 16:33:29 2024 >@@ -23,6 +23,7 @@ > > #include <stdio.h> > #include <unistd.h> >+#include <err.h> > #include <stdlib.h> > #include <time.h> > #include <sys/types.h> >@@ -396,6 +397,47 @@ int main(int argc, char **argv) > > srand((uint_t)(time(0) ^ getpid())); > >+ // unveil() >+ #ifdef __OpenBSD__ >+ if (unveil("/usr/local/share/fonts", "r") == -1) { >+ err(1, "unveil failed"); >+ } >+ if (unveil("/usr/local/etc/dillo", "r") == -1) { >+ err(1, "unveil failed"); >+ } >+ if (unveil("/tmp", "rwc") == -1) { >+ err(1, "unveil failed"); >+ } >+ if (unveil("/usr/local/bin/dpid", "x") == -1) { >+ err(1, "unveil failed"); >+ } >+ if (unveil("/etc/fonts", "r") == -1) { >+ err(1, "unveil failed"); >+ } >+ if (unveil("/etc/resolv.conf", "r") == -1) { >+ err(1, "unveil failed"); >+ } >+ if (unveil("/etc/ssl/cert.pem", "r") == -1) { >+ err(1, "unveil failed"); >+ } >+ char *dl_loc = dStrconcat(dGethomedir(), "/Downloads", NULL); >+ if (unveil(dl_loc, "rwc") == -1) { >+ err(1, "unveil failed"); >+ } >+ dFree(dl_loc); >+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL); >+ if (unveil(dil_loc, "rwc") == -1) { >+ err(1, "unveil failed"); >+ } >+ dFree(dil_loc); >+ char *xauth_loc = dStrconcat(dGethomedir(), "/.Xauthority", NULL); > >+ if (unveil(xauth_loc, "r") == -1) { >+ err(1, "unveil failed"); >+ } >+ dFree(xauth_loc); >+ unveil(NULL, NULL); >+ #endif >+ > // Some OSes exit dillo without this (not GNU/Linux). > signal(SIGPIPE, SIG_IGN); > // Establish our custom SIGCHLD handler > >diff -upr a/dpi/bookmarks.c b/dpi/bookmarks.c >--- a/dpi/bookmarks.c Sat Jun 29 16:33:08 2024 >+++ b/dpi/bookmarks.c Sun Jul 28 16:21:05 2024 >@@ -25,6 +25,7 @@ > #include <stddef.h> > #include <string.h> > #include <unistd.h> >+#include <err.h> > #include <errno.h> > #include <ctype.h> > #include <sys/socket.h> >@@ -1616,6 +1617,16 @@ int main(void) { > socklen_t address_size; > char *tok; > Dsh *sh; >+ >+ /* Use unveil on OpenBSD */ >+ #ifdef __OpenBSD__ >+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL); >+ if (unveil(dil_loc, "rwc") == -1) { >+ err(1, "unveil failed"); >+ } >+ dFree(dil_loc); >+ unveil(NULL, NULL); >+ #endif > > /* Arrange the cleanup function for terminations via exit() */ > atexit(cleanup); >diff -upr a/dpi/cookies.c b/dpi/cookies.c >--- a/dpi/cookies.c Sat Jun 29 16:33:08 2024 >+++ b/dpi/cookies.c Sun Jul 28 16:21:05 2024 >@@ -39,6 +39,7 @@ int main(void) > #include <fcntl.h> > #include <unistd.h> > #include <errno.h> >+#include <err.h> > #include <stddef.h> > #include <string.h> > #include <stdlib.h> >@@ -1643,6 +1644,16 @@ int main(void) { > int sock_fd, code; > char *buf; > Dsh *sh; >+ >+ /* Use unveil on OpenBSD */ >+ #ifdef __OpenBSD__ >+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL); >+ if (unveil(dil_loc, "rwc") == -1) { >+ err(1, "unveil failed"); >+ } >+ dFree(dil_loc); >+ unveil(NULL, NULL); >+ #endif > > /* Arrange the cleanup function for terminations via exit() */ > atexit(cleanup); >diff -upr a/dpi/datauri.c b/dpi/datauri.c >--- a/dpi/datauri.c Sat Jun 29 16:33:08 2024 >+++ b/dpi/datauri.c Sun Jul 28 16:21:05 2024 >@@ -12,6 +12,7 @@ > */ > > #include <unistd.h> >+#include <err.h> > #include <stdio.h> > #include <stdlib.h> > #include <string.h> >@@ -289,6 +290,19 @@ int main(void) > unsigned char *data; > int rc; > size_t data_size = 0; >+ >+ /* Use unveil on OpenBSD */ >+ #ifdef __OpenBSD__ >+ if (unveil("/tmp", "rwc") == -1) { >+ err(1, "unveil failed"); >+ } >+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL); >+ if (unveil(dil_loc, "rwc") == -1) { >+ err(1, "unveil failed"); >+ } >+ dFree(dil_loc); >+ unveil(NULL, NULL); >+ #endif > > /* Initialize the SockHandler */ > sh = a_Dpip_dsh_new(STDIN_FILENO, STDOUT_FILENO, 8*1024); >diff -upr a/dpi/downloads.cc b/dpi/downloads.cc >--- a/dpi/downloads.cc Sat Jun 29 16:33:08 2024 >+++ b/dpi/downloads.cc Sun Jul 28 16:21:05 2024 >@@ -18,6 +18,7 @@ > #include <stdlib.h> > #include <string.h> > #include <unistd.h> >+#include <err.h> > #include <errno.h> > #include <fcntl.h> > #include <ctype.h> >@@ -1104,6 +1105,38 @@ static void custLabelMeasure(const Fl_Label* o, int& W > int main() > { > int ww = 420, wh = 85; >+ >+ /* Use unveil on OpenBSD */ >+ #ifdef __OpenBSD__ >+ if (unveil("/tmp", "rwc") == -1) { >+ err(1, "unveil failed"); >+ } >+ if (unveil("/etc/fonts", "r") == -1) { >+ err(1, "unveil failed"); >+ } >+ if (unveil("/usr/local/bin/wget", "x") == -1) { >+ err(1, "unveil failed"); >+ } >+ char *xauth_loc = dStrconcat(dGethomedir(), "/.Xauthority", NULL); >+ if (unveil(xauth_loc, "r") == -1) { >+ err(1, "unveil failed"); >+ } >+ dFree(xauth_loc); >+ if (unveil("/usr/local/share/fonts", "r") == -1) { >+ err(1, "unveil failed"); >+ } >+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL); >+ if (unveil(dil_loc, "rwc") == -1) { >+ err(1, "unveil failed"); >+ } >+ dFree(dil_loc); >+ char *dl_loc = dStrconcat(dGethomedir(), "/Downloads", NULL); >+ if (unveil(dl_loc, "rwc") == -1) { >+ err(1, "unveil failed"); >+ } >+ dFree(dl_loc); >+ unveil(NULL, NULL); >+ #endif > > Fl::lock(); > >diff -upr a/dpi/file.c b/dpi/file.c >--- a/dpi/file.c Sat Jun 29 16:33:08 2024 >+++ b/dpi/file.c Sun Jul 28 16:21:05 2024 >@@ -22,6 +22,7 @@ > #include <stdlib.h> > #include <string.h> > #include <unistd.h> >+#include <err.h> > #include <sys/select.h> > #include <sys/socket.h> > #include <sys/stat.h> >@@ -1070,6 +1071,23 @@ int main(void) > socklen_t sin_sz; > int sock_fd, c_st, st = 1; > >+ /* Use unveil on OpenBSD */ >+ #ifdef __OpenBSD__ >+ if (unveil("/tmp", "rw") == -1) { >+ err(1, "unveil failed"); >+ } >+ char *dl_loc = dStrconcat(dGethomedir(), "/Downloads", NULL); >+ if (unveil(dl_loc, "rw") == -1) { >+ err(1, "unveil failed"); >+ } >+ dFree(dl_loc); >+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL); >+ if (unveil(dil_loc, "rwc") == -1) { >+ err(1, "unveil failed"); >+ } >+ unveil(NULL, NULL); >+ #endif >+ > /* Arrange the cleanup function for abnormal terminations */ > if (signal (SIGINT, termination_handler) == SIG_IGN) > >diff -upr a/dpi/ftp.c b/dpi/ftp.c >--- a/dpi/ftp.c Sat Jun 29 16:33:08 2024 >+++ b/dpi/ftp.c Sun Jul 28 16:21:05 2024 >@@ -29,6 +29,7 @@ > */ > > #include <unistd.h> >+#include <err.h> > #include <sys/types.h> > #include <sys/socket.h> > #include <sys/un.h> >@@ -281,6 +282,28 @@ int main(int argc, char **argv) > char *dpip_tag = NULL, *cmd = NULL, *url = NULL, *url2 = NULL; > int st, rc; > char *p, *d_cmd; >+ >+ /* Use unveil on OpenBSD */ >+ #ifdef __OpenBSD__ >+ if (unveil("/tmp", "rwc") == -1) { >+ err(1, "unveil failed"); >+ } >+ if (unveil("/usr/local/bin/wget", "x") == -1) { >+ err(1, "unveil failed"); >+ } >+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL); >+ if (unveil(dil_loc, "rwc") == -1) { >+ err(1, "unveil failed"); >+ } >+ dFree(dil_loc); >+ char *dl_loc = dStrconcat(dGethomedir(), "/Downloads", NULL); >+ if (unveil(dl_loc, "rwc") == -1) { >+ err(1, "unveil failed"); >+ } >+ dFree(dl_loc); >+ unveil(NULL, NULL); >+ #endif >+ > > /* wget may need to write a temporary file... */ > rc = chdir("/tmp"); >diff -upr a/dpi/vsource.c b/dpi/vsource.c >--- a/dpi/vsource.c Sat Jun 29 16:33:08 2024 >+++ b/dpi/vsource.c Sun Jul 28 16:21:05 2024 >@@ -13,6 +13,7 @@ > */ > > #include <unistd.h> >+#include <err.h> > #include <sys/types.h> > #include <stdio.h> > #include <stdlib.h> >@@ -172,6 +173,16 @@ int main(void) > int data_size; > char *dpip_tag, *cmd = NULL, *cmd2 = NULL, *url = NULL, *size_str = NULL; > char *d_cmd; >+ >+ /* Use unveil on OpenBSD */ >+ #ifdef __OpenBSD__ >+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL); >+ if (unveil(dil_loc, "r") == -1) { >+ err(1, "unveil failed"); >+ } >+ dFree(dil_loc); >+ unveil(NULL, NULL); >+ #endif > > _MSG("starting...\n"); > //sleep(20); >diff -upr a/dpid/main.c b/dpid/main.c >--- a/dpid/main.c Sat Jun 29 16:33:08 2024 >+++ b/dpid/main.c Sun Jul 28 16:21:30 2024 >@@ -19,6 +19,7 @@ > > #include <errno.h> /* for ckd_write */ > #include <unistd.h> /* for ckd_write */ >+#include <err.h> > #include <stdlib.h> /* for exit */ > #include <assert.h> /* for assert */ > #include <sys/stat.h> /* for umask */ >@@ -236,6 +237,21 @@ int main(void) > services_list = NULL; > //daemon(0,0); /* Use 0,1 for feedback */ > /* TODO: call setsid() ?? */ >+ >+ /* Use unveil on OpenBSD */ >+ #ifdef __OpenBSD__ >+ if (unveil("/usr/local/lib/dillo", "rx") == -1) { >+ err(1, "unveil failed"); >+ } >+ if (unveil("/usr/local/etc/dillo", "r") == -1) { >+ err(1, "unveil failed"); >+ } >+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL); >+ if (unveil(dil_loc, "rwc") == -1) { >+ err(1, "unveil failed"); >+ } >+ unveil(NULL, NULL); >+ #endif > > /* Allow read and write access, but only for the user. > * TODO: can this cause trouble with umount? */ >diff -upr a/src/dillo.cc b/src/dillo.cc >--- a/src/dillo.cc Sat Jun 29 16:33:08 2024 >+++ b/src/dillo.cc Sun Jul 28 16:33:29 2024 >@@ -23,6 +23,7 @@ > > #include <stdio.h> > #include <unistd.h> >+#include <err.h> > #include <stdlib.h> > #include <time.h> > #include <sys/types.h> >@@ -396,6 +397,47 @@ int main(int argc, char **argv) > > srand((uint_t)(time(0) ^ getpid())); > >+ // unveil() >+ #ifdef __OpenBSD__ >+ if (unveil("/usr/local/share/fonts", "r") == -1) { >+ err(1, "unveil failed"); >+ } >+ if (unveil("/usr/local/etc/dillo", "r") == -1) { >+ err(1, "unveil failed"); >+ } >+ if (unveil("/tmp", "rwc") == -1) { >+ err(1, "unveil failed"); >+ } >+ if (unveil("/usr/local/bin/dpid", "x") == -1) { >+ err(1, "unveil failed"); >+ } >+ if (unveil("/etc/fonts", "r") == -1) { >+ err(1, "unveil failed"); >+ } >+ if (unveil("/etc/resolv.conf", "r") == -1) { >+ err(1, "unveil failed"); >+ } >+ if (unveil("/etc/ssl/cert.pem", "r") == -1) { >+ err(1, "unveil failed"); >+ } >+ char *dl_loc = dStrconcat(dGethomedir(), "/Downloads", NULL); >+ if (unveil(dl_loc, "rwc") == -1) { >+ err(1, "unveil failed"); >+ } >+ dFree(dl_loc); >+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL); >+ if (unveil(dil_loc, "rwc") == -1) { >+ err(1, "unveil failed"); >+ } >+ dFree(dil_loc); >+ char *xauth_loc = dStrconcat(dGethomedir(), "/.Xauthority", NULL); >+ if (unveil(xauth_loc, "r") == -1) { >+ err(1, "unveil failed"); >+ } >+ dFree(xauth_loc); >+ unveil(NULL, NULL); >+ #endif >+ > // Some OSes exit dillo without this (not GNU/Linux). > signal(SIGPIPE, SIG_IGN); > // Establish our custom SIGCHLD handler >_______________________________________________ >Dillo-dev mailing list -- dillo-dev(a)mailman3.com >To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

July 28, 2024

Re: Updated unveil patch

by Solène Rapenne

Le 28/07/2024 à 19:14, a1ex(a)dismail.de a écrit : > Hi, > > Here is a new patch. I have done quite a bit more work on this and > think it may be close to completion. > > The '~/Downloads' directory has been unveiled to match the behavior of > Firefox and Chromium on OpenBSD, but Dillo's default of '/tmp' > continues to work as well. > > I have also made sure everything works fine when there is no ~/.dillo > directory, Dillo can create it, and also can access the system defaults > in '/usr/local/etc/dillo'. > > dpid is also now unveiled, as well as all of the stock plugins except > hello.dpi, I didn't see any point to that. > > Here are some other tests which I have run: > > - Regular browsing works fine > - Connect to an FTP site and download a file, also view a text file and > view an image > - Open a text and image file from /tmp and ~/Downloads > - Add/remove bookmarks > - Download a file to /tmp and ~/Downloads > - Save a page to /tmp and ~/Downloads > - View source still works > - Fonts and cursor icons are working correctly > - data: uri works correctly with text and images > > So far everything seems to be fine. I will keep testing, but would > really appreciate some help with reviewing this, there could be some > edge-cases which I missed. > > Regards, > Alex > > you should provide a command line argument to disable sandboxing, so in case of a problem users can run dillo without sandboxing and see if it works better, allowing to figure if sandboxing is the root cause of their problem. what happens if you have no ~/.dillo when you start dillo with unveil? why do you need to unveil the same directories multiple times in the code?

July 28, 2024

Updated unveil patch

by a1ex＠dismail.de

Hi, Here is a new patch. I have done quite a bit more work on this and think it may be close to completion. The '~/Downloads' directory has been unveiled to match the behavior of Firefox and Chromium on OpenBSD, but Dillo's default of '/tmp' continues to work as well. I have also made sure everything works fine when there is no ~/.dillo directory, Dillo can create it, and also can access the system defaults in '/usr/local/etc/dillo'. dpid is also now unveiled, as well as all of the stock plugins except hello.dpi, I didn't see any point to that. Here are some other tests which I have run: - Regular browsing works fine - Connect to an FTP site and download a file, also view a text file and view an image - Open a text and image file from /tmp and ~/Downloads - Add/remove bookmarks - Download a file to /tmp and ~/Downloads - Save a page to /tmp and ~/Downloads - View source still works - Fonts and cursor icons are working correctly - data: uri works correctly with text and images So far everything seems to be fine. I will keep testing, but would really appreciate some help with reviewing this, there could be some edge-cases which I missed. Regards, Alex diff -upr a/dpi/bookmarks.c b/dpi/bookmarks.c --- a/dpi/bookmarks.c Sat Jun 29 16:33:08 2024 +++ b/dpi/bookmarks.c Sun Jul 28 16:21:05 2024 @@ -25,6 +25,7 @@ #include <stddef.h> #include <string.h> #include <unistd.h> +#include <err.h> #include <errno.h> #include <ctype.h> #include <sys/socket.h> @@ -1616,6 +1617,16 @@ int main(void) { socklen_t address_size; char *tok; Dsh *sh; + + /* Use unveil on OpenBSD */ + #ifdef __OpenBSD__ + char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL); + if (unveil(dil_loc, "rwc") == -1) { + err(1, "unveil failed"); + } + dFree(dil_loc); + unveil(NULL, NULL); + #endif /* Arrange the cleanup function for terminations via exit() */ atexit(cleanup); diff -upr a/dpi/cookies.c b/dpi/cookies.c --- a/dpi/cookies.c Sat Jun 29 16:33:08 2024 +++ b/dpi/cookies.c Sun Jul 28 16:21:05 2024 @@ -39,6 +39,7 @@ int main(void) #include <fcntl.h> #include <unistd.h> #include <errno.h> +#include <err.h> #include <stddef.h> #include <string.h> #include <stdlib.h> @@ -1643,6 +1644,16 @@ int main(void) { int sock_fd, code; char *buf; Dsh *sh; + + /* Use unveil on OpenBSD */ + #ifdef __OpenBSD__ + char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL); + if (unveil(dil_loc, "rwc") == -1) { + err(1, "unveil failed"); + } + dFree(dil_loc); + unveil(NULL, NULL); + #endif /* Arrange the cleanup function for terminations via exit() */ atexit(cleanup); diff -upr a/dpi/datauri.c b/dpi/datauri.c --- a/dpi/datauri.c Sat Jun 29 16:33:08 2024 +++ b/dpi/datauri.c Sun Jul 28 16:21:05 2024 @@ -12,6 +12,7 @@ */ #include <unistd.h> +#include <err.h> #include <stdio.h> #include <stdlib.h> #include <string.h> @@ -289,6 +290,19 @@ int main(void) unsigned char *data; int rc; size_t data_size = 0; + + /* Use unveil on OpenBSD */ + #ifdef __OpenBSD__ + if (unveil("/tmp", "rwc") == -1) { + err(1, "unveil failed"); + } + char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL); + if (unveil(dil_loc, "rwc") == -1) { + err(1, "unveil failed"); + } + dFree(dil_loc); + unveil(NULL, NULL); + #endif /* Initialize the SockHandler */ sh = a_Dpip_dsh_new(STDIN_FILENO, STDOUT_FILENO, 8*1024); diff -upr a/dpi/downloads.cc b/dpi/downloads.cc --- a/dpi/downloads.cc Sat Jun 29 16:33:08 2024 +++ b/dpi/downloads.cc Sun Jul 28 16:21:05 2024 @@ -18,6 +18,7 @@ #include <stdlib.h> #include <string.h> #include <unistd.h> +#include <err.h> #include <errno.h> #include <fcntl.h> #include <ctype.h> @@ -1104,6 +1105,38 @@ static void custLabelMeasure(const Fl_Label* o, int& W int main() { int ww = 420, wh = 85; + + /* Use unveil on OpenBSD */ + #ifdef __OpenBSD__ + if (unveil("/tmp", "rwc") == -1) { + err(1, "unveil failed"); + } + if (unveil("/etc/fonts", "r") == -1) { + err(1, "unveil failed"); + } + if (unveil("/usr/local/bin/wget", "x") == -1) { + err(1, "unveil failed"); + } + char *xauth_loc = dStrconcat(dGethomedir(), "/.Xauthority", NULL); + if (unveil(xauth_loc, "r") == -1) { + err(1, "unveil failed"); + } + dFree(xauth_loc); + if (unveil("/usr/local/share/fonts", "r") == -1) { + err(1, "unveil failed"); + } + char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL); + if (unveil(dil_loc, "rwc") == -1) { + err(1, "unveil failed"); + } + dFree(dil_loc); + char *dl_loc = dStrconcat(dGethomedir(), "/Downloads", NULL); + if (unveil(dl_loc, "rwc") == -1) { + err(1, "unveil failed"); + } + dFree(dl_loc); + unveil(NULL, NULL); + #endif Fl::lock(); diff -upr a/dpi/file.c b/dpi/file.c --- a/dpi/file.c Sat Jun 29 16:33:08 2024 +++ b/dpi/file.c Sun Jul 28 16:21:05 2024 @@ -22,6 +22,7 @@ #include <stdlib.h> #include <string.h> #include <unistd.h> +#include <err.h> #include <sys/select.h> #include <sys/socket.h> #include <sys/stat.h> @@ -1070,6 +1071,23 @@ int main(void) socklen_t sin_sz; int sock_fd, c_st, st = 1; + /* Use unveil on OpenBSD */ + #ifdef __OpenBSD__ + if (unveil("/tmp", "rw") == -1) { + err(1, "unveil failed"); + } + char *dl_loc = dStrconcat(dGethomedir(), "/Downloads", NULL); + if (unveil(dl_loc, "rw") == -1) { + err(1, "unveil failed"); + } + dFree(dl_loc); + char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL); + if (unveil(dil_loc, "rwc") == -1) { + err(1, "unveil failed"); + } + unveil(NULL, NULL); + #endif + /* Arrange the cleanup function for abnormal terminations */ if (signal (SIGINT, termination_handler) == SIG_IGN) diff -upr a/dpi/ftp.c b/dpi/ftp.c --- a/dpi/ftp.c Sat Jun 29 16:33:08 2024 +++ b/dpi/ftp.c Sun Jul 28 16:21:05 2024 @@ -29,6 +29,7 @@ */ #include <unistd.h> +#include <err.h> #include <sys/types.h> #include <sys/socket.h> #include <sys/un.h> @@ -281,6 +282,28 @@ int main(int argc, char **argv) char *dpip_tag = NULL, *cmd = NULL, *url = NULL, *url2 = NULL; int st, rc; char *p, *d_cmd; + + /* Use unveil on OpenBSD */ + #ifdef __OpenBSD__ + if (unveil("/tmp", "rwc") == -1) { + err(1, "unveil failed"); + } + if (unveil("/usr/local/bin/wget", "x") == -1) { + err(1, "unveil failed"); + } + char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL); + if (unveil(dil_loc, "rwc") == -1) { + err(1, "unveil failed"); + } + dFree(dil_loc); + char *dl_loc = dStrconcat(dGethomedir(), "/Downloads", NULL); + if (unveil(dl_loc, "rwc") == -1) { + err(1, "unveil failed"); + } + dFree(dl_loc); + unveil(NULL, NULL); + #endif + /* wget may need to write a temporary file... */ rc = chdir("/tmp"); diff -upr a/dpi/vsource.c b/dpi/vsource.c --- a/dpi/vsource.c Sat Jun 29 16:33:08 2024 +++ b/dpi/vsource.c Sun Jul 28 16:21:05 2024 @@ -13,6 +13,7 @@ */ #include <unistd.h> +#include <err.h> #include <sys/types.h> #include <stdio.h> #include <stdlib.h> @@ -172,6 +173,16 @@ int main(void) int data_size; char *dpip_tag, *cmd = NULL, *cmd2 = NULL, *url = NULL, *size_str = NULL; char *d_cmd; + + /* Use unveil on OpenBSD */ + #ifdef __OpenBSD__ + char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL); + if (unveil(dil_loc, "r") == -1) { + err(1, "unveil failed"); + } + dFree(dil_loc); + unveil(NULL, NULL); + #endif _MSG("starting...\n"); //sleep(20); diff -upr a/dpid/main.c b/dpid/main.c --- a/dpid/main.c Sat Jun 29 16:33:08 2024 +++ b/dpid/main.c Sun Jul 28 16:21:30 2024 @@ -19,6 +19,7 @@ #include <errno.h> /* for ckd_write */ #include <unistd.h> /* for ckd_write */ +#include <err.h> #include <stdlib.h> /* for exit */ #include <assert.h> /* for assert */ #include <sys/stat.h> /* for umask */ @@ -236,6 +237,21 @@ int main(void) services_list = NULL; //daemon(0,0); /* Use 0,1 for feedback */ /* TODO: call setsid() ?? */ + + /* Use unveil on OpenBSD */ + #ifdef __OpenBSD__ + if (unveil("/usr/local/lib/dillo", "rx") == -1) { + err(1, "unveil failed"); + } + if (unveil("/usr/local/etc/dillo", "r") == -1) { + err(1, "unveil failed"); + } + char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL); + if (unveil(dil_loc, "rwc") == -1) { + err(1, "unveil failed"); + } + unveil(NULL, NULL); + #endif /* Allow read and write access, but only for the user. * TODO: can this cause trouble with umount? */ diff -upr a/src/dillo.cc b/src/dillo.cc --- a/src/dillo.cc Sat Jun 29 16:33:08 2024 +++ b/src/dillo.cc Sun Jul 28 16:33:29 2024 @@ -23,6 +23,7 @@ #include <stdio.h> #include <unistd.h> +#include <err.h> #include <stdlib.h> #include <time.h> #include <sys/types.h> @@ -396,6 +397,47 @@ int main(int argc, char **argv) srand((uint_t)(time(0) ^ getpid())); + // unveil() + #ifdef __OpenBSD__ + if (unveil("/usr/local/share/fonts", "r") == -1) { + err(1, "unveil failed"); + } + if (unveil("/usr/local/etc/dillo", "r") == -1) { + err(1, "unveil failed"); + } + if (unveil("/tmp", "rwc") == -1) { + err(1, "unveil failed"); + } + if (unveil("/usr/local/bin/dpid", "x") == -1) { + err(1, "unveil failed"); + } + if (unveil("/etc/fonts", "r") == -1) { + err(1, "unveil failed"); + } + if (unveil("/etc/resolv.conf", "r") == -1) { + err(1, "unveil failed"); + } + if (unveil("/etc/ssl/cert.pem", "r") == -1) { + err(1, "unveil failed"); + } + char *dl_loc = dStrconcat(dGethomedir(), "/Downloads", NULL); + if (unveil(dl_loc, "rwc") == -1) { + err(1, "unveil failed"); + } + dFree(dl_loc); + char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL); + if (unveil(dil_loc, "rwc") == -1) { + err(1, "unveil failed"); + } + dFree(dil_loc); + char *xauth_loc = dStrconcat(dGethomedir(), "/.Xauthority", NULL); + if (unveil(xauth_loc, "r") == -1) { + err(1, "unveil failed"); + } + dFree(xauth_loc); + unveil(NULL, NULL); + #endif + // Some OSes exit dillo without this (not GNU/Linux). signal(SIGPIPE, SIG_IGN); // Establish our custom SIGCHLD handler

July 28, 2024

Re: Does :hover work in 3.1.1?

by Steinar Bang

>>>>> Rodrigo Arias <rodarima(a)gmail.com>: > You may want to check: > https://dillo-browser.github.io/dillo.org.html > And: > https://dillo-browser.github.io/release/3.1.0/ Right! I knew that actually, from the mastodon post that brought dillo back into my attention. But when looking for stuff I am lazy and I google rather than remembering, and google still throw up the old pages. I'll link to the updated dillo doc from the oldalbum README when I release the non-javascript version. That should help the teensiest bit, at least (also it's a place I can click to to get there). >> If :hover doesn't work I will have to do it a different way: maybe with >> a separate settings page containing a form...? > I recommend you just don't use a drop down, just an static navigation > menu which would work fine with CSS disabled. Yup, the simplest way would be to have just two links in the <nav> one for each locale/language. But that would be too much clutter, I think...? > You could also use a <select> input with a form but it looks more > complicated. Yes, it is. But it's the road I've started to travel. :-) (remains to see if I will travel it to the end or cut my losses and do something simpler...:-) ) I have some copy-pastable code. I did the authservice login and basic self-service pages non-javascript (authservice started as a forms based login plugin for nginx, using apache shiro), and I have stuff I can copy paste from there: https://github.com/steinarb/authservice I don't like JSP or JSF (feels complicated and cluttered) so I did a simple DIY templating with jersey and jsoup (I write HTML pages and read them into jersey resources with jsoup and replace elment content and fill forms). I was looking for sort of the same feel I had when using CGI.pm back in the day: the state is contained in the form data and used to populate the form in the returned HTML, and jsoup gave me that. The use of jersey is because JAX-RS gives a convenient API to tailor responses (HTTP headers and stuff).

July 27, 2024

Re: Does :hover work in 3.1.1?

by Rodrigo Arias

Hi, On Fri, Jul 26, 2024 at 07:09:05PM +0200, Steinar Bang wrote: >Does :hover work in 3.1.1? No, its not implemented, only ":link" and ":visited": https://github.com/dillo-browser/dillo/blob/v3.1.1/src/cssparser.cc#L1426-L… >I am trying to write a JavaScript-less dropdown to switch locale as >e.g. outlined here: > https://www.w3schools.com/howto/tryit.asp?filename=tryhow_js_responsive_nav… > >Short story: the dropdown is an ul with "display: none" and hovering >over a parent element (that is displayed) is supposed to switch to >"display: block". > >But nothing happens when I hover over the parent. > >Google found me this, dated August 19 2022, listing pseudo-classes as >Pending, but August 19 2022 is almost two years ago...? > https://dillo.org/css.html >(looks like that "Pending" may be from January 1 2015...?) You may want to check: https://dillo-browser.github.io/dillo.org.html And: https://dillo-browser.github.io/release/3.1.0/ >If :hover doesn't work I will have to do it a different way: maybe with >a separate settings page containing a form...? I recommend you just don't use a drop down, just an static navigation menu which would work fine with CSS disabled. You could also use a <select> input with a form but it looks more complicated. >Here is the HTML of the dropdown: > <li> > <div class="locale-dropdown"> > <a href="">Language</a> > <ul class="locale-dropdown-content"> > <li><a href="">English</a></li> > <li><a href="">norsk bokmål</a></li> > </ul> > </div> > </li> > >(the dropdown is nested in a <li> that is part of the <ul> that forms the <nav>) > >The CSS looks like this: > >.locale-dropdown-content { > display: none; > position: absolute; > background-color: #f9f9f9; > min-width: 160px; > box-shadow: 0px 8px 16px 0px rgba(0,0,0,0.2); > z-index: 1; >} > >.locale-dropdown:hover .locale-dropdown-content { > display: block; >} > >_______________________________________________ >Dillo-dev mailing list -- dillo-dev(a)mailman3.com >To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

July 26, 2024

Does :hover work in 3.1.1?

by Steinar Bang

Does :hover work in 3.1.1? I am trying to write a JavaScript-less dropdown to switch locale as e.g. outlined here: https://www.w3schools.com/howto/tryit.asp?filename=tryhow_js_responsive_nav… Short story: the dropdown is an ul with "display: none" and hovering over a parent element (that is displayed) is supposed to switch to "display: block". But nothing happens when I hover over the parent. Google found me this, dated August 19 2022, listing pseudo-classes as Pending, but August 19 2022 is almost two years ago...? https://dillo.org/css.html (looks like that "Pending" may be from January 1 2015...?) If :hover doesn't work I will have to do it a different way: maybe with a separate settings page containing a form...? Here is the HTML of the dropdown: <li> <div class="locale-dropdown"> <a href="">Language</a> <ul class="locale-dropdown-content"> <li><a href="">English</a></li> <li><a href="">norsk bokmål</a></li> </ul> </div> </li> (the dropdown is nested in a <li> that is part of the <ul> that forms the <nav>) The CSS looks like this: .locale-dropdown-content { display: none; position: absolute; background-color: #f9f9f9; min-width: 160px; box-shadow: 0px 8px 16px 0px rgba(0,0,0,0.2); z-index: 1; } .locale-dropdown:hover .locale-dropdown-content { display: block; }

July 26, 2024

Re: Is CSS inline-block on <ul> supposed to work

by Steinar Bang

>>>>> Rodrigo Arias <rodarima(a)gmail.com>: >> nav.image-navbar ul li { >> float: left; > Replace this with "display: inline-block;" and should work. Thanks! Moving "display: inline-block;" from <ul> to <li> worked! The <li> elements were displayed horizontally in the navbar I removed "vertical-align: top" since it didn't have any effect that I could see. Here is the full CSS for the <nav> (so far): nav.image-navbar { background-color: lightgray; padding-bottom: 10px; } nav.image-navbar ul { list-style-type: none; margin: 0; padding: 0; } nav.image-navbar ul li { display: inline-block; } Thanks again! - Steinar

July 26, 2024

Re: Is CSS inline-block on <ul> supposed to work

by Rodrigo Arias

Hi, >nav.image-navbar ul li { > float: left; Replace this with "display: inline-block;" and should work. Rodrigo.

July 26, 2024

Is CSS inline-block on <ul> supposed to work

by Steinar Bang

dillo 3.1.1, debian 12.6 "bookworm", amd64 I am trying to create a <nav> "powered by" an <ul>: <nav class="image-navbar"> <ul> <li><a href="blah">item 1</a></li> <li><a href="bluh">item 2</a></li> </ul> </nav> But I am unable to make the <ul> render horizontally. Is "display: inline-bloc" supposed to work on dillo 3.1.1? Here's the CSS I've tried: nav.image-navbar { background-color: lightgray; padding-bottom: 10px; } nav.image-navbar ul { list-style-type: none; display: inline-block; vertical-align: top; margin: 0; padding: 0; } nav.image-navbar ul li { float: left; } Thanks! - Steinar

July 26, 2024

Unveil Dillo (new patch)

by a1ex＠dismail.de

Hi list, Here is an updated patch which now just does unveil (no pledge). I have tightened up the permissions so that Dillo only has the minimum of filesystem access, just enough so that everything still (hopefully) works. Testers and comments welcome. There probably aren't many OpenBSD users on this list, so I will eventually submit this to the OpenBSD ports list for further review. --- a/src/dillo.cc Thu Jul 25 21:21:14 2024 +++ b/src/dillo.cc Thu Jul 25 21:28:54 2024 @@ -23,6 +23,7 @@ #include <stdio.h> #include <unistd.h> +#include <err.h> #include <stdlib.h> #include <time.h> #include <sys/types.h> @@ -396,6 +397,41 @@ int main(int argc, char **argv) srand((uint_t)(time(0) ^ getpid())); + // unveil() + if (unveil("/usr/local/share/fonts", "r") == -1) { + err(1, "unveil failed"); + } + if (unveil("/tmp", "rw") == -1) { + err(1, "unveil failed"); + } + if (unveil("/usr/local/bin/dpid", "x") == -1) { + err(1, "unveil failed"); + } + if (unveil("/etc/fonts", "r") == -1) { + err(1, "unveil failed"); + } + if (unveil("/etc/resolv.conf", "r") == -1) { + err(1, "unveil failed"); + } + if (unveil("/etc/ssl/cert.pem", "r") == -1) { + err(1, "unveil failed"); + } + char *dl_loc = dStrconcat(dGethomedir(), "/Downloads", NULL); + if (unveil(dl_loc, "rw") == -1) { + err(1, "unveil failed"); + } + dFree(dl_loc); + char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL); + if (unveil(dil_loc, "rwc") == -1) { + err(1, "unveil failed"); + } + dFree(dil_loc); + char *xauth_loc = dStrconcat(dGethomedir(), "/.Xauthority", NULL); + if (unveil(xauth_loc, "r") == -1) { + err(1, "unveil failed"); + } + dFree(xauth_loc); + // Some OSes exit dillo without this (not GNU/Linux). signal(SIGPIPE, SIG_IGN); // Establish our custom SIGCHLD handler The only small issue I see so far is that the ~/Downloads directory is now hardcoded, and so the 'save_dir' preference in dillorc will need to match. Also note that in order to be able to use Rodrigo's multiple-actions patch with this, or my external link handler patch, you will also need to add: if (unveil("/bin/sh", "x") == -1) { err(1, "unveil failed"); } But that's not really advisable if you are looking for maximum security. EDIT: I just realized we may need to unveil dpid as well. Since it's a separate process, I don't think it inherits the unveil from dillo.cc. For example, when I use the 'Open file...' dialog, I am unable to see the restricted directories. However, when I load 'file:/home/user' in the browser, the contents still show up. Back to the drawing board! I will try to look at that in the next few days if possible. Regards, Alex

July 25, 2024

Re: Hardening Dillo with unveil and pledge

by Rodrigo Arias

Hi Alex, On Sun, Jul 21, 2024 at 07:31:29PM +0200, a1ex(a)dismail.de wrote: >Hi Rodrigo, > >On Sun, 21 Jul 2024 13:33:32 +0200 >Rodrigo Arias <rodarima(a)gmail.com> wrote: > >> I can see clear benefits on restricting the file system access, but >> do you have in mind which type of attack the pledge() configuration >> would you help mitigate? > >It might reduce the attack surface for exploits in things like image and >compression libraries. Or maybe there could be a bug in FLTK. Or in >Dillo itself. I'm not saying these things are very likely, but they >are possible. Since Dillo is a complicated program, we have to grant it >access to lot of syscalls, which limits how effective pledge can be. >But it still offers a level of protection which can be valuable in >various scenerios. Sorry, I think I didn't explained myself very clearly :-) With "which type of attack the pledge() configuration would you help mitigate?", I meant: if using your current configuration of "stdio rpath wpath cpath inet unix dns tty proc prot_exec" you have in mind an specific attack that we can mitigate, as this is giving Dillo access to a lot of syscalls which can be used to easily exploit any bugs. Also, I think it is very likely we have some exploitable bugs laying around in the parsers and other parts of the code and I don't think we will be able to use pledge effectively until we change the design to be able to split Dillo in more than one process. But maybe there is some exploitation that we can prevent right now with that combination that I'm not aware of. Otherwise I'm not sure if it is worth using pledge(2) as-is, until we change Dillo design so it is more effective. However, I think using unveil(2) is an effective way of restricting a lot of attack surface and doesn't require any design change. Maybe it would be better to start with unveil(2) alone and think later how to approach pledge(2). In Linux there is Landlock[1] (and also a project to implement an API like unveil on top of Landlock[2]), so it should be possible to at least implement support for OpenBSD and Linux to restrict access to the FS. [1]: https://landlock.io/ [2]: https://github.com/marty1885/landlock-unveil >Regarding something you said earlier: > >> I believe it would be nice to move the network facing code away from >> the parsers, so the parser code cannot use the network or read the >> file system. This requires separating them in different processes. > >This sounds like a very reasonable approach which would benefit all >Dillo users and not just the small minority who have access to pledge >and unveil. This is something I'm considering addressing already in RFC-002, as we will have to change the way Dillo exchanges data internally, we can move to a message passing design. While right now we will continue to use a single process, this design could potentially run over different processes, and then we could use pledge(2), seccomp(2) or other OS protection mechanisms for the untrusted code. I think it is important to remember that Dillo is a *multiplatform* browser, and it would be nice if security features are be available in all supported platforms. If you want to add support for unveil(2), I recommend you do that in the Dillo git repository with an #ifdef guard, so it can be enabled only if build for OpenBSD, and with some way to enable/disable it for testing. I can help you with this part if you are not familiar with autoconf. Then we can see how to add similar protection for other operating systems. Best, Rodrigo.

July 25, 2024

Re: Hardening Dillo with unveil and pledge

by a1ex＠dismail.de

Hi Rodrigo, On Sun, 21 Jul 2024 13:33:32 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > I can see clear benefits on restricting the file system access, but > do you have in mind which type of attack the pledge() configuration > would you help mitigate? It might reduce the attack surface for exploits in things like image and compression libraries. Or maybe there could be a bug in FLTK. Or in Dillo itself. I'm not saying these things are very likely, but they are possible. Since Dillo is a complicated program, we have to grant it access to lot of syscalls, which limits how effective pledge can be. But it still offers a level of protection which can be valuable in various scenerios. > I think allowing exec and inet is too permissive and would allow an > attacker to easily spawn a remote shell as soon as a RCE bug is > found. I agree about exec, but right now without inet Dillo fails to start. One drawback to this current implementation is that things like my external link handler patch, and your multiple-actions patch don't work anymore. I ran some tests and confirmed that it causes issues, even with exec pledged. Maybe it would be possible to work around that with an un-pledged process which does the call, which would have to be started by Dillo prior to the pledge call in main. I did some experiments with initializing dpid prior to the pledge call being made, so that it can run un-pledged. It seems possible, but may require other changes which seem to be above my current skill level. > I think is a good idea more OpenBSD people review this part, as I'm > not very familiar with pledge(2). > > However, I'm afraid having this patch only in OpenBSD may cause a > negative effect, as we may start receiving bug reports that are only > happening on OpenBSD with that patch and cannot be reproduced on > Linux or other systems without it. > > Maybe you can make a hardened Dillo port, so people can still test > the non-hardened port to determine if the problem comes from these > changes. I will have to think a bit on that, but maybe I'll start by forwarding this thread to some OpenBSD people and see what kind of response comes back. Really not sure how much interest there will be in this, as I suspect the amount of developers who use Dillo on OpenBSD is not huge. Hopefully I'm wrong. :) Regarding something you said earlier: > I believe it would be nice to move the network facing code away from > the parsers, so the parser code cannot use the network or read the > file system. This requires separating them in different processes. This sounds like a very reasonable approach which would benefit all Dillo users and not just the small minority who have access to pledge and unveil. -Alex

July 21, 2024

Re: Hardening Dillo with unveil and pledge

by Rodrigo Arias

Hi Alex, On Sat, Jul 20, 2024 at 09:03:48PM +0200, a1ex(a)dismail.de wrote: >Hi Rodrigo, > >On Sat, 20 Jul 2024 16:34:47 +0200 >Rodrigo Arias <rodarima(a)gmail.com> wrote: > >> >+ if (unveil("/home", "rwc") == -1) { >> >> We may want to constraint this a bit further, so a malicious actor >> cannot read anything from /home/.config. Maybe only /home/.dillo and >> the downloads directory would be suitable? > >Absolutely, that was my initial intention, but just wanted to keep the >example patch as simple as possible. There are a number of things in >$HOME which we probably don't want the browser having access to. Ups, I meant $HOME, not /home :-) There is a dGethomedir() function in dlib/dlib.h to help with this, which also works with other systems. >> >+ if (pledge("stdio rpath wpath cpath inet unix dns tty proc >> >prot_exec", >> >> Does this work with plugins, when the dpid daemon is not running?, as >> I believe it has to fork and exec the dpid program. > >I started with a mindset of "whats the bare minimum of permissions we >can get away with". But its clear that we would need "exec" as well for >full functionality. I can see clear benefits on restricting the file system access, but do you have in mind which type of attack the pledge() configuration would you help mitigate? I think allowing exec and inet is too permissive and would allow an attacker to easily spawn a remote shell as soon as a RCE bug is found. Maybe we can remove exec by spawning first the dpid daemon and then restricting the exec syscall with pledge. Currently it is only started when a request to a dpi plugin via a_Dpi_ccc(). >At some point I may try to submit an improved patch to the OpenBSD >ports maintainers. Unfortunately that won't do much for users of Linux >and other systems. I think is a good idea more OpenBSD people review this part, as I'm not very familiar with pledge(2). However, I'm afraid having this patch only in OpenBSD may cause a negative effect, as we may start receiving bug reports that are only happening on OpenBSD with that patch and cannot be reproduced on Linux or other systems without it. Maybe you can make a hardened Dillo port, so people can still test the non-hardened port to determine if the problem comes from these changes. This could be also controlled by a dillorc option (Dillo shouldn't be able to write dillorc), so it can be disabled for testing. The latter could be applied to upstream Dillo if we allow compiling the pledge part conditionally and would benefit from the CI tests on BSD too. Best, Rodrigo.

July 21, 2024

Re: Hardening Dillo with unveil and pledge

by a1ex＠dismail.de

Hi Rodrigo, On Sat, 20 Jul 2024 16:34:47 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > >+ if (unveil("/home", "rwc") == -1) { > > We may want to constraint this a bit further, so a malicious actor > cannot read anything from /home/.config. Maybe only /home/.dillo and > the downloads directory would be suitable? Absolutely, that was my initial intention, but just wanted to keep the example patch as simple as possible. There are a number of things in $HOME which we probably don't want the browser having access to. > >+ if (pledge("stdio rpath wpath cpath inet unix dns tty proc > >prot_exec", > > Does this work with plugins, when the dpid daemon is not running?, as > I believe it has to fork and exec the dpid program. I started with a mindset of "whats the bare minimum of permissions we can get away with". But its clear that we would need "exec" as well for full functionality. At some point I may try to submit an improved patch to the OpenBSD ports maintainers. Unfortunately that won't do much for users of Linux and other systems. -Alex

July 20, 2024

Re: Hardening Dillo with unveil and pledge

by Rodrigo Arias

Hi Alex, On Sat, Jul 20, 2024 at 04:02:54PM +0200, a1ex(a)dismail.de wrote: >Hi list, > >I have been experimenting with unveil[1] and pledge[2] on Dillo to >reduce possible attack surface. Right now these system calls are >exclusive to OpenBSD, but there are projects[3] working to bring them to >Linux and other systems. > >Basically, unveil restricts which areas of the filesystem a program can >access, and pledge restricts which system calls the program is allowed >to make. > >[1] https://man.openbsd.org/unveil.2 >[2] https://man.openbsd.org/pledge.2 >[3] https://justine.lol/pledge/ > >Initial testing indicates that both of these features are working >correctly with Dillo. I am including a patch which provides some basic >filesystem protection, and limits Dillo to the minimum amount of >syscalls possible. If anyone has questions or comments, they are >welcome. Thanks for the patch, I had just opened an issue on this topic a few days ago: https://github.com/dillo-browser/dillo/issues/225 I believe it would be nice to move the network facing code away from the parsers, so the parser code cannot use the network or read the file system. This requires separating them in different processes. I also have to take a look at Justine implementation of pledge(2) for Linux. Constraining the current design may already lead to some improvement. >+ if (unveil("/home", "rwc") == -1) { We may want to constraint this a bit further, so a malicious actor cannot read anything from /home/.config. Maybe only /home/.dillo and the downloads directory would be suitable? >+ if (pledge("stdio rpath wpath cpath inet unix dns tty proc prot_exec", Does this work with plugins, when the dpid daemon is not running?, as I believe it has to fork and exec the dpid program. Easy test: $ dpidc stop $ dillo dpi:/bm/ Best, Rodrigo.

July 20, 2024

Hardening Dillo with unveil and pledge

by a1ex＠dismail.de

Hi list, I have been experimenting with unveil[1] and pledge[2] on Dillo to reduce possible attack surface. Right now these system calls are exclusive to OpenBSD, but there are projects[3] working to bring them to Linux and other systems. Basically, unveil restricts which areas of the filesystem a program can access, and pledge restricts which system calls the program is allowed to make. [1] https://man.openbsd.org/unveil.2 [2] https://man.openbsd.org/pledge.2 [3] https://justine.lol/pledge/ Initial testing indicates that both of these features are working correctly with Dillo. I am including a patch which provides some basic filesystem protection, and limits Dillo to the minimum amount of syscalls possible. If anyone has questions or comments, they are welcome. Regards, Alex --- a/src/dillo.cc Fri Jun 14 22:27:18 2024 +++ b/src/dillo.cc Sat Jul 20 15:16:42 2024 @@ -24,6 +24,7 @@ #include <stdio.h> #include <unistd.h> +#include <err.h> #include <stdlib.h> #include <time.h> #include <sys/types.h> @@ -397,6 +398,24 @@ int main(int argc, char **argv) FILE *fp; srand((uint_t)(time(0) ^ getpid())); + + // Unveil and Pledge + if (unveil("/usr", "rx") == -1) { + err(1, "unveil failed"); + } + if (unveil("/tmp", "rwc") == -1) { + err(1, "unveil failed"); + } + if (unveil("/etc", "r") == -1) { + err(1, "unveil failed"); + } + if (unveil("/home", "rwc") == -1) { + err(1, "unveil failed"); + } + if (pledge("stdio rpath wpath cpath inet unix dns tty proc prot_exec", + NULL) == -1) { + err(1, "pledge failed"); + } // Some OSes exit dillo without this (not GNU/Linux). signal(SIGPIPE, SIG_IGN);

July 20, 2024

Re: [PATCH] Toolbar zoom control button

by Rodrigo Arias

Hi, On Sun, Jul 14, 2024 at 07:02:50PM +0200, a1ex(a)dismail.de wrote: >Hi list, > >Here is an improved version of my previous patch. > >The icon is fixed, it's basic but does the job. If someone wants to >make a prettier one, I'm open to it. > >Other improvements as discussed with Rodrigo: > >- Middle click resets zoom level >- There is now a 'show_zoom' preference in dillorc (enabled by default) >- The save button has been disabled by default >- The zoom button has been moved to the right of the refresh button > >Please let me know if you find any issues, and hope you enjoy it :) Thanks!, so far it seems to be working fine. I'll try to get it merged soon. Best, Rodrigo.

July 14, 2024

[PATCH] Toolbar zoom control button

by a1ex＠dismail.de

Hi list, Here is an improved version of my previous patch. The icon is fixed, it's basic but does the job. If someone wants to make a prettier one, I'm open to it. Other improvements as discussed with Rodrigo: - Middle click resets zoom level - There is now a 'show_zoom' preference in dillorc (enabled by default) - The save button has been disabled by default - The zoom button has been moved to the right of the refresh button Please let me know if you find any issues, and hope you enjoy it :) Regards, Alex diff -upr a/dillorc b/dillorc --- a/dillorc Sun Jul 14 18:25:44 2024 +++ b/dillorc Sun Jul 14 18:25:59 2024 @@ -366,7 +366,8 @@ ui_tab_bg_color=#b7beb7 #show_forw=YES #show_home=YES #show_reload=YES -#show_save=YES +#show_zoom=YES +#show_save=NO #show_stop=YES #show_bookmarks=YES #show_tools=YES diff -upr a/src/pixmaps.h b/src/pixmaps.h --- a/src/pixmaps.h Sun Jul 14 18:25:44 2024 +++ b/src/pixmaps.h Sun Jul 14 18:25:59 2024 @@ -809,6 +809,35 @@ static const char *const tools_xpm[] = { " -&X6&=# ", " "}; +/* XPM */ +static const char *const zoom_xpm[] = { +"22 22 3 1", +" c None", +"1 c #B3B3B3", +"2 c #000000", +" 111111 ", +" 1122222211 ", +" 122 221 ", +" 12 21 ", +" 12 21 ", +" 12 11 21 ", +" 12 1221 21 ", +" 12 1221 21 ", +"12 1221 21", +"12 1111221111 21", +"12 122222222221 21", +"12 122222222221 21", +"12 1111221111 21", +"12 1221 21", +" 12 1221 21 ", +" 12 1221 21 ", +" 12 11 21 ", +" 12 21 ", +" 12 2221 ", +" 122 2211221 ", +" 1122222211 1221", +" 111111 122"}; + /* Small icons here */ /* XPM */ @@ -1408,6 +1437,29 @@ static const char *const tools_s_xpm[] = { " u-%#*%0", " feww0g" }; + +/* XPM */ +static const char *const zoom_s_xpm[] = { +"16 16 3 1", +" c None", +"1 c #000000", +"2 c #B3B3B3", +" 222222 ", +" 21111112 ", +" 21 12 ", +" 21 22 12 ", +" 21 2112 12 ", +"21 2112 12", +"21 22211222 12", +"21 2111111112 12", +"21 2111111112 12", +"21 22211222 12", +" 21 2112 12 ", +" 21 2112 122 ", +" 21 22 11112", +" 211111122111", +" 222222 211", +" 22"}; /* XPM */ static const char *const new_s_xpm[] = { diff -upr a/src/prefs.c b/src/prefs.c --- a/src/prefs.c Sun Jul 14 18:25:44 2024 +++ b/src/prefs.c Sun Jul 14 18:25:59 2024 @@ -103,7 +103,8 @@ void a_Prefs_init(void) prefs.show_progress_box = TRUE; prefs.show_quit_dialog = TRUE; prefs.show_reload = TRUE; - prefs.show_save = TRUE; + prefs.show_zoom = TRUE; + prefs.show_save = FALSE; prefs.show_url = TRUE; prefs.show_search = TRUE; prefs.show_stop = TRUE; diff -upr a/src/prefs.h b/src/prefs.h --- a/src/prefs.h Sun Jul 14 18:25:44 2024 +++ b/src/prefs.h Sun Jul 14 18:25:59 2024 @@ -81,6 +81,7 @@ typedef struct { bool_t show_forw; bool_t show_home; bool_t show_reload; + bool_t show_zoom; bool_t show_save; bool_t show_stop; bool_t show_bookmarks; diff -upr a/src/prefsparser.cc b/src/prefsparser.cc --- a/src/prefsparser.cc Sun Jul 14 18:25:44 2024 +++ b/src/prefsparser.cc Sun Jul 14 18:25:59 2024 @@ -213,6 +213,7 @@ void PrefsParser::parse(FILE *fp) { "show_progress_box", &prefs.show_progress_box, PREFS_BOOL, 0 }, { "show_quit_dialog", &prefs.show_quit_dialog, PREFS_BOOL, 0 }, { "show_reload", &prefs.show_reload, PREFS_BOOL, 0 }, + { "show_zoom", &prefs.show_zoom, PREFS_BOOL, 0 }, { "show_save", &prefs.show_save, PREFS_BOOL, 0 }, { "show_url", &prefs.show_url, PREFS_BOOL, 0 }, { "show_search", &prefs.show_search, PREFS_BOOL, 0 }, diff -upr a/src/ui.cc b/src/ui.cc --- a/src/ui.cc Sun Jul 14 18:25:44 2024 +++ b/src/ui.cc Sun Jul 14 18:25:59 2024 @@ -38,7 +38,7 @@ struct iconset { Fl_Image *ImgMeterOK, *ImgMeterBug, - *ImgHome, *ImgReload, *ImgSave, *ImgBook, *ImgTools, + *ImgHome, *ImgReload, *ImgZoom, *ImgSave, *ImgBook, *ImgTools, *ImgClear,*ImgSearch, *ImgHelp, *ImgLeft, *ImgLeftIn, *ImgRight, *ImgRightIn, *ImgStop, *ImgStopIn; }; @@ -48,6 +48,7 @@ static struct iconset standard_icons = { new Fl_Pixmap(mini_bug_xpm), new Fl_Pixmap(home_xpm), new Fl_Pixmap(reload_xpm), + new Fl_Pixmap(zoom_xpm), new Fl_Pixmap(save_xpm), new Fl_Pixmap(bm_xpm), new Fl_Pixmap(tools_xpm), @@ -67,6 +68,7 @@ static struct iconset small_icons = { standard_icons.ImgMeterBug, new Fl_Pixmap(home_s_xpm), new Fl_Pixmap(reload_s_xpm), + new Fl_Pixmap(zoom_s_xpm), new Fl_Pixmap(save_s_xpm), new Fl_Pixmap(bm_s_xpm), new Fl_Pixmap(tools_s_xpm), @@ -356,6 +358,15 @@ static void b1_cb(Fl_Widget *wid, void *cb_data) wid->y() + wid->h()); } break; + case UI_ZOOM: + if (b == FL_LEFT_MOUSE) { + a_UIcmd_zoom_in(a_UIcmd_get_bw_by_widget(wid)); + } else if (b == FL_RIGHT_MOUSE) { + a_UIcmd_zoom_out(a_UIcmd_get_bw_by_widget(wid)); + } else if (b == FL_MIDDLE_MOUSE) { + a_UIcmd_zoom_reset(a_UIcmd_get_bw_by_widget(wid)); + } + break; default: break; } @@ -429,6 +440,7 @@ void UI::make_toolbar(int tw, int th) Forw = make_button("Forw", icons->ImgRight, icons->ImgRightIn, UI_FORW); Home = make_button("Home", icons->ImgHome, NULL, UI_HOME); Reload = make_button("Reload", icons->ImgReload, NULL, UI_RELOAD); + Zoom = make_button("Zoom", icons->ImgZoom, NULL, UI_ZOOM); Save = make_button("Save", icons->ImgSave, NULL, UI_SAVE); Stop = make_button("Stop", icons->ImgStop, icons->ImgStopIn, UI_STOP); Bookmarks = make_button("Book", icons->ImgBook, NULL, UI_BOOK); @@ -438,6 +450,7 @@ void UI::make_toolbar(int tw, int th) Forw->set_tooltip("Next page"); Home->set_tooltip("Go to the Home page"); Reload->set_tooltip("Reload"); + Zoom->set_tooltip("Zoom: left-click, Zoom out: right-click, Reset: middle"); Save->set_tooltip("Save this page"); Stop->set_tooltip("Stop loading"); Bookmarks->set_tooltip("View bookmarks"); @@ -952,6 +965,8 @@ void UI::customize() Home->hide(); if ( !prefs.show_reload ) Reload->hide(); + if ( !prefs.show_zoom ) + Zoom->hide(); if ( !prefs.show_save ) Save->hide(); if ( !prefs.show_stop ) diff -upr a/src/ui.hh b/src/ui.hh --- a/src/ui.hh Sun Jul 14 18:25:44 2024 +++ b/src/ui.hh Sun Jul 14 18:25:59 2024 @@ -19,6 +19,7 @@ typedef enum { UI_FORW, UI_HOME, UI_RELOAD, + UI_ZOOM, UI_SAVE, UI_STOP, UI_BOOK, @@ -124,7 +125,7 @@ class UI : public CustGroupVertical { CustTabs *Tabs; CustGroupVertical *TopGroup; - CustButton *Back, *Forw, *Home, *Reload, *Save, *Stop, *Bookmarks, + CustButton *Back, *Forw, *Home, *Reload, *Zoom, *Save, *Stop, *Bookmarks, *Tools, *Clear, *Search, *Help, *BugMeter, *FileButton; CustGroupHorizontal *LocBar, *NavBar, *StatusBar; Fl_Input *Location;

July 14, 2024

Re: Fingerprinting with JA3 and JA4 hashes

by Rodrigo Arias

On Sun, Jul 14, 2024 at 03:41:25PM +0200, Rodrigo Arias wrote: >--8<-- >diff --git a/src/IO/mime.c b/src/IO/mime.c >index 9d5e6738..2361a459 100644 >--- a/src/IO/mime.c >+++ b/src/IO/mime.c >@@ -112,6 +112,9 @@ void a_Mime_init() > /* Add a major type to handle all the text stuff */ > Mime_add_major_type("text", a_Plain_text); >+ >+ /* Display JSON as plain text too */ >+ Mime_add_major_type("application/json", a_Plain_text); This should be Mime_add_minor_type() not major ^^'. I opened a PR: https://github.com/dillo-browser/dillo/pull/224 Rodrigo.

July 14, 2024

Re: Fingerprinting with JA3 and JA4 hashes

by Rodrigo Arias

Hi, On Sat, Jul 13, 2024 at 08:03:13PM +0200, a1ex(a)dismail.de wrote: >I was doing some tests on browserleaks.com with TLS fingerprinting. > >https://tls.browserleaks.com/iframe/ja3_hash > >On Dillo with LibreSSL, this hash changes every time I reload the page. >On Firefox (which uses NSS), the hash stays the same. I don't know if I >understand fully, but it seems like LibreSSL is resistant to this type >of fingerprinting. Very nice discovery. I can also reproduce the same behavior with LibreSSL, but with OpenSSL it stays the same. Unfortunately, the JA3n hash stays the same for LibreSSL. I also found a way to access the "raw" data in JSON using: https://tls.browserleaks.com/tls With this little patch, the response can be shown in Dillo too: --8<-- diff --git a/src/IO/mime.c b/src/IO/mime.c index 9d5e6738..2361a459 100644 --- a/src/IO/mime.c +++ b/src/IO/mime.c @@ -112,6 +112,9 @@ void a_Mime_init() /* Add a major type to handle all the text stuff */ Mime_add_major_type("text", a_Plain_text); + + /* Display JSON as plain text too */ + Mime_add_major_type("application/json", a_Plain_text); } --8<-- There is also JA4[1,2], which can be displayed here: https://ja4db.com/id/ja4/ https://ja4db.com/id/ja4h/ [1]:https://developers.cloudflare.com/bots/concepts/ja3-ja4-fingerprint/ [2]:https://github.com/FoxIO-LLC/ja4 Both JA4 hashes seem to stay the same on reloading the page using LibreSSL. Best, Rodrigo.

July 14, 2024

Re: [SCRIPT] Run Dillo with a random user agent

by a1ex＠dismail.de

On Sat, 13 Jul 2024 09:54:11 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > I work under the assumption that each Dillo user is uniquely > identifiable based on non-JS enabled, other HTTP headers, TLS > behavior, TCP and network timing leaked details, unless I have > evidence that suggests otherwise. I was doing some tests on browserleaks.com with TLS fingerprinting. https://tls.browserleaks.com/iframe/ja3_hash On Dillo with LibreSSL, this hash changes every time I reload the page. On Firefox (which uses NSS), the hash stays the same. I don't know if I understand fully, but it seems like LibreSSL is resistant to this type of fingerprinting. Regards, Alex

July 13, 2024

Re: [PATCH] Toolbar button to control zoom level

by a1ex＠dismail.de

On Sat, 13 Jul 2024 11:07:10 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > >all that is needed now is the 'magnifying glass' icon above the word > >Zoom 'borrowed' from the 'search button' :) > > There is a button there, but with the default Dillo options the color > of the icon is very similar to the background (attached screenshot) > and is barely visible. I think Alex may be using a different color > scheme. You are correct. The patch was just a proof of concept, and I didn't spend too much time on the icon. Since there appears to be interest in this feature, I will work on a more complete patch which will address that, and the items mentioned below. > I'm thinking if we could hide the save button by default and put the > zoom there instead, as save is available from the page menu either > way, and I think the zoom button would be used more frequently. > > We probably should add a "show_zoom" preference too in dillorc. Also > we may want to use the middle click to reset the zoom level. Agreed! Thanks, Alex

July 13, 2024

Re: Option to define external link handler

by Rodrigo Arias

Hi Diego On Sat, Jul 13, 2024 at 01:36:19PM +0200, Diego wrote: >I think a good way is to reduce functionality to a minimum. Not to make a >full scripting language, but rather moderately complex hook rules that can >call external scripts or DPIs with complex functionality. This is not a scripting language, just a way to describe rules that can be transformed in quick operations at runtime. We won't be reinventing JS. >Another mistake that can be made is to replace the DPI infrastructure. I >think a cooperation between the two is better. There is no plan to remove the support for DPI plugins, just to increase the capabilities for hooking. >DPIs and authorized scripts can set temporary rules and be called by dillo >on events. >Fixed rules in a rules file call complex scripts or DPIs. That's more or less the idea. >The problem with the DPI infrastructure is that it is an unfinished >infrastructure with very little documentation. There are other structural problems, please check the related issues. https://github.com/dillo-browser/dillo/issues/65 https://github.com/dillo-browser/dillo/issues/56 Best, Rodrigo.

July 13, 2024

Re: [SCRIPT] Run Dillo with a random user agent

by a1ex＠dismail.de

Hi Rodrigo, On Sat, 13 Jul 2024 09:54:11 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > Thanks!, I think is a good idea to reduce fingerprinting in Dillo. > Have you considered also removing the user agent header completely? Yes, I ran with no user agent for quite a while in the past, but found that certain sites refused to serve content without it. > I work under the assumption that each Dillo user is uniquely > identifiable based on non-JS enabled, other HTTP headers, TLS > behavior, TCP and network timing leaked details, unless I have > evidence that suggests otherwise. Probably a good assumption, however I suspect that many sites aren't so advanced and mainly use JS, headers, and IP address for fingerprinting. Randomizing some of the headers may still be valuable. > >Just to add to this, have you considered the idea of a user agent > >switcher in Dillo? It would be neat to be able to choose from > >different profiles and have them applied in real-time without having > >to restart the browser. For example, the profiles could be something > >like: > > > >'Default', 'Desktop', 'Mobile', 'Random' > > I thought about something like this but for the CSS media selector, > not so much for the user agent. I'm not sure if switching the user > agent among desktop/mobile would have a measurable effect on the page > content. I don't know about recently, but in the past certain sites would serve a more Dillo-friendly page if you used a mobile agent like: http_user_agent="Opera/9.60 (J2ME/MIDP; Opera Mini/4.2.13337/458; U; en) Presto/2.2.0" or http_user_agent="Mozilla/5.0 (PSP (PlayStation Portable); 2.00)" Of course those are VERY outdated examples, and are probably no longer effective. I still think that a mobile user agent could cause certain sites to work better, but this would take further study to prove value. > If you want to reduce information leaked by Dillo that can identify a > user, I think a good strategy is first to make a service that can > measure this information among Dillo users and show the differences > it can find among users, much like the EFF does[1]. Maybe we can work > with the EFF to improve the support for non-JS browsers, so we can > benefit from their pool of users to estimate uniqueness. > > [1]: https://coveryourtracks.eff.org/ > > We can also make it cooperate with a Dillo plugin that can have > access to network TCP packets and timing information on both ends to > emulate an state actor, so we can estimate how much information is > being leaked and how much we are reducing it. > > This is probably something that we may want to bring up to the Tor > team to see which strategies the did for the Tor Browser and which > ones we can apply to Dillo. I like the idea of emulating the Tor Browser fingerprint, however there could be scenerios where this is undesireable, and may actually draw more attention. Regards, Alex

July 13, 2024

Re: Option to define external link handler

by Diego

El sáb, 13 jul 2024 a las 10:01, Rodrigo Arias (<rodarima(a)gmail.com>) escribió: > On Mon, Jul 08, 2024 at 09:59:20AM +1000, Kevin Koster wrote: > >That would be great. Provided it doesn't actually end up as complicated > >as iptables configuration of course. :) > > Yeah, I'll have to think how to avoid that too :-) > > I'm putting my thoughts into an RFC here: > > > https://github.com/dillo-browser/rfc/blob/rfc-002/rfc-002-rule-based-conten… > > (On Dillo it renders ok without remote CSS) > > Let's see if I can keep it simple. > > Rodrigo. > I think a good way is to reduce functionality to a minimum. Not to make a full scripting language, but rather moderately complex hook rules that can call external scripts or DPIs with complex functionality. Another mistake that can be made is to replace the DPI infrastructure. I think a cooperation between the two is better. DPIs and authorized scripts can set temporary rules and be called by dillo on events. Fixed rules in a rules file call complex scripts or DPIs. The problem with the DPI infrastructure is that it is an unfinished infrastructure with very little documentation. For example: uncontrolled mime types can be implemented by sending a DPI command to the DPI service "mime.<mime_type_name>" and using the same functions as vsource. To handle, for example, text/markdow or image/webp, put mime.text/markdown=... and mime.imge/webp=... in dpidrc. I think this is the only way to have a lightweight device with more functionality loaded only when used. (Sorry for my English. My native language is Spanish) Diego Sáenz

July 13, 2024

Re: [PATCH] Toolbar button to control zoom level

by Rodrigo Arias

Hi, > Here is an updated patch with a better icon and fixed tooltip. > Hopefully somebody finds it useful :) Thanks! I applied it from the attached file, like this: $ cd src $ md5sum /tmp/zoom-button.patch c8d48b41f30ba889ddd610860ecdc310 /tmp/patches/zoom-button.patch $ patch -p1 < /tmp/zoom-button.patch patching file pixmaps.h patching file ui.cc patching file ui.hh In the future, please perform the diffs from the top level directory, like so: $ diff -up dillo-orig/ dillo-mod/ (Or better, via "git format-patch" if you use git) >all that is needed now is the 'magnifying glass' icon above the word >Zoom 'borrowed' from the 'search button' :) There is a button there, but with the default Dillo options the color of the icon is very similar to the background (attached screenshot) and is barely visible. I think Alex may be using a different color scheme. I'm thinking if we could hide the save button by default and put the zoom there instead, as save is available from the page menu either way, and I think the zoom button would be used more frequently. We probably should add a "show_zoom" preference too in dillorc. Also we may want to use the middle click to reset the zoom level. Best, Rodrigo.

July 13, 2024

Re: zoom needs scrolling to maintain center

by Rodrigo Arias

Hi, On Fri, Jul 12, 2024 at 11:18:11PM +0200, a1ex(a)dismail.de wrote: >On Fri, 12 Jul 2024 12:04:30 -0600 >pastebin(a)gmx.com wrote: > >> Hi >> >> with left mouse click on zoom button -> screen get bigger and screen >> slides down - so when leaves the viewport it needs a scroll up so >> center remains and zoom is userfull >> >> with right mouse click on zoom button -> screen get smaller and >> screen slides down - so when viewport is off the physical screena >> scroll down - do nothing when viewport is <= the physical screen > >Thats true. I think the zoom code right now just relies on a >StyleEngine action, which isn't really designed for that. What you >are suggesting would probably take quite a bit more work. I think we could approximate it by assuming that each element will be magnified by the same amount. Therefore, if you measure the distance in pixels of the current view from the top of the page, Y, and then you increase the zoom by a factor of 1.2, then you should scroll to 1.2*Y to compensate it. Here is a "graphical" visualization but in horizontal rather than vertically: 0 5 10 15 0 5 10 15 AAAABBBBCCCCDDDD --> AAAAABBBBBCCCCCDDDDD ^ ^ Y=10 x1.2 Y=12 This won't work with cases where the text is constrained into a container that has 100% width (or some other relative size), as it would change the breaking point of the lines, causing the scroll approximation to fail. A more accurate and complex approach is to take the position of some elements in the current view, and then try to locate them after zooming and then scroll there. I opened an issue here to track it: https://github.com/dillo-browser/dillo/issues/221 Rodrigo.

July 13, 2024

Re: Option to define external link handler

by Rodrigo Arias

On Mon, Jul 08, 2024 at 09:59:20AM +1000, Kevin Koster wrote: >That would be great. Provided it doesn't actually end up as complicated >as iptables configuration of course. :) Yeah, I'll have to think how to avoid that too :-) I'm putting my thoughts into an RFC here: https://github.com/dillo-browser/rfc/blob/rfc-002/rfc-002-rule-based-conten… (On Dillo it renders ok without remote CSS) Let's see if I can keep it simple. Rodrigo.

July 13, 2024

Re: [SCRIPT] Run Dillo with a random user agent

by Rodrigo Arias

Hi Alex, On Tue, Jul 09, 2024 at 12:31:29PM +0200, a1ex(a)dismail.de wrote: >On Mon, 8 Jul 2024 14:50:08 +0200 ><a1ex(a)dismail.de> wrote: > >> Hi list, >> >> Here is a simple script which runs Dillo with a random user agent on >> each run. I've been using it for a long time with no issues. It would >> be interesting to have similar functionality built-in to Dillo at some >> point, at least for me. >> >> ... Thanks!, I think is a good idea to reduce fingerprinting in Dillo. Have you considered also removing the user agent header completely? I work under the assumption that each Dillo user is uniquely identifiable based on non-JS enabled, other HTTP headers, TLS behavior, TCP and network timing leaked details, unless I have evidence that suggests otherwise. I don't think the web is designed to keep users anonymous and there is only so much we can do. However, I would appreciate efforts towards reducing the fingerprinting information we are leaking. It would be nice to be able to measure it somehow, but I only find JS enabled fingerprinting estimation tests online. >Just to add to this, have you considered the idea of a user agent >switcher in Dillo? It would be neat to be able to choose from different >profiles and have them applied in real-time without having to restart >the browser. For example, the profiles could be something like: > >'Default', 'Desktop', 'Mobile', 'Random' I thought about something like this but for the CSS media selector, not so much for the user agent. I'm not sure if switching the user agent among desktop/mobile would have a measurable effect on the page content. If you want to reduce information leaked by Dillo that can identify a user, I think a good strategy is first to make a service that can measure this information among Dillo users and show the differences it can find among users, much like the EFF does[1]. Maybe we can work with the EFF to improve the support for non-JS browsers, so we can benefit from their pool of users to estimate uniqueness. [1]: https://coveryourtracks.eff.org/ We can also make it cooperate with a Dillo plugin that can have access to network TCP packets and timing information on both ends to emulate an state actor, so we can estimate how much information is being leaked and how much we are reducing it. This is probably something that we may want to bring up to the Tor team to see which strategies the did for the Tor Browser and which ones we can apply to Dillo. See also: https://github.com/dillo-browser/dillo/issues/135 Best, Rodrigo.

July 13, 2024

Re: zoom needs scrolling to maintain center

by pastebin＠gmx.com

isn't there already a scroll up/scroll down command like zoom_in/zoom_out } else if (cmd == KEYS_ZOOM_IN) { a_UIcmd_zoom_in(a_UIcmd_get_bw_by_widget(this)); a_UIcmc_scroll_up(number_lines); <-- ret = 1; On Fri, 12 Jul 2024 23:18:11 +0200 <a1ex(a)dismail.de> wrote: > On Fri, 12 Jul 2024 12:04:30 -0600 > pastebin(a)gmx.com wrote: > > > Hi > > > > with left mouse click on zoom button -> screen get bigger and screen > > slides down - so when leaves the viewport it needs a scroll up so > > center remains and zoom is userfull > > > > with right mouse click on zoom button -> screen get smaller and > > screen slides down - so when viewport is off the physical screena > > scroll down - do nothing when viewport is <= the physical screen > > Thats true. I think the zoom code right now just relies on a > StyleEngine action, which isn't really designed for that. What you > are suggesting would probably take quite a bit more work. > > Dillo needs contributors who can offer patches and support. Please lets > try to pick our battles carefully in order to not overwhelm the already > very busy developer. > > -Alex > > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

July 12, 2024

Re: zoom needs scrolling to maintain center

by a1ex＠dismail.de

On Fri, 12 Jul 2024 12:04:30 -0600 pastebin(a)gmx.com wrote: > Hi > > with left mouse click on zoom button -> screen get bigger and screen > slides down - so when leaves the viewport it needs a scroll up so > center remains and zoom is userfull > > with right mouse click on zoom button -> screen get smaller and > screen slides down - so when viewport is off the physical screena > scroll down - do nothing when viewport is <= the physical screen Thats true. I think the zoom code right now just relies on a StyleEngine action, which isn't really designed for that. What you are suggesting would probably take quite a bit more work. Dillo needs contributors who can offer patches and support. Please lets try to pick our battles carefully in order to not overwhelm the already very busy developer. -Alex

July 12, 2024

zoom needs scrolling to maintain center

by pastebin＠gmx.com

Hi with left mouse click on zoom button -> screen get bigger and screen slides down - so when leaves the viewport it needs a scroll up so center remains and zoom is userfull with right mouse click on zoom button -> screen get smaller and screen slides down - so when viewport is off the physical screena scroll down - do nothing when viewport is <= the physical screen ---

July 12, 2024

dillo css

by pastebin＠gmx.com

Hi the attached html with css that does dropdown box renders fine with seamonkey with the ~/.dillo/style.css or tools/use embedded css it partially succeeds but the drop down fails i have an old dillo css html help file (looks like from 2005) titled Dillo Web Browser :: Cascading Style Sheets and what the current dillo user manual (generated for version 3.1.1) has in it for css any further 3.1.1 css info/help pages? these are quite complicated coding dillo-3.1.1/src/cssparser.cc dillo-3.1.1/src/css.cc

July 11, 2024

adding magnifying glass to zoom button

by pastebin＠gmx.com

Hi I was able to add a 'magnifying' glass to the zoom button by in src/ui.cc line 54 by the following new Fl_Pixmap(search_xpm), // new Fl_Pixmap(zoom_xpm), i am working on how to do make a 'patch' but it still needs some work

July 10, 2024

Re: view source - close button

by pastebin＠gmx.com

alex - sorry please disregard i use F1 key with close on it F1 = close-tab dillo to close tabs/windows - i has just looked at bug meter and saw that there was nothing on the bottom bar On Tue, 9 Jul 2024 21:12:18 +0200 <a1ex(a)dismail.de> wrote: > On Tue, 9 Jul 2024 11:34:16 -0600 > pastebin(a)gmx.com wrote: > > > Hi > > > > didn't there use to be a close button on the bottom of the 'right > > mouse click/view page source' page like there is on the 'bug display > > page'? > > I don't recall that, but could be wrong. > > View source displays in a new tab, and the bug meter opens in a new > window textbox. Apples to oranges. > > Middle-click closing the tab works for me. > > > Regards, > Alex > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

July 9, 2024

Re: view source - close button

by pastebin＠gmx.com

Hi alex middle click on the tab itself closes it maybe i'm paying to close attention to how i am doing dillo things now (i am making a personal how-to for everything i do) i did an install of my old dillo and there was no close button i use 'view source' alot but maybe i clicked 'X' to close it without thinking about it there is an empty bar at the bottom of 'view source' maybe i thought it was missing .... from there i had just done the bug meter and there is a close button in the same bar location can i add a new feature request to put a close button there :) in regards to an old situation -> my wanting to cutnpaste the tooltip from the 'done save file' dialog since i can cut n paste from the bug meter window text box and view file source in a new tab can the done save file tooltip be re-made into a window text box (with cutnpaste capabilities) On Tue, 9 Jul 2024 21:12:18 +0200 <a1ex(a)dismail.de> wrote: > On Tue, 9 Jul 2024 11:34:16 -0600 > pastebin(a)gmx.com wrote: > > > Hi > > > > didn't there use to be a close button on the bottom of the 'right > > mouse click/view page source' page like there is on the 'bug display > > page'? > > I don't recall that, but could be wrong. > > View source displays in a new tab, and the bug meter opens in a new > window textbox. Apples to oranges. > > Middle-click closing the tab works for me. > > > Regards, > Alex > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

July 9, 2024

Re: view source - close button

by a1ex＠dismail.de

On Tue, 9 Jul 2024 11:34:16 -0600 pastebin(a)gmx.com wrote: > Hi > > didn't there use to be a close button on the bottom of the 'right > mouse click/view page source' page like there is on the 'bug display > page'? I don't recall that, but could be wrong. View source displays in a new tab, and the bug meter opens in a new window textbox. Apples to oranges. Middle-click closing the tab works for me. Regards, Alex

July 9, 2024

view source - close button

by pastebin＠gmx.com

Hi didn't there use to be a close button on the bottom of the 'right mouse click/view page source' page like there is on the 'bug display page'? the zoom controls aren't the cause of it not being there

July 9, 2024

Re: [SCRIPT] Run Dillo with a random user agent

by a1ex＠dismail.de

On Mon, 8 Jul 2024 14:50:08 +0200 <a1ex(a)dismail.de> wrote: > Hi list, > > Here is a simple script which runs Dillo with a random user agent on > each run. I've been using it for a long time with no issues. It would > be interesting to have similar functionality built-in to Dillo at some > point, at least for me. > > ... Just to add to this, have you considered the idea of a user agent switcher in Dillo? It would be neat to be able to choose from different profiles and have them applied in real-time without having to restart the browser. For example, the profiles could be something like: 'Default', 'Desktop', 'Mobile', 'Random' I think this could be a valuable feature for many users. I know you have a lot on your plate, but just wanted to throw the idea out there. Thanks, Alex

July 9, 2024

Re: [PATCH] Toolbar button to control zoom level

by pastebin＠gmx.com

Hi just a suggestion when zooming in and out - is it possible to keep the center in the center - currently the center moves down when zooming in and up when zooming out On Sun, 7 Jul 2024 21:02:19 +0200 <a1ex(a)dismail.de> wrote: > Hi, > > Here is an updated patch with a better icon and fixed tooltip. > Hopefully somebody finds it useful :) > > > diff -u ./pixmaps.h mod/pixmaps.h > --- ./pixmaps.h Sat Jul 6 18:03:43 2024 > +++ mod/pixmaps.h Sat Jul 6 18:23:27 2024 > @@ -1410,6 +1410,28 @@ > }; > > /* XPM */ > +static const char *const zoom_xpm[] = { > +"16 16 2 1", > +" c None", > +"@ c gray70", > +" ", > +" @@@@@@ ", > +" @ @ ", > +" @ @ ", > +" @ @@ @ ", > +" @ @@ @ ", > +" @ @@ @ ", > +" @ @@@@@@@@ @ ", > +" @ @@@@@@@@ @ ", > +" @ @@ @ ", > +" @ @@ @ ", > +" @ @@ @ ", > +" @ @@@@ ", > +" @@@@@@ @@@", > +" @@", > +" "}; > + > +/* XPM */ > static const char *const new_s_xpm[] = { > "11 11 35 1", > " c None", > diff -u ./ui.cc mod/ui.cc > --- ./ui.cc Sat Jul 6 18:26:52 2024 > +++ mod/ui.cc Sat Jul 6 18:03:57 2024 > @@ -38,7 +38,7 @@ > > struct iconset { > Fl_Image *ImgMeterOK, *ImgMeterBug, > - *ImgHome, *ImgReload, *ImgSave, *ImgBook, *ImgTools, > + *ImgHome, *ImgReload, *ImgSave, *ImgBook, *ImgTools, *ImgZoom, > *ImgClear,*ImgSearch, *ImgHelp, *ImgLeft, *ImgLeftIn, > *ImgRight, *ImgRightIn, *ImgStop, *ImgStopIn; > }; > @@ -51,6 +51,7 @@ > new Fl_Pixmap(save_xpm), > new Fl_Pixmap(bm_xpm), > new Fl_Pixmap(tools_xpm), > + new Fl_Pixmap(zoom_xpm), > new Fl_Pixmap(new_s_xpm), > new Fl_Pixmap(search_xpm), > new Fl_Pixmap(help_xpm), > @@ -70,6 +71,7 @@ > new Fl_Pixmap(save_s_xpm), > new Fl_Pixmap(bm_s_xpm), > new Fl_Pixmap(tools_s_xpm), > + new Fl_Pixmap(zoom_xpm), > new Fl_Pixmap(new_s_xpm), > standard_icons.ImgSearch, > standard_icons.ImgHelp, > @@ -356,6 +358,13 @@ > wid->y() + wid->h()); > } > break; > + case UI_ZOOM: > + if (b == FL_LEFT_MOUSE) { > + a_UIcmd_zoom_in(a_UIcmd_get_bw_by_widget(wid)); > + } else if (b == FL_RIGHT_MOUSE) { > + a_UIcmd_zoom_out(a_UIcmd_get_bw_by_widget(wid)); > + } > + break; > default: > break; > } > @@ -433,6 +442,7 @@ > Stop = make_button("Stop", icons->ImgStop, icons->ImgStopIn, UI_STOP); > Bookmarks = make_button("Book", icons->ImgBook, NULL, UI_BOOK); > Tools = make_button("Tools", icons->ImgTools, NULL, UI_TOOLS); > + Zoom = make_button("Zoom", icons->ImgZoom, NULL, UI_ZOOM); > > Back->set_tooltip("Previous page"); > Forw->set_tooltip("Next page"); > @@ -442,6 +452,7 @@ > Stop->set_tooltip("Stop loading"); > Bookmarks->set_tooltip("View bookmarks"); > Tools->set_tooltip("Settings"); > + Zoom->set_tooltip("Zoom in: left-click, Zoom out: right-click"); > } > > /** > diff -u ./ui.hh mod/ui.hh > --- ./ui.hh Sat Jul 6 18:03:43 2024 > +++ mod/ui.hh Sat Jul 6 18:03:57 2024 > @@ -23,6 +23,7 @@ > UI_STOP, > UI_BOOK, > UI_TOOLS, > + UI_ZOOM, > UI_CLEAR, > UI_SEARCH > } UIButton; > @@ -125,7 +126,7 @@ > > CustGroupVertical *TopGroup; > CustButton *Back, *Forw, *Home, *Reload, *Save, *Stop, *Bookmarks, > - *Tools, *Clear, *Search, *Help, *BugMeter, *FileButton; > + *Tools, *Zoom, *Clear, *Search, *Help, *BugMeter, *FileButton; > CustGroupHorizontal *LocBar, *NavBar, *StatusBar; > Fl_Input *Location; > CustProgressBox *PProg, *IProg; > > > -Alex

July 8, 2024

[SCRIPT] Run Dillo with a random user agent

by a1ex＠dismail.de

Hi list, Here is a simple script which runs Dillo with a random user agent on each run. I've been using it for a long time with no issues. It would be interesting to have similar functionality built-in to Dillo at some point, at least for me. $ cat rundillo.sh #!/bin/sh # runs dillo with a random user agent, from a list in agents.txt # the ua must be the last line of dillorc, this deletes it: echo -e '$d\nw\nq'| ed ~/.dillo/dillorc # put a random ua line from agents.txt into the last line of dillorc # each line in agents.txt must include http_user_agent='...' cat ~/.dillo/agents.txt | sort -R | head -1 >> ~/.dillo/dillorc # run dillo: dillo ------------------------------- Here is an example 'agents.txt': http_user_agent='Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:123.0) Gecko/20100101 Firefox/123.0' http_user_agent='Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0' http_user_agent='Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:125.0) Gecko/20100101 Firefox/125.0' http_user_agent='Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:126.0) Gecko/20100101 Firefox/126.0' http_user_agent='Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:127.0) Gecko/20100101 Firefox/127.0' http_user_agent='Mozilla/5.0 (Macintosh; Intel Mac OS X 14.5; rv:123.0) Gecko/20100101 Firefox/123.0' http_user_agent='Mozilla/5.0 (Macintosh; Intel Mac OS X 14.5; rv:124.0) Gecko/20100101 Firefox/124.0' http_user_agent='Mozilla/5.0 (Macintosh; Intel Mac OS X 14.5; rv:125.0) Gecko/20100101 Firefox/125.0' http_user_agent='Mozilla/5.0 (Macintosh; Intel Mac OS X 14.5; rv:126.0) Gecko/20100101 Firefox/126.0' http_user_agent='Mozilla/5.0 (Macintosh; Intel Mac OS X 14.5; rv:127.0) Gecko/20100101 Firefox/127.0' ------------------------------ Just make sure there are no blank lines or comments in agents.txt Anyway, hopefully this will be useful to someone. Enjoy :) -Alex

July 8, 2024

Re: Option to define external link handler

by Kevin Koster

On Sun, 7 Jul 2024 19:10:57 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > On Sun, Jul 07, 2024 at 10:21:05AM +1000, Kevin Koster wrote: > >In addition to HTTP header feilds, it would be handy to assign > >rewrite rules according to HTTP status codes. I spend a lot of time > >browsing dead/dying websites so I'm always using the Wayback > >Machine. I'd like to use this system to process 404 (500, etc.) > >error pages through a program/script that adds a link at the top to > >look up the URL at the Wayback Machine. It might also check for a > >copy I've archived locally, if I get my website archives more > >organised, and link to that as well. > > Good idea, this should be doable with the rule mechanism. An > important consideration is to be able to quickly forward good > requests or responses, so we reduce the overhead in overall browsing. > > We could probably just hook it to >= 400 and then you handle those > broken responses as you want, while quickly forwarding 200 to Dillo: > > match http-status-code >= 400 action broken-page > > I think we may need to define several "tables" like in iptables so we > can have rules that handle the traffic at different stages. This one > doesn't require decoding the compressed content. That would be great. Provided it doesn't actually end up as complicated as iptables configuration of course. :)

July 7, 2024

Re: dillo mouse cursor

by pastebin＠gmx.com

Hi alex, it loads on startx okay now but it still goes back to the 'default' in dillo and seamonkey, so the problem must be in xorg or fluxbox and i ain't messing with them - and besides the big cursor just doesn't look right after all :) thanks for the help and code - i've already forgotten about the cursor now that i have your and Rodrigo's zoom to play with :) On Sun, 7 Jul 2024 22:44:40 +0200 <a1ex(a)dismail.de> wrote: > On Sun, 7 Jul 2024 14:17:31 -0600 > Hi pastebin, > > pastebin(a)gmx.com wrote: > > > Hi alex > > > > i did the .Xdefaults file but there are a lot of pointers in the > > /usr/share/icons/DMZ-Black/cursors/ > > dir - how to tell it to use left_ptr? > > With the right settings, it should happen automatically if you have the > cursors in the correct directory. > > > btw it happens with seamonkey too - so it isn't just a dillo thing > > Maybe also try this in ~/.config/gtk-3.0/settings.ini: > > gtk-cursor-theme-name=DMZ-Black > gtk-cursor-theme-size=48 > > You may need to restart X or reboot to see if it works. > > > -Alex > > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

July 7, 2024

Re: [PATCH] Toolbar button to control zoom level

by pastebin＠gmx.com

Hi Rodrigo and alex, both your patches work on fresh source and the zoom button works nicely (left mouse click for zoom out and right mouse click for zoom in Rodrigos patch applied in dillo-3.1.1 patching file src/bw.c patching file src/bw.h patching file src/keys.cc patching file src/keys.hh patching file src/prefs.c patching file src/prefs.h patching file src/styleengine.cc patching file src/ui.cc Reversed (or previously applied) patch detected! Assume -R? [n] n Apply anyway? [n] n Skipping patch. 2 out of 2 hunks ignored -- saving rejects to file src/ui.cc.rej alex's patch applied in dillo-3.1.1/src patching file src/uicmd.cc patching file src/uicmd.hh patching file pixmaps.h patching file ui.cc patching file ui.hh all that is needed now is the 'magnifying glass' icon above the word Zoom 'borrowed' from the 'search button' :) On Sun, 7 Jul 2024 21:02:19 +0200 <a1ex(a)dismail.de> wrote: > Hi, > > Here is an updated patch with a better icon and fixed tooltip. > Hopefully somebody finds it useful :) > > > diff -u ./pixmaps.h mod/pixmaps.h > --- ./pixmaps.h Sat Jul 6 18:03:43 2024 > +++ mod/pixmaps.h Sat Jul 6 18:23:27 2024 > @@ -1410,6 +1410,28 @@ > }; > > /* XPM */ > +static const char *const zoom_xpm[] = { > +"16 16 2 1", > +" c None", > +"@ c gray70", > +" ", > +" @@@@@@ ", > +" @ @ ", > +" @ @ ", > +" @ @@ @ ", > +" @ @@ @ ", > +" @ @@ @ ", > +" @ @@@@@@@@ @ ", > +" @ @@@@@@@@ @ ", > +" @ @@ @ ", > +" @ @@ @ ", > +" @ @@ @ ", > +" @ @@@@ ", > +" @@@@@@ @@@", > +" @@", > +" "}; > + > +/* XPM */ > static const char *const new_s_xpm[] = { > "11 11 35 1", > " c None", > diff -u ./ui.cc mod/ui.cc > --- ./ui.cc Sat Jul 6 18:26:52 2024 > +++ mod/ui.cc Sat Jul 6 18:03:57 2024 > @@ -38,7 +38,7 @@ > > struct iconset { > Fl_Image *ImgMeterOK, *ImgMeterBug, > - *ImgHome, *ImgReload, *ImgSave, *ImgBook, *ImgTools, > + *ImgHome, *ImgReload, *ImgSave, *ImgBook, *ImgTools, *ImgZoom, > *ImgClear,*ImgSearch, *ImgHelp, *ImgLeft, *ImgLeftIn, > *ImgRight, *ImgRightIn, *ImgStop, *ImgStopIn; > }; > @@ -51,6 +51,7 @@ > new Fl_Pixmap(save_xpm), > new Fl_Pixmap(bm_xpm), > new Fl_Pixmap(tools_xpm), > + new Fl_Pixmap(zoom_xpm), > new Fl_Pixmap(new_s_xpm), > new Fl_Pixmap(search_xpm), > new Fl_Pixmap(help_xpm), > @@ -70,6 +71,7 @@ > new Fl_Pixmap(save_s_xpm), > new Fl_Pixmap(bm_s_xpm), > new Fl_Pixmap(tools_s_xpm), > + new Fl_Pixmap(zoom_xpm), > new Fl_Pixmap(new_s_xpm), > standard_icons.ImgSearch, > standard_icons.ImgHelp, > @@ -356,6 +358,13 @@ > wid->y() + wid->h()); > } > break; > + case UI_ZOOM: > + if (b == FL_LEFT_MOUSE) { > + a_UIcmd_zoom_in(a_UIcmd_get_bw_by_widget(wid)); > + } else if (b == FL_RIGHT_MOUSE) { > + a_UIcmd_zoom_out(a_UIcmd_get_bw_by_widget(wid)); > + } > + break; > default: > break; > } > @@ -433,6 +442,7 @@ > Stop = make_button("Stop", icons->ImgStop, icons->ImgStopIn, UI_STOP); > Bookmarks = make_button("Book", icons->ImgBook, NULL, UI_BOOK); > Tools = make_button("Tools", icons->ImgTools, NULL, UI_TOOLS); > + Zoom = make_button("Zoom", icons->ImgZoom, NULL, UI_ZOOM); > > Back->set_tooltip("Previous page"); > Forw->set_tooltip("Next page"); > @@ -442,6 +452,7 @@ > Stop->set_tooltip("Stop loading"); > Bookmarks->set_tooltip("View bookmarks"); > Tools->set_tooltip("Settings"); > + Zoom->set_tooltip("Zoom in: left-click, Zoom out: right-click"); > } > > /** > diff -u ./ui.hh mod/ui.hh > --- ./ui.hh Sat Jul 6 18:03:43 2024 > +++ mod/ui.hh Sat Jul 6 18:03:57 2024 > @@ -23,6 +23,7 @@ > UI_STOP, > UI_BOOK, > UI_TOOLS, > + UI_ZOOM, > UI_CLEAR, > UI_SEARCH > } UIButton; > @@ -125,7 +126,7 @@ > > CustGroupVertical *TopGroup; > CustButton *Back, *Forw, *Home, *Reload, *Save, *Stop, *Bookmarks, > - *Tools, *Clear, *Search, *Help, *BugMeter, *FileButton; > + *Tools, *Zoom, *Clear, *Search, *Help, *BugMeter, *FileButton; > CustGroupHorizontal *LocBar, *NavBar, *StatusBar; > Fl_Input *Location; > CustProgressBox *PProg, *IProg; > > > -Alex

July 7, 2024

Re: dillo mouse cursor

by a1ex＠dismail.de

On Sun, 7 Jul 2024 14:17:31 -0600 Hi pastebin, pastebin(a)gmx.com wrote: > Hi alex > > i did the .Xdefaults file but there are a lot of pointers in the > /usr/share/icons/DMZ-Black/cursors/ > dir - how to tell it to use left_ptr? With the right settings, it should happen automatically if you have the cursors in the correct directory. > btw it happens with seamonkey too - so it isn't just a dillo thing Maybe also try this in ~/.config/gtk-3.0/settings.ini: gtk-cursor-theme-name=DMZ-Black gtk-cursor-theme-size=48 You may need to restart X or reboot to see if it works. -Alex

July 7, 2024

Re: RFC repository

by Rodrigo Arias

Hi, On Sun, Jul 07, 2024 at 02:08:30PM -0600, pastebin(a)gmx.com wrote: >Rodrigo this looks pretty amazing Thanks! >are you thinking along the lines of a plugin that will take for example on the page >https://github.com/dillo-browser/rfc >the drop down box - when viewed with dillo gives > >Product >Actions >Automate any workflow >Packages >Host and manage packages >Security >Find and fix vulnerabilities >Codespaces >Instant dev environments >GitHub Copilot >Write better code with AI >Code review >Manage code changes >Issues >Plan and track work >Discussions >Collaborate outside of code >Sun, 7 Jul 2024 20:53:34 +0200 >Rodrigo Arias <rodarima(a)gmail.com> wrote: > >and put them into a drop down box? Yeah, that would be one of the use cases: HTML content rewriting. I think it would be easy to have a community maintained repository of rules to "fix the web" so it can be read by Dillo more easily. For now you can use the raw Markdown version to read it from Dillo: https://raw.githubusercontent.com/dillo-browser/rfc/rfc-002/rfc-002-rule-ba… Best, Rodrigo.

July 7, 2024

Re: dillo mouse cursor

by pastebin＠gmx.com

Hi alex i did the .Xdefaults file but there are a lot of pointers in the /usr/share/icons/DMZ-Black/cursors/ dir - how to tell it to use left_ptr? btw it happens with seamonkey too - so it isn't just a dillo thing On Sun, 7 Jul 2024 20:29:32 +0200 <a1ex(a)dismail.de> wrote: > On Sun, 7 Jul 2024 11:47:37 -0600 > pastebin(a)gmx.com wrote: > > > Hi > > > > this is my original mouse pointer > > xsetroot -cursor_name left_ptr > > > > when playing around with mouse cursors (i like this size) > > xsetroot -xcf /usr/share/icons/DMZ-Black/cursors/left_ptr 48 > > > > when i go into a text box on a site or move mouse to dillo's buttons > > on top the cursor changes to the original mouse pointer > > > > if i load a new dillo the large cursor comes back - until i pass the > > mouse cursor over a text box or dillo's top buttons again > > > > the large cursor isn't affected by text boxes on other program > > > I don't know what type of system you are running, but you could try > putting the following in your ~/.Xdefaults file: > > Xcursor.theme: DMZ-Black > Xcursor.size: 48 > > > Regards, > Alex > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

July 7, 2024

Re: RFC repository

by pastebin＠gmx.com

Rodrigo this looks pretty amazing are you thinking along the lines of a plugin that will take for example on the page https://github.com/dillo-browser/rfc the drop down box - when viewed with dillo gives Product Actions Automate any workflow Packages Host and manage packages Security Find and fix vulnerabilities Codespaces Instant dev environments GitHub Copilot Write better code with AI Code review Manage code changes Issues Plan and track work Discussions Collaborate outside of code Sun, 7 Jul 2024 20:53:34 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: and put them into a drop down box? > Hi, > > I've decided to open a RFC-like repository for Dillo here: > > https://github.com/dillo-browser/rfc > > So we can have a centralized place to propose and discuss non-arbitrary > changes or other topics regarding Dillo. For now they are just Markdown > files so they are easy to read and write from any editor and we don't > rely much on GitHub. This also allows contributions by sending patches > via email. > > I'll be collecting more thoughts about the rule-based mechanism I was > talking about in other threads in the RFC-002: Rule-based content > manipulation, here: > > https://github.com/dillo-browser/rfc/blob/rfc-002/rfc-002-rule-based-conten… > > I may also add the PEC proposal I did the other day to classify how > broken are pages when you disable JS, although it not very Dillo > specific: > > https://dillo-browser.github.io/pec/ > > Best, > Rodrigo. > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

July 7, 2024