Re: [PATCH v2] Unveil patch
by Rodrigo Arias
Hi,
On Thu, Aug 01, 2024 at 05:12:09PM +0200, a1ex(a)dismail.de wrote:
>Hi,
>
>Here is version 2 of my unveil patch. Many thanks to Rodrigo for his
>kind assistance!
Thank you Alex! I see this is progressing very well :-)
I'll be doing some tests with your patch when I have a moment. I'll need
to get an OpenBSD VM for testing probably.
In the meanwhile, I just wanted to link this compatibility unveil()
function for Linux, so I don't forget the link:
https://github.com/rpki-client/rpki-client-portable/blob/master/compat/unve…
I think a simple approach to test this is to find out if we cannot read
the ~/.ssh/id_rsa private keys from Dillo or plugins by any means. So
far I think we could read them by forging a call to the file plugin and
maybe by forking a new process that doesn't have the unveil()
protections and then reading ~/.ssh/id_rsa from there.
I saw that the OpenBSD developers have placed an "uploads" directory to
place files to be available to be read from the browser, and only that
directory is allowed (along with the downloads dir). It doesn't sound a
bad idea to me. This way we can avoid leaving ~/ unprotected in the file
plugin. What do you think?
>Improvements:
>- Unveil is disabled by default. It can be enabled using:
> configure --enable-unveil
>- There is now a dUnveil() wrapper which simplifies the code and error
> handling
>- Locale check and custom cursor icons unveil fix
>
>To-Do:
>- Add prefs parsing to plugins to get 'save_dir' (may need help here)
I assume you could reuse the same prefs parser from Dillo, but we would
need to link the DPIs with some of the code that is now only being
linked in the browser.
>- Add a dillorc pref to enable/disable unveil (same issue as above)
>- Localize wget and $AUTHORITY
>- A few other items from my previous to-do list
>
>Regards,
>Alex
>
>
>
>diff -upr a/configure.ac b/configure.ac
>--- a/configure.ac Sat Jul 27 12:54:47 2024
>+++ b/configure.ac Thu Aug 1 16:40:16 2024
>@@ -36,6 +36,11 @@ AC_ARG_ENABLE([insure],
> [enable_insure=$enableval],
> [enable_insure=no])
>
>+AC_ARG_ENABLE([unveil],
>+ [AS_HELP_STRING([--enable-unveil], [Build with support for unveil])],
>+ [enable_unveil=$enableval],
>+ [enable_unveil=no])
>+
> AC_ARG_ENABLE([ipv6],
> [AS_HELP_STRING([--enable-ipv6], [Build with support for IPv6])],
> [enable_ipv6=$enableval],
>@@ -619,6 +624,9 @@ if test "x$enable_insure" = "xyes" ; then
> CC="insure -Zoi \"compiler $CC\""
> LIBS="$LIBS -lstdc++-2-libc6.1-1-2.9.0"
> fi
>+if test "x$enable_unveil" = "xyes" ; then
>+ AC_DEFINE([ENABLE_UNVEIL], [1], [Enable unveil])
>+fi
> if test "x$enable_threaded_dns" = "xyes" ; then
> CFLAGS="$CFLAGS -DD_DNS_THREADED"
> fi
>@@ -725,4 +733,5 @@ _AS_ECHO([ GIF enabled : ${enable_gif}])
> _AS_ECHO([ SVG enabled : ${enable_svg}])
> _AS_ECHO([])
> _AS_ECHO([ HTML tests : ${html_tests_ok}])
>+_AS_ECHO([ unveil enabled : ${enable_unveil}])
> _AS_ECHO([])
>diff -upr a/dpi/bookmarks.c b/dpi/bookmarks.c
>--- a/dpi/bookmarks.c Sat Jul 27 12:54:47 2024
>+++ b/dpi/bookmarks.c Thu Aug 1 16:40:50 2024
>@@ -1606,6 +1606,20 @@ static void termination_handler(int signum)
> exit(signum);
> }
>
>+/**
>+ * Use unveil on OpenBSD
>+ */
>+static void dUnveil(const char *path, const char *perm)
>+{
>+ #ifdef ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
>+ if (unveil(path, perm) == -1) {
>+ MSG("unveil(%s, %s) failed: %s\n", path, perm, strerror(errno));
>+ exit(1);
>+ }
>+ #endif
>+ #endif
>+}
We can probably put the dUnveil() wrapper into dlib/ so it is available
in all the other parts.
>
> /*
> * -- MAIN -------------------------------------------------------------------
>@@ -1617,6 +1631,16 @@ int main(void) {
> char *tok;
> Dsh *sh;
>
>+ /* Use unveil on OpenBSD */
>+ #ifdef ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
I think the #ifdef ENABLE_UNVEIL is enough here, as we may have other
implementations handling it transparently for other platforms. Same for
the other cases except inside dUnveil().
>+ char *dil_bm = dStrconcat(dGethomedir(), "/.dillo/bm.txt", NULL);
>+ dUnveil(dil_bm, "rwc");
>+ dFree(dil_bm);
>+ unveil(NULL, NULL);
>+ #endif
>+ #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 Jul 27 12:54:47 2024
>+++ b/dpi/cookies.c Thu Aug 1 16:40:50 2024
>@@ -1632,6 +1632,20 @@ static void termination_handler(int signum)
> exit(signum);
> }
>
>+/**
>+ * Use unveil on OpenBSD
>+ */
>+static void dUnveil(const char *path, const char *perm)
>+{
>+ #ifdef ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
>+ if (unveil(path, perm) == -1) {
>+ MSG("unveil(%s, %s) failed: %s\n", path, perm, strerror(errno));
>+ exit(1);
>+ }
>+ #endif
>+ #endif
>+}
>
> /*
> * -- MAIN -------------------------------------------------------------------
>@@ -1643,6 +1657,16 @@ int main(void) {
> int sock_fd, code;
> char *buf;
> Dsh *sh;
>+
>+ /* Use unveil on OpenBSD */
>+ #ifdef ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
>+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL);
>+ dUnveil(dil_loc, "rwc");
>+ dFree(dil_loc);
>+ unveil(NULL, NULL);
>+ #endif
>+ #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 Jul 27 12:54:47 2024
>+++ b/dpi/datauri.c Thu Aug 1 16:40:50 2024
>@@ -280,6 +280,21 @@ static unsigned char *datauri_get_data(char *url, size
> return data;
> }
>
>+/**
>+ * Use unveil on OpenBSD
>+ */
>+static void dUnveil(const char *path, const char *perm)
>+{
>+ #ifdef ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
>+ if (unveil(path, perm) == -1) {
>+ MSG("unveil(%s, %s) failed: %s\n", path, perm, strerror(errno));
>+ exit(1);
>+ }
>+ #endif
>+ #endif
>+}
>+
> /*
> *
> */
>@@ -289,6 +304,17 @@ int main(void)
> unsigned char *data;
> int rc;
> size_t data_size = 0;
>+
>+ /* Use unveil on OpenBSD */
>+ #ifdef ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
>+ dUnveil("/tmp", "rwc");
>+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL);
>+ dUnveil(dil_loc, "rwc");
>+ dFree(dil_loc);
>+ unveil(NULL, NULL);
>+ #endif
>+ #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 Jul 27 12:54:47 2024
>+++ b/dpi/downloads.cc Thu Aug 1 16:40:50 2024
>@@ -1098,12 +1098,45 @@ static void custLabelMeasure(const Fl_Label* o, int& W
> fl_measure(o->value, W, H, interpret_symbols);
> }
>
>+/**
>+ * Use unveil on OpenBSD
>+ */
>+static void dUnveil(const char *path, const char *perm)
>+{
>+ #ifdef ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
>+ if (unveil(path, perm) == -1) {
>+ MSG("unveil(%s, %s) failed: %s\n", path, perm, strerror(errno));
>+ exit(1);
>+ }
>+ #endif
>+ #endif
>+}
>
>-
> //int main(int argc, char **argv)
> int main()
> {
> int ww = 420, wh = 85;
>+
>+ /* Use unveil on OpenBSD */
>+ #ifdef ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
>+ dUnveil("/tmp", "rwc");
>+ dUnveil("/etc/fonts", "r");
>+ dUnveil("/usr/local/bin/wget", "x");
>+ char *xauth_loc = dStrconcat(dGethomedir(), "/.Xauthority", NULL);
>+ dUnveil(xauth_loc, "r");
>+ dFree(xauth_loc);
>+ dUnveil("/usr/local/share/fonts", "r");
>+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL);
>+ dUnveil(dil_loc, "rwc");
>+ dFree(dil_loc);
>+ char *dl_loc = dStrconcat(dGethomedir(), "/Downloads", NULL);
>+ dUnveil(dl_loc, "rwc");
>+ dFree(dl_loc);
>+ unveil(NULL, NULL);
>+ #endif
>+ #endif
>
> Fl::lock();
>
>diff -upr a/dpi/file.c b/dpi/file.c
>--- a/dpi/file.c Sat Jul 27 12:54:47 2024
>+++ b/dpi/file.c Thu Aug 1 16:40:50 2024
>@@ -1063,6 +1063,20 @@ static int File_check_fds(uint_t seconds)
> return st;
> }
>
>+/**
>+ * Use unveil on OpenBSD
>+ */
>+static void dUnveil(const char *path, const char *perm)
>+{
>+ #ifdef ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
>+ if (unveil(path, perm) == -1) {
>+ MSG("unveil(%s, %s) failed: %s\n", path, perm, strerror(errno));
>+ exit(1);
>+ }
>+ #endif
>+ #endif
>+}
>
> int main(void)
> {
>@@ -1070,6 +1084,19 @@ int main(void)
> socklen_t sin_sz;
> int sock_fd, c_st, st = 1;
>
>+ /* Use unveil on OpenBSD */
>+ #ifdef ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
>+ dUnveil("/tmp", "rw");
>+ char *dl_loc = dStrconcat(dGethomedir(), "/Downloads", NULL);
>+ dUnveil(dl_loc, "rw");
>+ dFree(dl_loc);
>+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL);
>+ dUnveil(dil_loc, "rwc");
>+ unveil(NULL, NULL);
>+ #endif
>+ #endif
>+
> /* Arrange the cleanup function for abnormal terminations */
> if (signal (SIGINT, termination_handler) == SIG_IGN)
> signal (SIGINT, SIG_IGN);
>diff -upr a/dpi/ftp.c b/dpi/ftp.c
>--- a/dpi/ftp.c Sat Jul 27 12:54:47 2024
>+++ b/dpi/ftp.c Thu Aug 1 16:40:50 2024
>@@ -272,6 +272,21 @@ static int try_ftp_transfer(char *url)
> return (no_such_file ? -1 : (aborted ? -2 : nb));
> }
>
>+/**
>+ * Use unveil on OpenBSD
>+ */
>+static void dUnveil(const char *path, const char *perm)
>+{
>+ #ifdef ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
>+ if (unveil(path, perm) == -1) {
>+ MSG("unveil(%s, %s) failed: %s\n", path, perm, strerror(errno));
>+ exit(1);
>+ }
>+ #endif
>+ #endif
>+}
>+
> /*
> *
> */
>@@ -281,6 +296,21 @@ 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 ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
>+ dUnveil("/tmp", "rwc");
>+ dUnveil("/usr/local/bin/wget", "x");
>+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL);
>+ dUnveil(dil_loc, "rwc");
>+ dFree(dil_loc);
>+ char *dl_loc = dStrconcat(dGethomedir(), "/download", NULL);
>+ dUnveil(dl_loc, "rwc");
>+ dFree(dl_loc);
>+ unveil(NULL, NULL);
>+ #endif
>+ #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 Jul 27 12:54:47 2024
>+++ b/dpi/vsource.c Thu Aug 1 16:40:50 2024
>@@ -178,6 +178,21 @@ void send_html_text(Dsh *sh, const char *url, int data
> a_Dpip_dsh_write_str(sh, 1, "</table></body></html>");
> }
>
>+/**
>+ * Use unveil on OpenBSD
>+ */
>+static void dUnveil(const char *path, const char *perm)
>+{
>+ #ifdef ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
>+ if (unveil(path, perm) == -1) {
>+ MSG("unveil(%s, %s) failed: %s\n", path, perm, strerror(errno));
>+ exit(1);
>+ }
>+ #endif
>+ #endif
>+}
>+
> /*
> *
> */
>@@ -187,6 +202,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 ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
>+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL);
>+ dUnveil(dil_loc, "r");
>+ dFree(dil_loc);
>+ unveil(NULL, NULL);
>+ #endif
>+ #endif
>
> _MSG("starting...\n");
> //sleep(20);
>diff -upr a/dpid/main.c b/dpid/main.c
>--- a/dpid/main.c Sat Jul 27 12:54:47 2024
>+++ b/dpid/main.c Thu Aug 1 16:41:04 2024
>@@ -220,6 +220,21 @@ static int get_open_max(void)
> #endif
> }
>
>+/**
>+ * Use unveil on OpenBSD
>+ */
>+static void dUnveil(const char *path, const char *perm)
>+{
>+ #ifdef ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
>+ if (unveil(path, perm) == -1) {
>+ MSG("unveil(%s, %s) failed: %s\n", path, perm, strerror(errno));
>+ exit(1);
>+ }
>+ #endif
>+ #endif
>+}
>+
> /*! \todo
> * \li Add a dpid_idle_timeout variable to dpidrc
> * \bug Infinite loop if plugin crashes before it accepts a connection
>@@ -236,6 +251,17 @@ int main(void)
> services_list = NULL;
> //daemon(0,0); /* Use 0,1 for feedback */
> /* TODO: call setsid() ?? */
>+
>+ /* Use unveil on OpenBSD */
>+ #ifdef ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
>+ dUnveil("/usr/local/lib/dillo", "rx");
>+ dUnveil("/usr/local/etc/dillo", "r");
>+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL);
>+ dUnveil(dil_loc, "rwc");
>+ unveil(NULL, NULL);
>+ #endif
>+ #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 Jul 27 12:54:47 2024
>+++ b/src/dillo.cc Thu Aug 1 16:40:06 2024
>@@ -379,6 +379,21 @@ static DilloUrl *makeStartUrl(char *str, bool local)
> return start_url;
> }
>
>+/**
>+ * Use unveil on OpenBSD
>+ */
>+static void dUnveil(const char *path, const char *perm)
>+{
>+ #ifdef ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
>+ if (unveil(path, perm) == -1) {
>+ MSG("unveil(%s, %s) failed: %s\n", path, perm, strerror(errno));
>+ exit(1);
>+ }
>+ #endif
>+ #endif
>+}
>+
> /*
> * MAIN
> */
>@@ -462,7 +477,34 @@ int main(int argc, char **argv)
> fclose(fp);
> }
> dLib_show_messages(prefs.show_msg);
>-
>+
>+ // Use unveil on OpenBSD
>+ #ifdef ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
>+ dUnveil("/usr/local/share/fonts", "r");
>+ dUnveil("/usr/local/share/icons", "r");
>+ dUnveil("/usr/X11R6/share/X11/locale", "r");
>+ dUnveil("/usr/X11R6/lib/X11/fonts", "r");
>+ dUnveil("/usr/local/etc/dillo", "r");
>+ dUnveil("/tmp", "rwc");
>+ dUnveil("/usr/local/bin/dpid", "x");
>+ dUnveil("/etc/fonts", "r");
>+ dUnveil("/etc/resolv.conf", "r");
>+ dUnveil("/etc/ssl/cert.pem", "r");
>+ dUnveil(prefs.save_dir, "rwc");
What happens if someone puts save_dir to $HOME?, should we restrict it
maybe?
>+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL);
>+ dUnveil(dil_loc, "rwc");
>+ dFree(dil_loc);
>+ char *icons_loc = dStrconcat(dGethomedir(), "/.icons", NULL);
>+ dUnveil(icons_loc, "r");
>+ dFree(icons_loc);
>+ char *xauth_loc = dStrconcat(dGethomedir(), "/.Xauthority", NULL);
>+ dUnveil(xauth_loc, "r");
>+ dFree(xauth_loc);
>+ unveil(NULL, NULL);
>+ #endif
>+ #endif
>+
> // initialize internal modules
> a_Dpi_init();
> a_Dns_init();
>diff -upr a/configure.ac b/configure.ac
>--- a/configure.ac Sat Jul 27 12:54:47 2024
>+++ b/configure.ac Thu Aug 1 16:40:16 2024
>@@ -36,6 +36,11 @@ AC_ARG_ENABLE([insure],
> [enable_insure=$enableval],
> [enable_insure=no])
>
>+AC_ARG_ENABLE([unveil],
>+ [AS_HELP_STRING([--enable-unveil], [Build with support for unveil])],
>+ [enable_unveil=$enableval],
>+ [enable_unveil=no])
>+
> AC_ARG_ENABLE([ipv6],
> [AS_HELP_STRING([--enable-ipv6], [Build with support for IPv6])],
> [enable_ipv6=$enableval],
>@@ -619,6 +624,9 @@ if test "x$enable_insure" = "xyes" ; then
> CC="insure -Zoi \"compiler $CC\""
> LIBS="$LIBS -lstdc++-2-libc6.1-1-2.9.0"
> fi
>+if test "x$enable_unveil" = "xyes" ; then
>+ AC_DEFINE([ENABLE_UNVEIL], [1], [Enable unveil])
>+fi
> if test "x$enable_threaded_dns" = "xyes" ; then
> CFLAGS="$CFLAGS -DD_DNS_THREADED"
> fi
>@@ -725,4 +733,5 @@ _AS_ECHO([ GIF enabled : ${enable_gif}])
> _AS_ECHO([ SVG enabled : ${enable_svg}])
> _AS_ECHO([])
> _AS_ECHO([ HTML tests : ${html_tests_ok}])
>+_AS_ECHO([ unveil enabled : ${enable_unveil}])
> _AS_ECHO([])
>diff -upr a/dpi/bookmarks.c b/dpi/bookmarks.c
>--- a/dpi/bookmarks.c Sat Jul 27 12:54:47 2024
>+++ b/dpi/bookmarks.c Thu Aug 1 16:40:50 2024
>@@ -1606,6 +1606,20 @@ static void termination_handler(int signum)
> exit(signum);
> }
>
>+/**
>+ * Use unveil on OpenBSD
>+ */
>+static void dUnveil(const char *path, const char *perm)
>+{
>+ #ifdef ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
>+ if (unveil(path, perm) == -1) {
>+ MSG("unveil(%s, %s) failed: %s\n", path, perm, strerror(errno));
>+ exit(1);
>+ }
>+ #endif
>+ #endif
>+}
>
> /*
> * -- MAIN -------------------------------------------------------------------
>@@ -1617,6 +1631,16 @@ int main(void) {
> char *tok;
> Dsh *sh;
>
>+ /* Use unveil on OpenBSD */
>+ #ifdef ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
>+ char *dil_bm = dStrconcat(dGethomedir(), "/.dillo/bm.txt", NULL);
>+ dUnveil(dil_bm, "rwc");
>+ dFree(dil_bm);
>+ unveil(NULL, NULL);
>+ #endif
>+ #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 Jul 27 12:54:47 2024
>+++ b/dpi/cookies.c Thu Aug 1 16:40:50 2024
>@@ -1632,6 +1632,20 @@ static void termination_handler(int signum)
> exit(signum);
> }
>
>+/**
>+ * Use unveil on OpenBSD
>+ */
>+static void dUnveil(const char *path, const char *perm)
>+{
>+ #ifdef ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
>+ if (unveil(path, perm) == -1) {
>+ MSG("unveil(%s, %s) failed: %s\n", path, perm, strerror(errno));
>+ exit(1);
>+ }
>+ #endif
>+ #endif
>+}
>
> /*
> * -- MAIN -------------------------------------------------------------------
>@@ -1643,6 +1657,16 @@ int main(void) {
> int sock_fd, code;
> char *buf;
> Dsh *sh;
>+
>+ /* Use unveil on OpenBSD */
>+ #ifdef ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
>+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL);
>+ dUnveil(dil_loc, "rwc");
>+ dFree(dil_loc);
>+ unveil(NULL, NULL);
>+ #endif
>+ #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 Jul 27 12:54:47 2024
>+++ b/dpi/datauri.c Thu Aug 1 16:40:50 2024
>@@ -280,6 +280,21 @@ static unsigned char *datauri_get_data(char *url, size
> return data;
> }
>
>+/**
>+ * Use unveil on OpenBSD
>+ */
>+static void dUnveil(const char *path, const char *perm)
>+{
>+ #ifdef ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
>+ if (unveil(path, perm) == -1) {
>+ MSG("unveil(%s, %s) failed: %s\n", path, perm, strerror(errno));
>+ exit(1);
>+ }
>+ #endif
>+ #endif
>+}
>+
> /*
> *
> */
>@@ -289,6 +304,17 @@ int main(void)
> unsigned char *data;
> int rc;
> size_t data_size = 0;
>+
>+ /* Use unveil on OpenBSD */
>+ #ifdef ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
>+ dUnveil("/tmp", "rwc");
>+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL);
>+ dUnveil(dil_loc, "rwc");
>+ dFree(dil_loc);
>+ unveil(NULL, NULL);
>+ #endif
>+ #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 Jul 27 12:54:47 2024
>+++ b/dpi/downloads.cc Thu Aug 1 16:40:50 2024
>@@ -1098,12 +1098,45 @@ static void custLabelMeasure(const Fl_Label* o, int& W
> fl_measure(o->value, W, H, interpret_symbols);
> }
>
>+/**
>+ * Use unveil on OpenBSD
>+ */
>+static void dUnveil(const char *path, const char *perm)
>+{
>+ #ifdef ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
>+ if (unveil(path, perm) == -1) {
>+ MSG("unveil(%s, %s) failed: %s\n", path, perm, strerror(errno));
>+ exit(1);
>+ }
>+ #endif
>+ #endif
>+}
>
>-
> //int main(int argc, char **argv)
> int main()
> {
> int ww = 420, wh = 85;
>+
>+ /* Use unveil on OpenBSD */
>+ #ifdef ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
>+ dUnveil("/tmp", "rwc");
>+ dUnveil("/etc/fonts", "r");
>+ dUnveil("/usr/local/bin/wget", "x");
>+ char *xauth_loc = dStrconcat(dGethomedir(), "/.Xauthority", NULL);
>+ dUnveil(xauth_loc, "r");
>+ dFree(xauth_loc);
>+ dUnveil("/usr/local/share/fonts", "r");
>+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL);
>+ dUnveil(dil_loc, "rwc");
>+ dFree(dil_loc);
>+ char *dl_loc = dStrconcat(dGethomedir(), "/Downloads", NULL);
>+ dUnveil(dl_loc, "rwc");
>+ dFree(dl_loc);
>+ unveil(NULL, NULL);
>+ #endif
>+ #endif
>
> Fl::lock();
>
>diff -upr a/dpi/file.c b/dpi/file.c
>--- a/dpi/file.c Sat Jul 27 12:54:47 2024
>+++ b/dpi/file.c Thu Aug 1 16:40:50 2024
>@@ -1063,6 +1063,20 @@ static int File_check_fds(uint_t seconds)
> return st;
> }
>
>+/**
>+ * Use unveil on OpenBSD
>+ */
>+static void dUnveil(const char *path, const char *perm)
>+{
>+ #ifdef ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
>+ if (unveil(path, perm) == -1) {
>+ MSG("unveil(%s, %s) failed: %s\n", path, perm, strerror(errno));
>+ exit(1);
>+ }
>+ #endif
>+ #endif
>+}
>
> int main(void)
> {
>@@ -1070,6 +1084,19 @@ int main(void)
> socklen_t sin_sz;
> int sock_fd, c_st, st = 1;
>
>+ /* Use unveil on OpenBSD */
>+ #ifdef ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
>+ dUnveil("/tmp", "rw");
>+ char *dl_loc = dStrconcat(dGethomedir(), "/Downloads", NULL);
>+ dUnveil(dl_loc, "rw");
>+ dFree(dl_loc);
>+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL);
>+ dUnveil(dil_loc, "rwc");
>+ unveil(NULL, NULL);
>+ #endif
>+ #endif
>+
> /* Arrange the cleanup function for abnormal terminations */
> if (signal (SIGINT, termination_handler) == SIG_IGN)
> signal (SIGINT, SIG_IGN);
>diff -upr a/dpi/ftp.c b/dpi/ftp.c
>--- a/dpi/ftp.c Sat Jul 27 12:54:47 2024
>+++ b/dpi/ftp.c Thu Aug 1 16:40:50 2024
>@@ -272,6 +272,21 @@ static int try_ftp_transfer(char *url)
> return (no_such_file ? -1 : (aborted ? -2 : nb));
> }
>
>+/**
>+ * Use unveil on OpenBSD
>+ */
>+static void dUnveil(const char *path, const char *perm)
>+{
>+ #ifdef ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
>+ if (unveil(path, perm) == -1) {
>+ MSG("unveil(%s, %s) failed: %s\n", path, perm, strerror(errno));
>+ exit(1);
>+ }
>+ #endif
>+ #endif
>+}
>+
> /*
> *
> */
>@@ -281,6 +296,21 @@ 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 ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
>+ dUnveil("/tmp", "rwc");
>+ dUnveil("/usr/local/bin/wget", "x");
>+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL);
>+ dUnveil(dil_loc, "rwc");
>+ dFree(dil_loc);
>+ char *dl_loc = dStrconcat(dGethomedir(), "/download", NULL);
>+ dUnveil(dl_loc, "rwc");
>+ dFree(dl_loc);
>+ unveil(NULL, NULL);
>+ #endif
>+ #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 Jul 27 12:54:47 2024
>+++ b/dpi/vsource.c Thu Aug 1 16:40:50 2024
>@@ -178,6 +178,21 @@ void send_html_text(Dsh *sh, const char *url, int data
> a_Dpip_dsh_write_str(sh, 1, "</table></body></html>");
> }
>
>+/**
>+ * Use unveil on OpenBSD
>+ */
>+static void dUnveil(const char *path, const char *perm)
>+{
>+ #ifdef ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
>+ if (unveil(path, perm) == -1) {
>+ MSG("unveil(%s, %s) failed: %s\n", path, perm, strerror(errno));
>+ exit(1);
>+ }
>+ #endif
>+ #endif
>+}
>+
> /*
> *
> */
>@@ -187,6 +202,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 ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
>+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL);
>+ dUnveil(dil_loc, "r");
>+ dFree(dil_loc);
>+ unveil(NULL, NULL);
>+ #endif
>+ #endif
>
> _MSG("starting...\n");
> //sleep(20);
>diff -upr a/dpid/main.c b/dpid/main.c
>--- a/dpid/main.c Sat Jul 27 12:54:47 2024
>+++ b/dpid/main.c Thu Aug 1 16:41:04 2024
>@@ -220,6 +220,21 @@ static int get_open_max(void)
> #endif
> }
>
>+/**
>+ * Use unveil on OpenBSD
>+ */
>+static void dUnveil(const char *path, const char *perm)
>+{
>+ #ifdef ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
>+ if (unveil(path, perm) == -1) {
>+ MSG("unveil(%s, %s) failed: %s\n", path, perm, strerror(errno));
>+ exit(1);
>+ }
>+ #endif
>+ #endif
>+}
>+
> /*! \todo
> * \li Add a dpid_idle_timeout variable to dpidrc
> * \bug Infinite loop if plugin crashes before it accepts a connection
>@@ -236,6 +251,17 @@ int main(void)
> services_list = NULL;
> //daemon(0,0); /* Use 0,1 for feedback */
> /* TODO: call setsid() ?? */
>+
>+ /* Use unveil on OpenBSD */
>+ #ifdef ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
>+ dUnveil("/usr/local/lib/dillo", "rx");
>+ dUnveil("/usr/local/etc/dillo", "r");
>+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL);
>+ dUnveil(dil_loc, "rwc");
>+ unveil(NULL, NULL);
>+ #endif
>+ #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 Jul 27 12:54:47 2024
>+++ b/src/dillo.cc Thu Aug 1 16:40:06 2024
>@@ -379,6 +379,21 @@ static DilloUrl *makeStartUrl(char *str, bool local)
> return start_url;
> }
>
>+/**
>+ * Use unveil on OpenBSD
>+ */
>+static void dUnveil(const char *path, const char *perm)
>+{
>+ #ifdef ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
>+ if (unveil(path, perm) == -1) {
>+ MSG("unveil(%s, %s) failed: %s\n", path, perm, strerror(errno));
>+ exit(1);
>+ }
>+ #endif
>+ #endif
>+}
>+
> /*
> * MAIN
> */
>@@ -462,7 +477,34 @@ int main(int argc, char **argv)
> fclose(fp);
> }
> dLib_show_messages(prefs.show_msg);
>-
>+
>+ // Use unveil on OpenBSD
>+ #ifdef ENABLE_UNVEIL
>+ #ifdef __OpenBSD__
>+ dUnveil("/usr/local/share/fonts", "r");
>+ dUnveil("/usr/local/share/icons", "r");
>+ dUnveil("/usr/X11R6/share/X11/locale", "r");
>+ dUnveil("/usr/X11R6/lib/X11/fonts", "r");
>+ dUnveil("/usr/local/etc/dillo", "r");
>+ dUnveil("/tmp", "rwc");
>+ dUnveil("/usr/local/bin/dpid", "x");
>+ dUnveil("/etc/fonts", "r");
>+ dUnveil("/etc/resolv.conf", "r");
>+ dUnveil("/etc/ssl/cert.pem", "r");
>+ dUnveil(prefs.save_dir, "rwc");
>+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL);
>+ dUnveil(dil_loc, "rwc");
>+ dFree(dil_loc);
>+ char *icons_loc = dStrconcat(dGethomedir(), "/.icons", NULL);
>+ dUnveil(icons_loc, "r");
>+ dFree(icons_loc);
>+ char *xauth_loc = dStrconcat(dGethomedir(), "/.Xauthority", NULL);
>+ dUnveil(xauth_loc, "r");
>+ dFree(xauth_loc);
>+ unveil(NULL, NULL);
>+ #endif
>+ #endif
>+
> // initialize internal modules
> a_Dpi_init();
> a_Dns_init();
>_______________________________________________
>Dillo-dev mailing list -- dillo-dev(a)mailman3.com
>To unsubscribe send an email to dillo-dev-leave(a)mailman3.com
3 months, 2 weeks
Various minor patches
by jcid＠dillo.org
On Wed, Jan 30, 2008 at 03:21:41PM +0100, Christian Kellermann wrote:
> * Jorge Arellano Cid <jcid(a)dillo.org> [080130 15:06]:
> > On Wed, Jan 30, 2008 at 10:51:19AM -0300, Jorge Arellano Cid wrote:
> > > On Sun, Jan 27, 2008 at 05:10:19PM +0100, Christian Kellermann wrote:
> > > > * Johannes Hofmann <Johannes.Hofmann(a)gmx.de> [080125 20:21]:
> > > > > On Mon, Jan 21, 2008 at 04:03:47PM +0100, Christian Kellermann wrote:
> > > > > > > On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote:
> > > > > > > > 1) detect_libiconv.diff
> > > > > > > >
> > > > > > > > src/decode.c uses iconv_open but - at least on FreeBSD - libiconv
> > > > > > > > is not in the default linker path, making the build abort. Add
> > > > > > > > a simple test to configure.in to check for libiconv's presence
> > > > > > > > and usability and a substitution for ICONV_LIBS to src/Makefile.am.
> > > > > > >
> > > > > > > Very nice! The same problem exists on DragonFly...
> > > > > >
> > > > > > This breaks configure for me (OpenBSD/386 -stable). seems the test does not use the LDFLAGS=-L/usr/local/lib... My knowledge (and motivation) to fiddle with this autoconf hell is limited, so I'd kindly hand the ball over to someone else.
> > > > >
> > > > > What exactly is breaking? Can you provide config.log?
> > > > >
> > > > > Here on DragonFly linking was failing with unresolved symbols,
> > > > > but it turned out that the problem was caused by a libiconv
> > > > > package that was no longer needed. The iconv stuff is now handled
> > > > > in libc on DragonFly...
> > > >
> > > > I have attached the log. Seems like the function signature differs
> > > > on OpenBSD a bit. The testcase modified as such that it includes
> > > > <iconv.h> and calling iconv_open("",""); works for me when doint
> > > > it manually.
> > > >
> > > > I don't know what happens here...
> > > >
> > > > Kind regards,
> > >
> > > Does it fail with current CVS?
> >
> > Sorry, from the log it's clear it doesn't.
> >
> > This page seems to have good info:
> >
> > http://synflood.at/blog/index.php?/plugin/tag/bsd
> >
> > (my understanding of German is barely for survival. ;).
> >
>
> Yes it does describe my problem, but how do we fix this in a portable way?
Before this patch, we had no test for iconv. Did it work for you then?
--
Cheers
Jorge.-
16 years, 9 months
flicker at reload
by jcid＠dillo.org
On Tue, Oct 13, 2009 at 07:13:45PM +0200, Johannes Hofmann wrote:
> Hi Stefan,
>
> On Tue, Oct 13, 2009 at 06:48:51PM +0200, Stefan Strobl wrote:
> > Hello
> >
> > I'm new to both dillo and fltk. I'm trying to do two things and I'm
> > hoping you can point me in the right directions on how to do it.
> >
> > 1) flicker at reload
> > When doing a reload my screen flickers and I'd like to get rid of that.
> > I first tried the dillorc option buffered_drawing=0/1/2 but that didn't
> > make any difference. I then tried to find the source where the screen is
> > cleared before redrawing the page. I followed the source of redraw()
> > until layout.cc where topLevel->draw() is executed but I cannot find its
> > implementation.
>
> I would recommend to start in FltkViewBase::draw(). Or maybe
> FltkViewport::draw() if you are interested in scrolling too.
>
> > Is the flickering an fltk issue or where is the screen cleared?
>
> I'm not sure. It might just be that the freshly loaded page is
> rendered while it is not 100% loaded, which would blank the screen.
> Then it is drawn again after loading has completed.
> I would suggest to put printf()s in FltkViewBase::draw() (the actual
> draw) and Layout::queueResize() (which requests a complete redraw)
> to see what is going on. You can also use gdb an breakpoints of
> course.
> The flickering is certainly caused by dillo code and is not a
> general issue of fltk.
>
> >
> > 2) externally trigger reload
> > I'd like to trigger a page reload externally by another application. I
> > searched a bit about IPC mechanisms of fltk but didn't find any. So I'm
> > thinking about using a UNIX fifo or the system signal SIGUSR2. Do you
> > think this is a good approach?
>
> If you just need to trigger a reload, SIGUSR2 might be ok. For a
> more general remote control fifo's or maybe stdin might be an
> option. You can check what other browsers do.
Ditto.
I have the idea of a remote control dpi for dillo that allows
to command it as necessary (think of a help browser). In this
case you'd need reload and maybe the ability to send it to other
pages or make it cycle or whatever. This feature needs a revision
of the dillo plugin protocol (DPIP). I've been working on it for
some time now, and hope to commit big changes this month.
With regard to using dillo as a display for embedded devices,
the idea is feasible and you'd be good testing with SIGUSR2 and
reload by now.
The golden idea is to use dpip to be able to update individual
widgets using DOM. That would be really good. Specially if there
was an interested sponsor! ;)
--
Cheers
Jorge.-
15 years, 1 month
--xid option
by jcid＠dillo.org
On Tue, May 26, 2009 at 08:17:53PM +0200, Johannes Hofmann wrote:
> On Tue, May 19, 2009 at 08:24:14PM +0200, Johannes Hofmann wrote:
> > On Tue, May 19, 2009 at 01:34:56PM -0400, Jorge Arellano Cid wrote:
> > > On Mon, May 18, 2009 at 11:14:14PM +0200, Johannes Hofmann wrote:
> > > > On Mon, May 18, 2009 at 01:48:43PM -0400, Jorge Arellano Cid wrote:
> > > > > On Mon, May 18, 2009 at 01:18:11AM +0200, Johannes Hofmann wrote:
> > > > > > Hi,
> > > > > >
> > > > > > attached patch tries to implement the missing --xid option that is
> > > > > > used to embed dillo into the claws mailer.
> > > > > > The right way to do this would probabely be to implement the
> > > > > > complete XEMBED protocol which is also mentioned in
> > > > > > doc/fltk-problems.doc.
> > > > > > However a simple XReparentWindow() seems to work more or less here.
> > > > > > Please test.
> > > > >
> > > > > It seems like you forgot to commit xembed.{hh,cc} to the repo.
> > > > > e.g. hg add xembed.hh xembed.cc
> > > >
> > > > Oh yes. Should be fixed now.
> > > > Btw. I managed to install the claws mail client including the dillo
> > > > plugin and it seems to work fine now with dillo2. That's why I just
> > > > committed the xembed stuff.
> > >
> > > This is very good.
> > >
> > > I'll have to dig for the sylpheed contact to let them know.
> > > Does anybody here know the email?
> >
> > I already contacted them on irc (#claws on freenode).
> > It would be good if this get's some testing as there seems to be
> > some interaction with the WM in use. I now tested it successful
> > on dwm, twm, and fvwm.
> > Also there are probabely more elegant ways to do it, but
> > for now I think it's better than nothing.
>
> More testing showed that the current implementation has severe
> problems.
> The thing is that the window manager that I use (dwm) is one of the
> few non-reparenting WMs. Most others reparent new windows and that
> can create races with the reparentin we do.
> There also seems to be a problem with keyboard events in that case.
> Is there anyone on the list with in-depth X11 knowledge who could
> help with the xembed stuff?
Not me.
I've seen new patches in the repo so I assume this is more
or less being improved. Please let me know how it goes.
AFAIS the current repo is almost dillo-2.1. I'd freeze here
and only accept bug fixes and polish from now. Opinions?
--
Cheers
Jorge.-
15 years, 5 months
[Dillo-dev]Porting dillo to another UI toolkit
by Sebastian Geerken
Hi,
I intended to post this a bit later, not before some usable code is
available, but I changed my opinion, it may be useful to outline, how
porting will happen.
The most complex part is certainly Dw, since it is tightly bound to
Gtk+. By all means, I want to prevent, that there exist different
versions of Dw, with different features (e.g., when the development of
the Gtk+ version continues, while the FLTK version is developed),
which are hard to integrate.
For this reason (and others), I'm currently working on a redesign of
Dw, which will make Dw toolkit independant. This is not the single
goal of this redesign, it will also make some other features possible,
e.g. a preview window, in which the whole page may be seen with
reduced size, also, it will make reusage of Dw within graphical
plugins possibel, and some more. (Actually, the idea for this design
is already older, except the platform independency, but this was simple
to add.)
I'll soon (within a week or so) post the first usable version of it,
which will only include a small program to test Dw, not dillo itself,
the integration into dillo will be done later. However, it will
already make it possible to start with the porting work.
A documentation, which changes should remain small, is already
attached.
As for the actual port, the following steps should be done:
1. Realize the test program, but for another UI toolkit. This will
still have to include Gtk+, because of the Gtk+ object model,
but the new toolkit should be in control over the event
processing. (Furthermore, GLib will, in this phase, still be
needed.)
What is needed for this step:
(i) an implementation of DwRenderPlatform and DwRenderView,
and
(ii) ports of the modules Dw_style and Dw_tooltip. These will
perhaps also be abstracted, see DwRender.txt for
details.
The rest should not be touched, if this should become necessary,
this is a bug.
The changes in Dw_style and Dw_tooltip should not be too hard,
and these modules will not change much in the near future, so
this simple approach for porting is reasonable in this case. The
experiences made on this should be interesting, if the design of
Dw_style and Dw_tooltip should be enhanced, as described as an
idea in the attached document.
2. The second step (regarding Dw) should be to get rid of Gtk+ and
GLib. Since a port to FLTK is planned, it makes sense to port
the C code to C++, this would also make the code cleaner, since
dealing with classes and interfaces in C (with the Gtk+ model)
is quite fiddly.
Details of this step have still to be clarified, but the
features, GLib and Gtk+ provides, should be relatively easily
replaced.
Notice also, that I plan to make an own library of Dw (at least the
core of it), most of it has already been finished, but the release has
been delayed, because I assign a greater priority to the dillo
project.
For the rest of the port, I do not have any plans, but AFAIS, I see
far less problems as for Dw.
Sebastian
20 years, 2 months
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
4 months
Feature Request
by newman.x＠gmail.com
Jorge Arellano Cid wrote:
> On Sat, Nov 08, 2008 at 10:58:43PM +0100, Michal Nowak wrote:
>> me at swva wrote:
>>> I think I'm being unclear, in two ways.
>>>
>>>>> Just to check, I did this as root :
>>>>>
>>>>> [root@Hbsk2 btth]# rpm -q dillo
>>>>> dillo-0.8.6-7.fc9.i386
>>>>> [root@Hbsk2 btth]# yum update dillo
>>> ^^^^^^^^^^^^^^^^
>>>>> Loaded plugins: refresh-packagekit
>>>>> updates-newkey | 2.3 kB 00:00
>>>>> updates | 2.6 kB 00:00
>>>>> fedora | 2.4 kB 00:00
>>>>> Setting up Update Process
>>>>> No Packages marked for Update
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>> [root@Hbsk2 btth]#
>>> On Sat, 8 Nov 2008, Johannes Hofmann wrote:
>>>
>>>> dillo-0.8.6 is no longer supported and you should consider to
>>>> upgrade to dillo-2.0.
>>>> But nevertheless for me it also works with dillo-0.8.6.
>>> For those who run other OSs, what the emphasized lines mean is the
>>> 0.8.6 is what Fedora has, period. (I run F9, the latest release.) Any
>>> idea why it's so far behind?? I didn't realize 1.0 had become official,
>>> let alone 2.0
>>>
>> That's life. In Fedora, nor even Rawhide, isn't Dillo v2.0. Two reasons:
>>
>> 1) No one packed FLTK 2.x, check repository there's still 1.1.9.
>> 2) Because of (1) no Dillo 2.
>>
>> Although Fedora is usually fresh, in case of Dillo it's still on Dillo
>> 0.8.6 mainline. Feel free to file bug (bugzilla.redhat.com) against
>> Dillo and Package Review for FLTK2, but be aware that having unstable
>> FLTK 2.x in Fedora might be quite fight. (Believe me I am Fedora
>> packager.)
>
> Dillo2 doesn't need an FLTK2 package installed!
> It can be statically linked in. One package, that's it.
> (this is the default BTW).
>
Sure I am aware of that, but wrt Fedora, it's something neat forbidden
https://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryPolicy
unless necessary (and this is not the case).
> Now, if distros need to also provide source packages by policy,
> then that's a different story.
>
Correct. FLTK can't just be present in compile time, somehow, toolchain
has to be clear and for everyone from day0.
> Please clarify me because I've read that complaint a few times,
> and don't yet know whether it's my fault not making the statical
> linking clear enough to packagers, or if there's a packaging
> policy issue I don't know of. :)
>
From my POV, in distros we don't want static built packages; security
flaws in linked-in libraries is the main concern. One has to rebuild all
apps with those libraries, not just the library (obvious).
I don't thing it will be that hard to get FLTK & Dillo2 into Fedora, the
thing is that no one did it till now :). (And I ma pretty busy at work &
uni :) ).
Michal
16 years
Re: [Dillo-dev] [RFC] Plans for next version of tab patch
by Sebastian Geerken
On Tue, Jun 17, Jorge Arellano Cid wrote:
>
> Hi Frank,
>
> On Tue, 17 Jun 2003, Frank de Lange wrote:
>
> > Hej!
> >
> > Now that the first release of my tab patch is 'out there', I'd like to
> > give a short overview of my plans for the next version of this patch.
>
> If geocities stops working just let me know, or ask Andreas who
> mirrored the patch...
>
> > I
> > do not know when I'll be able to release this next version, as I'm busy
> > this week, followed by a trip to the UK (back the 13th of juli), but I
> > will try to make it relatively soon...
>
> No problem.
>
>
> Some time ago (maybe a lot), Arvind told me he had developed a
> "tabs" patch for dillo:
>
> http://www.dillo.org/test/dillo_tabs.png
>
> He had to work on it some more, then he got very busy, and I
> haven't heard of it in a long time...
>
> Technically, what interests me more about the patch is the
> separation of interface code out of document code.
>
> Now Sebastian is working on another separation; for CSS (it
> also involves several files), so I think it is better to keep
> both works separated until our re-structuring of the parser is
> well defined.
>
> I'd advise you to choose a date from CVS and improve the patch
> against it (not trying to catch up with current); that way the
> patch can be polished without too much hassle and with the
> feedback of interested developers.
>
> Then, when the time to merge comes, it will be stable, clean
> and polished.
>
> Personally, I can't look at it right now (because of the above
> mentioned reasons, plus I'm dedicated to the dillo plugins
> extensions).
>
> NOTE: We have advanced a lot with Ferdi on dpid, so it will
> soon be integrated and commited.
>
> ... it has come a tradition (or better, our way of development)
> to test a lot the patches before commiting them in. That way, the
> CVS keeps stable, the code clean, and we can keep up with the
> ideal of always releasing a better Dillo than the former.
>
> As you noticed, the patch generated a lot of feedback. I hope
> patches start to come just as bug notes! ;)
>
>
> > [...]
> >
> > Jorge, let me know if/when you plan to commit the patch to CVS
>
> (read above)
>
> Last, but not the least, I also think that tabbing is a
> function that should/must be done by the WM. I always try to find
> "the right place" to put a patch, and IMO it belongs to the WM.
>
> Now, as these days only a few WMs come with good tabs support,
> and as the patch seems small, it should pose no major trouble to
> eventually commit it.
>
>
> Welcome aboard!
> Jorge.-
>
> _______________________________________________
> Dillo-dev mailing list
> Dillo-dev(a)lists.auriga.wearlab.de
> http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
21 years, 4 months
Various minor patches
by Johannes.Hofmann＠gmx.de
On Wed, Jan 30, 2008 at 03:21:41PM +0100, Christian Kellermann wrote:
> * Jorge Arellano Cid <jcid(a)dillo.org> [080130 15:06]:
> > On Wed, Jan 30, 2008 at 10:51:19AM -0300, Jorge Arellano Cid wrote:
> > > On Sun, Jan 27, 2008 at 05:10:19PM +0100, Christian Kellermann wrote:
> > > > * Johannes Hofmann <Johannes.Hofmann(a)gmx.de> [080125 20:21]:
> > > > > On Mon, Jan 21, 2008 at 04:03:47PM +0100, Christian Kellermann wrote:
> > > > > > > On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote:
> > > > > > > > 1) detect_libiconv.diff
> > > > > > > >
> > > > > > > > src/decode.c uses iconv_open but - at least on FreeBSD - libiconv
> > > > > > > > is not in the default linker path, making the build abort. Add
> > > > > > > > a simple test to configure.in to check for libiconv's presence
> > > > > > > > and usability and a substitution for ICONV_LIBS to src/Makefile.am.
> > > > > > >
> > > > > > > Very nice! The same problem exists on DragonFly...
> > > > > >
> > > > > > This breaks configure for me (OpenBSD/386 -stable). seems the test does not use the LDFLAGS=-L/usr/local/lib... My knowledge (and motivation) to fiddle with this autoconf hell is limited, so I'd kindly hand the ball over to someone else.
> > > > >
> > > > > What exactly is breaking? Can you provide config.log?
> > > > >
> > > > > Here on DragonFly linking was failing with unresolved symbols,
> > > > > but it turned out that the problem was caused by a libiconv
> > > > > package that was no longer needed. The iconv stuff is now handled
> > > > > in libc on DragonFly...
> > > >
> > > > I have attached the log. Seems like the function signature differs
> > > > on OpenBSD a bit. The testcase modified as such that it includes
> > > > <iconv.h> and calling iconv_open("",""); works for me when doint
> > > > it manually.
> > > >
> > > > I don't know what happens here...
> > > >
> > > > Kind regards,
> > >
> > > Does it fail with current CVS?
> >
> > Sorry, from the log it's clear it doesn't.
> >
> > This page seems to have good info:
> >
> > http://synflood.at/blog/index.php?/plugin/tag/bsd
> >
> > (my understanding of German is barely for survival. ;).
> >
>
> Yes it does describe my problem, but how do we fix this in a portable way?
Not sure, it describes the same problem.
I think the problem is that libiconv only exports
libiconv_open() and the corresponding iconv.h header file defines
iconv_open to libiconv_open.
Unfortunately the test program generated by autoconf does not
include iconv.h.
Johannes
>
> --
> You may use my gpg key for replies:
> pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)
> _______________________________________________
> Dillo-dev mailing list
> Dillo-dev(a)dillo.org
> http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
16 years, 9 months
Future of dillo2
by jcid＠dillo.org
On Mon, May 12, 2008 at 06:24:30PM +0100, Jeremy Henty wrote:
> On Mon, May 12, 2008 at 12:20:45PM -0400, Jorge Arellano Cid wrote:
> > On Mon, May 12, 2008 at 03:52:59PM +0000, corvid wrote:
> > > The consequences of not informing the outside world about the progress
> > > of dillo in any detail: http://wiki.linuxfromscratch.org/blfs/wiki/dillo2
> >
> > Please feel free to write them to get that page back on track before
> > somebody believes what was written. ;)
>
> I have a BLFS Trac account so I can probably do it myself. But what
> should I change? At a glance:
>
> * We *do* support FTP and HTTPS.
> * Change "can support cookies" to "supports cookies".
Yes, but https is basic. If a page has multiple images, the
dialog window may spam the user once per image. That's why https
went disabled for normal users, and experienced guys/devs were
left the chance to enable it.
> * "Dillo always interprets web pages as if they had the ISO-8859-1
> encoding." True?
It depends on what dillo they talk about. It looks like a
dillo2 page, and in that case, it's FLTK2-based, it has nothing
to do with GTK1, glib nor GTK2, just FLTK2. The code is now a
mixture of C/C++ instead of pure C, etc...
It's important to make a difference between dillo1 (C lang,
GTK1/glib, __unmantained__, and dillo2 (active branch).
If we talk about dillo2 then the statement:
"Dillo always interprets web pages as if they had the
ISO-8859-1 encoding."
is absolutely false.
>
> * "useless for reading non-English web pages" Surely not true, though
> maybe "useless for reading multibyte-encoded pages" is true.
If we talk about dillo2, false again.
Dillo2 uses utf-8 by default, and utf-8 is multibyte-encoded.
On top of that we have all the work corvid put in the character
decoding, so now dillo2 can decode a boat load of charsets into
utf-8 using iconv.
Non english pages render quite well provided you have the
necessary fonts installed. There're a few exceptions as with
those that render backwards or have collapsing glyphs.
For instance, set:
vw_fontname="DejaVu Sans"
in ~/.dillo/dillorc2
and go to:
http://www.gnu.org/home.fa.html
Worth a thounsand words!
then go to:
http://www.gnu.org/
scroll to the bottom and you'll see plenty of non-english
pages, that you can click into.
If you go to:
http://www.bds-bg.org/
you'll see windows-1251 charset handled properly by dillo.
etc.
> Anything else?
Yes, we should compile and provide this information from our
web site. Otherwise it will be extremely hard for a non-developer
to get right.
A good diff document may be got from reviewing the Changelog
alone. Here we have the record of all the work we've put in
dillo2; from time to time I find there things forgotten long ago!
I'll try to update some pages in the site as soon as I find
some time. That's the point: lack of time/manpower. All the help
is appreciated.
Another very important point to be stated is that the plugins
and the dpi daemon need to be installed for most things to work.
After the build this is done with: make install-strip.
Bottom line: current dillo2 is for developers. After we make a
release it will be user ready.
HTH.
--
Cheers
Jorge.-
16 years, 6 months