dillo-2.1.tar.bz2
by devidfil＠gmail.com
On Thu, Jun 18, 2009 at 6:57 PM, Jorge Arellano Cid<jcid(a)dillo.org> wrote:
> Hi,
>
> ?Working on:
>
> ? ? 1.- Solve the OpenSSL license issue and upload rc3.
>
>
> On Thu, Jun 18, 2009 at 05:24:25PM +0200, Devid Antonio Filoni wrote:
>> On Wed, Jun 17, 2009 at 11:45 PM, Jorge Arellano Cid<jcid(a)dillo.org> wrote:
>> > On Wed, Jun 17, 2009 at 10:01:12PM +0200, Devid Antonio Filoni wrote:
>> > [...]
>> > ?Devid: please send me the .deb and its directions when done.
>> DONE! You can find it at https://launchpad.net/~d.filoni/+archive/ppa
>> . However I found an error checking my package using lintian:
>>
>> E: dillo: possible-gpl-code-linked-with-openssl
>> N:
>> N: ? ?This package appears to be covered by the GNU GPL but depends on the
>> N: ? ?OpenSSL libssl package and does not mention a license exemption or
>> N: ? ?exception for OpenSSL in its copyright file. The GPL (including version
>> N: ? ?3) is incompatible with some terms of the OpenSSL license, and therefore
>> N: ? ?Debian does not allow GPL-licensed code linked with OpenSSL libraries
>> N: ? ?unless there is a license exception explicitly permitting this.
>> N:
>> N: ? ?If only the Debian packaging, or some other part of the package not
>> N: ? ?linked with OpenSSL, is covered by the GNU GPL, please add a lintian
>> N: ? ?override for this tag. Lintian currently has no good way of
>> N: ? ?distinguishing between that case and problematic packages.
>> N:
>> N: ? ?Severity: serious, Certainty: wild-guess
>>
>> Can you please fix it?
>
> ?AFAIS, the only program that links to OpenSSL is the https dpi.
> i.e. The ssl-enabled dillo binary doesn't link to it.
> ? ? https.filter.dpi links to it.
>
> ?IANAL, but it looks like giving permission for this dpi is enough,
> and it's already done in its sources (dpi/https.c):
>
> ?* [...]
> ?* As a special exception permission is granted to link the code of
> ?* the https dillo plugin with the OpenSSL project's "OpenSSL"
> ?* library, and distribute the linked executables, without including
> ?* the source code for OpenSSL in the source distribution. You must
> ?* obey the GNU General Public License, version 3, in all respects
> ?* for all of the code used other than "OpenSSL".
> ?*
> ?*/
>
>
> ?Please let me know if this is _really_ enough or if some extra
> legal formula must be added somewhere else.
It should be enough, at least this is what I see for example at
http://lists.octality.com/pipermail/cherokee/2008-November/009408.html
(take a look in that page for more infos)
> ?TIA.
>
> --
> ?Cheers
> ?Jorge.-
>
> _______________________________________________
> Dillo-dev mailing list
> Dillo-dev(a)dillo.org
> http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
>
Devid
June 18, 2009
dillo 2.1
by sandshrew＠gmail.com
On Mon, Jun 22, 2009 at 06:49:06PM +0200, Johannes Hofmann wrote:
> Hi Tomas,
>
> On Mon, Jun 22, 2009 at 05:12:07PM +0300, Tomas R wrote:
> > Been testing dillo 2.1 for some time and would like to share my
> > experience.
> >
> > It's really great to see some basic css support (appearance of most if
> > not all websites has improved alot), properly resized images,
> > redirection and basic authentication working now :)
> >
> > Anyway, even dillo improved alot recently there still seems to be some
> > issues. Here are some I've noticed after testing this release for few
> > days:
> > Rendering
> > 1) ubuntu.lt
> > Not sure if it's dillo fault or website's malformed stylesheet, but
> > with default dillo settings some of the lithuanian characters are not
> > displayed. This can be fixed by just adding "* {font-family:
> > serif !important}" to the style.css. Here is a pic with some of the
> > places where letters are missing marked in red:
> > http://img4.imageshack.us/img4/2227/ubuntult.png
>
> I guess the problem is that the font simply does not contain those
> glyphs. There are some rules how this case should be handled, but
> dillo does not implement them currently.
>
I see.
> > 2) gmail
> > It's nice that login works now, but with default dillo settings the
> > size of most of the text is 1px. This can be partially fixed by adding
> > font_min_size to dillorc, but it's obviously a dillo bug as this
> > doesn't happen with links-hacked.
>
> I don't have a gmail account, so I can't reproduce it, but
> there seems to be a general bug in the CSS code that makes fonts
> smaller than in other browsers.
The account is just few clicks away ;)
> > 3) google
> > What's with the textarea in the top left corner of the page? And just
> > for information: signing out doesn't work because it requires basic
> > javascript support (works with links-hacked).
>
> That textarea is in the google page. It's just hidden due to a
> "display: none" CSS directive which is not supported yet by dillo.
> Actually I'd like to know the reason why it is there before
> hiding it.
>
I guess, that's a honeypot for spambots.
> > 4) Black on black, white on white...
> > http://www.nma-fallout.com/forum/viewtopic.php?t=42776&start=2660&sid=a5712…
> > For some reason black font color is used here and we get black text on
> > black background in some posts (doesn't happen with links-hacked).
>
> Oh. This is just horrible HTML / CSS, it's full of bugs!
> The reason for black on black is:
> <body bgcolor="#000000" text="#C0C0C0" link="#33CC00" vlink="#33CC00" />
>
> I.e. body is immediately closed. But there is tons of other bugs on
> this page.
I see. I'll try to contact the admin and see if I can fix some of the bugs.
> > http://www.acetoneteam.org/
> > Background color is not set here and if we have "body
> > {background-color: white}" rule in our style.css file, we get white
> > text on white background.
>
> dillo does not handle color definitions of the form rgb(255,255,255)
> yet. I guess we can fix that.
>
Sounds good :)
> > 5) http://ubuntuforums.org/showthread.php?p=6592005
> > What's with the PINK blocks? If that's more of a "feature" then a bug,
> > can the color be changed by using some css rule?
>
> I can't find pink blocks on that page. Where exactly do you see
> them? Maybe post a screenshot.
>
Sure. Some of the blocks marked in red:
http://img20.imageshack.us/img20/2749/ubuntuforums.png
http://img20.imageshack.us/img20/6066/ubuntuforums1.png
> > 6) http://www.binaryworld.skynet.lt/DUK.html
> > If we use one link with fragment identifier in the page, all the others
> > are marked as visited too.
>
> Not sure how this should be handled correctly. Someone will have to
> check the specs.
>
I've checked opera, firefox, midori and chromium (aka google chrome under
BSD license) browsers. None of them act like that.
> > 7) Authentication
> > Basic authentication does work now, but at first the server displays a
> > message saying "wrong credentials or browser doesn't
> > understand how to supply the credentials" and only then a window
> > pops up asking for the credentials...
> >
> > UI
> > 1) Positioning the tab close button on the top RIGHT corner of the
> > browser isn't a good thing because:
> > a) The distance between the most commonly used buttons and the tab
> > close button is pretty big (especially when widescreen monitors are
> > pretty common nowadays);
> > b) It only allows closing the active tab;
> > I think it would be much better if all tabs had close buttons or at
> > least the button was placed near the last tab.
>
> Agreed. Patch welcome :)
>
> > 2) Trivial but... because the setting to enable/disable image loading
> > now is in the wrench menu it is two clicks away instead of one as it
> > used to be in dillo 2.0. Maybe css settings could be left where they are
> > now, but the setting for enabling/disabling images could be moved where
> > it was in dillo 2.0?
> > 3) UPPERCASE letters should be used in the File menu to define keyboard
> > shortcuts, because now L looks like I (Open url... ctrl+l)
> > 4) Don't you think "Are you sure you want to close the browser?"
> > message is pretty annoying?
>
> Which one exactly? When exiting dillo with multiple tabs/windows
> open?
> I don't think dillo asks a lot for confirmation, but I normally use
> multiple Ctrl-q's to close all tabs and windows and quit.
>
Yup, the one with multiple tabs. I just use my WM's shortcut for closing the
window.
> >
> > Other:
> > It seems whoever designed the new website theme has no idea what
> > READABILITY means... It looks like someone just used some stupid online
> > color picker, which just picks some similar colors to the one user
> > chooses. The old website looked MUCH MUCH better. Imho, it's a
> > regression...
>
> Hm I like the new design, but I agree that readability might be a problem.
> Let's see what other say.
>
> >
> > PS: how to install dillo 2.1 claws-mail plugin?
>
> Just install claws and the dillo plugin from source or packages
> depending on your distribution.
> Then make sure that dillo-2.1 is the dillo binary in your PATH.
Ok, I'll try.
June 22, 2009
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
Aug. 1, 2024
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.-
Jan. 30, 2008
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.-
Oct. 13, 2009
--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.-
May 27, 2009
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
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
Nov. 9, 2008
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
Jan. 30, 2008
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.-
May 12, 2008