Search results for "plugin" - Dillo-dev

web bug save?

by bblochl＠arcor.de

Jorge Arellano Cid schrieb: > On Fri, Dec 25, 2009 at 05:46:22PM +0000, corvid wrote: > >> bb wrote: >> >>> *On http://www.dillo.org/ I found the item News and a remark: >>> >>> 03-Jul-2009 Dillo-2.1.1 has been released to provide a security fix >>> for malicious images. I am not shure what is meant with **malicious >>> images? Are this so called Web bugs? If yes - how is the blocking >>> done? >>> >> Here's the advisory about the image size problem: >> http://www.ocert.org/advisories/ocert-2009-008.html >> >> >>> I think there are some strategies possible to prevent a browser from >>> a Web Bug attack: >>> >>> 1. Dont allow to load gifs or pngs from another URL as the actual >>> page comes from. (I think to remember that firefox **originally >>> **had such an option - not available in the actual version.) >>> >> Here's the beginning of a thread and a patch experimenting with this: >> http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-September/006844.ht… >> >> (the "same host" option was found to be useless, but I'm still >> interested in >> "same domain") >> >> >>> 2. I think one might prepare HTML/CSS not to load such gifs or pngs >>> smaller than say about 5x5. Do you think such a measure is feasible >>> in Dillo and could that really stop Web Bugs? But I think that there >>> should not be a problem to make Web Bugs larger than 1x1pixel as >>> long as they are transparent - may be I am wrong, I am just a simple >>> minded user, not a web professional. So such a limit might be useless? >>> > > AFAIS your analysis is correct. There's no problem in increasing the > web bug image size, specially on these broadband days... > > Personally I have hopes on restricting resource loading from other > sites, > but as corvid cites, it's non trivial and requires careful thought. > > As a highly interested user, you may gather some information on > web bugs, techniques to avoid them etc. and post a summary of > your findings here. That would help a lot. We have the knowledge > on how to code dillo and restricted time to work on it. If you > can help us everybody gains. > > > >> Here's a post and patch experimenting with rejecting images with a >> dimension >> of 0: >> http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-December/007101.html >> >> >> >>> Are there other ideas? I am highly interested in that Web Bug problem. >>> >> I'm glad to hear this, since user interest may encourage things to >> happen... >> > > I'm very interested in this topic, although haven't found free time > these days... > > > Thank you for your response. The begin of my web bug adventure was some curiousity as I gamed around with http://livehttpheaders.mozdev.org. I found some strange things, and momentarily felt like the guy in "The blue velvet", finding an cut ear and come into touch with an strange and eval world outside a wardrobe. The real eval things can only be done by javascript - so dillo is on the save side. It may be of general Interest: I found as a countermeasure the plugin ghostery for firefox. ghostery has a large list of known web bugs and can block it. Most of that software one may find is googles urchin.js, but ggogle has a new software ga.js. There was even launched "Turn Key Web Analytics In A Box" on Friday, December 18, 2009, see http://www.coradiant.com/news/091209_analyticsbox.htm. The List of web bugs you can find: http://code.google.com/p/ghostery/source/browse/trunk/firefox/ghostery-stat… One may check out a read-only working copy anonymously over HTTP: http://code.google.com/p/ghostery/source/checkout As I just pointed out, a dillo user cannot be tracked by any javascript code. But even a simple Web Bug with a http-rquest to a tracking server can get a lot of Information about the request AFAIK that is client IP address, certainly the request date/time, the page requested, HTTP code, bytes served, user agent, and referer. So the tracker knows the URL of the page containing the bug and allows the server to determine which particular Web page the user has accessed. But more, the URL of the bug can be appended with an arbitrary string in various ways with extra information to identify the loading conditions of the bug. This extra information can be added while sending the page or by JavaScript scripts after the download (but as ponted out - no Javascript with Dillo). Web bugs can also be used in combination with HTTP cookies (if there are any) like any other object transferred using the HTTP protocol. One might say, use a proxy. But I found that nearly all of the free proxys are real trojans and sending such web bugs, most often in the advertising pictures. I asked a couple of the providers of free proxy services. The usual answer was, that they do not send web bugs, but the bad advertisers do. And usually they offered ma thei payed service that is free of advertising. And very often that web bug requests will NOT be send via the proxy!! You sent me an option switch to forbid dillo to request another domain as that of the actually used page: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-September/006844.ht… How can I patch Dillo in this way? It might be useful to have that as an option in Dillo, I am shure not every user is comfortable with that restriction. Seasons greetings BB

14 years, 10 months

[Dillo-dev]Tabs/Frames/Kbnav

by Jorge Arellano Cid

Hi, Now that dillo 0.8.1 is done, I want to clarify what happened with the Tabs/Frames/KeybNav patch. Sometime has passed since, but at the time we decided to not stir an already ungrateful situation. Here I'm forwarding a couple of emails that should be enough to do it (dillo-dev archives holds the rest). Sincerely Jorge.- -------------------------------------------------------------------------- From akemnade(a)informatik.uni-bremen.de Mon May 17 08:44:51 2004 Date: Sat, 27 Mar 2004 14:25:31 +0100 From: Andreas Kemnade <akemnade(a)informatik.uni-bremen.de> To: Sebastian Geerken <s.geerken(a)ping.de> Cc: jcid(a)dillo.org Subject: Re: [Dillo-dev]Frame support in CVS Hi Sebastian, Hi Jorge, On Sun, 7 Mar 2004 22:14:49 +0100 Sebastian Geerken <s.geerken(a)ping.de> wrote: > Hi Andreas. > > (I'm writing this in English to make forwarding etc. simpler.) > > Jorge and I would indeed like to incorporate Frank's work into the > main trunk, but unfortunately Frank refused to clean up the code, and > finally, he quit the project, and plans to make an own version of > dillo. I've a mail of 8 Jan, which I can forward you, if you are > interested. > Please send me that mail. Ok, perhaps I was not deep enough in the archives. I just did not find any statement about what has to be done with the patch. I think other readers of dillo-dev do not know about that, too. Perhaps it would be better if that was more clarified but I also understand that you do not want to repeat yourself too often. > If you want to commit some work, you may clean up the patch, > especially split it up into several parts. Most important, there are > three parts: DilloDoc (which I'd like to be renamed), frames, and > tabs. They are of course related, but it would be handy to have single > patches for them (because of the over-linear correlation of patch size > and review time). > Most the time I was just happy to be able to apply the frames patch. I was not forced to look at the code. But with the massive conflicts the patch produces when I applied it to 0.8 I really had to start to look at the patch. Sometimes being not a maintainer has really big advances... If I checked the patch size before fixing the conflicts I guess I would have given up. I have never noticed before how big the patch was. If splitting does not work, then there is something really wrong with the code. So let's divide and conquer. I think an important part is to remove nice (but not very important) features from the patch which can be added separetely later on. I think I can find time in the next month to split and clean up the frame patch. Greetings Andreas Kemnade -------------------------------------------------------------------------- From s.geerken(a)ping.de Mon May 17 08:44:37 2004 Date: Sat, 10 Jan 2004 13:04:11 +0100 From: Sebastian Geerken <s.geerken(a)ping.de> To: Jorge Arellano Cid <jcid(a)dillo.org> Subject: Fwd: Re: Notes on keyboard navigation FYI. [ Part 2: "Included Message" ] Date: Thu, 08 Jan 2004 22:31:10 +0100 From: Frank de Lange <frank(a)unternet.org> To: Sebastian Geerken <s.geerken(a)ping.de> Subject: Re: Notes on keyboard navigation Sebastian Geerken wrote: >Hi Frank. > >First of all, a happy new year! > >Several notes on keyboard navigation: > >1. Jorge and I decided, that we do not immediately support keyboard > configuration, also because it is rather unclear what widget > toolkit will be used in the future. So the version of keyboard > navigation, which will be integrated the first time, should have > hard-coded keys. > >2. Some days ago, I committed some changes to iterators, you may be > interested in. There is some description within doc/Dw.txt, section > "Anchors and Scrolling", subsection "Scrolling". Especially, > scrolling has now two dimensions, there is a new scrolling > position, DW_[HV]POS_INTO_VIEW, and DwIterator::scroll_to has been > replaced by the more general DwIterator::get_allocation. > >3. I noticed some performance problems with stress tests, I'm not sure > they play a role in real life. Anyway, you wrote on the list that > you are already working on in. > >Sebastian > > Happy new year as well... and thanks for the notice. For keyboard navigation to work in a sensible way x coördinate support is useful... so useful that I had already implemented it. The performance problems have been solved in my tree as well, as I have stated in my last message to the list. They are caused by the use of g_list_search_custom to find the focusable in focus.c. Using a hash table solved this. But... I have decided to discontinue support to the Dillo project as of the 'infringer' message to the list, so I will no longer post or update patches to Dillo. Instead, I am working on a new browser which should fill the same niche as Dillo (small, fast, enough features for most sites so it can be used as main browser). Starting point for this is my patched version of Dillo, with additional changes: - dpi and dpid and related things are gone (DONE) - library plugins for everything dpi did, and more (mime decoders, schemes, etc) (DONE) - ccc is on the way out, to be replaced by something less convoluted and more general (WORK IN PROGRESS) - DOM support with new xml parser (WORK IN PROGRESS) The project currently uses GTK+ as toolkit, but might switch to something else (FLTK is a candidate). A side goal for this project is to be developer-friendly. Patches are welcome, they will get their own space on the site (which will be on savannah, which is still not completely recovered from the break-in yet... hence the delay). I may post a short notice to the list if/when the project is up and ready for testing. Good luck with Dillo. Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

20 years, 5 months

Re: [Dillo-dev] An odd request, I know...

by Jorge Arellano Cid

On Sat, 24 Jan 2004, Tom Barnes-Lawrence wrote: > Hi again, > On Mon, Jan 19, 2004 at 06:29:16PM -0300, Jorge Arellano Cid wrote: > > > Firstly, I'd like to say I've been using Dillo for over 2 years now, > > > and find it fantastic. Well, apart from a few little details (which > > > I'll probably post to the list in a couple of days, when I'm less > > > busy). So anyways, very well done for this piece of software! > > > > Thanks for your comments. A long time user, that's good news! > > Hehe, you haven't heard my complaints yet ;) Don't worry, they're > not so bad, and I'm not going to go making demands. Here you go: > > -I understand you not wanting the referer info being sent, even if > it does make the logs from my hit-counter a bit less useful, *but*, > some sites do seem to use the referer tags to work out if you're > accessing their images, etc deep-linked from some other page. > I'm afraid I can sort of sympathise with this, as the idea of > "stealing bandwidth" does have quite a lot of truth in it (it > does cost them money). > So, perhaps (as someone else suggested) Dillo could have some > button or menu option, etc that we could click to allow the > referer tags to be set temporarily for pages that need them? > Or alternatively, images on pages could automatically have the > referer tags set for them, or they could be used for accessing > *any* other file on the same server perhaps. Just thoughts. > > -It's great that the cache is used so aggressively with static > content, it keeps things very very fast, keeps the network > usage down, and is very useful when the connection goes down; > but it does seem to get used in many places where it really > shouldn't, such as dynamic content (revisit certain CGI scripts > and you just get the cache), and that problem with images- where > if a screenful of images stops loading, refreshing will *not* reload > the half-done images. > OTOH, it's *good* that dynamic content doesn't get reevaluated when > I press the *back* button. That's a PITA when other browsers do that, > as I usually just want to go back to where I was before. After considering it through the time, I believe that the problem with referer and the cache issue, can be solved using a similar technique to what we use with cookies. Unfortunately some standards allow for easy abuse of the technologies they describe. Sometimes it is the same RFC the one that warns about the problems that may arise! For instance image request with referer (as you suggest) is the basis for a spying technology widely known as web bugs. Allowing our cache to honour http cache directives blindly, would allow sites to send a refresh request on each of their advertising banners (and they usually get paid for request so this practice is very common). That's the reason why going back or forward in history is a PITA with browsers that follow them. Keeping Dillo as it is now, and allowing the user to site-tune it with regard to cookies, cache and referer is a solution that solves a broad range of problems. > > -It's probably because I'm using a snapshot of 0.8.0-pre from about > November with Frank's tabs patch (OK maybe the tabs patch doesn't > affect this), but once or twice I've found my load average go way > up, and looking at PS, found dpid spawning the https plugin > repeatedly (with each one dying again so there was only ever one > at a time). IIRC this happened (some time) after quitting Dillo. > Perhaps this is one of the things you've fixed since then. Yes, I fixed that. > -MOST important to me: Bookmarks. I like the way Dillo now has > bookmarks shown as a web page instead of a menu, I like that it allows > us to put them into categories, and I like that the DPI system allows > the bookmarks to be controlled by a separate program. > Unfortunately, bookmarks are still one of the main reasons I still > use Konqueror (despite the stupid crashes): I have lots of them, > last time I tried to work it out I calculated maybe a thousand- > and a great many of these are *not* pr0n! The only way I can cope > with so many of them is having them organised into a very deep > heirarchy. But not only does Dillo's bookmarks program not allow > this, but it has every single bookmark shown on the same page! The > scrollbar control is tiny! > So, I'd love it if the bookmarks code stuck each section in its own > page, and let me nest one section in another. Perhaps the current > version is only temporary, so you'd have time to work on other > stuff, and all this is already planned, but I thought I ought to > mention it because *this* is one thing that would really make > Dillo great for me. I'd have a go at this myself, but I've already > got lots of other things to do. OK, I suppose you do as well. Yes, I have much more to do than what I can cope with. So I sort it by priority and work on the top. As Thorben remarked, a very important point of dpis is to allow for multiple implementations of them. This is reinforced by the fact that writing a dpi doesn't require knowledge about dillo's internal working. With bookmarks, it keeps the bm list in memory, so making it to return the section list (in whatever format) and to bind each section with a page specific for it, is a one day effort. Testing it to work reliably and comfortably takes more time. If someone comes with a better implementation of bm, it may end as the default and the current one as an option. > That's it, really. For me, the problems are definitely oughtweighed > by Dillo's good points, like the stability and speed, I just want > to be able to use it a lot more! Stability!, thanks for the comment. It takes a great effort from our team to keep it stable. That's the unsexy work of chasing bugs, polishing the code, commenting, careful patch reviewing, and thoughtful design. Cheers Jorge.-

20 years, 9 months

Updated unveil patch

by a1ex＠dismail.de

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

3 months, 2 weeks

Re: [Fwd: Dillo article precisions]

by Jorge Arellano Cid

Hi Henry, On Tue, Oct 03, 2006 at 02:30:33PM -0700, Henry Kingman wrote: > Hi Jorge, > > I tried to update our article with some of the details you sent. > > Thanks, and good luck with the Dillo project! I hope you find funding. Thanks for the corrections. One important precision: the dillo project needs at least two core developers working on it fulltime. Not only me. If there's only one person working full time on it, it's not enough to keep the pace of evolving technologies. That's what I meant when writing: > > The situation is this: there're two core developers. We need at > >least to be both working on Dillo full time (ideally three devs.) > >otherwise the project would lag behind the moving target that > >Internet browsing is. I find this paragraph misleading: "Alternatively, Cid says he will release the FLTK2 port if he finds enough funding to be able to continue working fulltime on the port himeself. He said, "Given the current situation, the best option seems to be to remain closed until funding happens." and it's not true. Please make the correction. -- Cheers Jorge.- > > -Henry > > cc: Rick, executive editor > > -- > Henry Kingman, senior editor > LinuxDevices.com > Ziff Davis Internet > 775 625-4547 > > > > > > > >-------- Original Message -------- > >Subject: Dillo article precisions > >Date: Tue, 3 Oct 2006 09:40:28 -0400 > >From: Jorge Arellano Cid <jcid(a)dillo.org> > >To: Rick Lehrbaum <rick(a)linuxdevices.com> > >CC: Dillo mailing list <dillo-dev(a)lists.auriga.wearlab.de> > > > >Hi Rick, > > > > It's being a long time since my last article at linuxdevices, > >receive my greetings from Chile! > > > > With regard to the new article: > > > > http://linuxdevices.com/news/NS4370323584.html > > > > It caught me by surprise. There was a thread in dillo-dev and > >some users suggested that campaign. I was commenting on gross > >factual mistakes in the wiki when it was announced that an > >article was live at linuxdevices. > > > > It's good to see our users' interest in keeping the project > >alive, so I'll comment the article here so you can correct and > >improve the article: > > > > > >>A project to create an ultra-lightweight web browser for use in > >>embedded devices and other resource-constrained hardware has > >>issued a plea for financial help. The Dillo Project says it needs > >>to find a corporate sponsor in order to add anti-aliased text, > >>CSS, Javascript, and internationalization/localization support. > > > > We've almost finished the port to FLTK2, and it already has > >anti-aliased text. (Dillo doesn't compile with FLTK1) > > > > FLTK2 uses UTF8 and provides antialiasing so it solves the > >problem of using GTK1 (this was one of the reasons for GTK1 to go > >GTK2). > > > > UTF8 also makes it easy to add i18n and l10n without breaking > >things inside the browser. > > > > I point this technical details because unofficial patches have > >been developed for antialiasing, i18n and l10n for GTK1. This is > >a good workaround but not a long term solution. > > > > > >> > >>(Click for larger screenshot of Dillo) > > > > Here you'll find a screenshot of dillo-fltk2: > > > > http://www.dillo.org/test/ph2.png > > > > (it shows antialiasing) > > > > > >> > >>Dillo is a very lightweight (about 350 KB) browser supporting a > >>subset of HTML, CGI, SSL, and cookies. > > > > And plugins. > > + Images (GIF, PNG and JPEG) > > > >> Dillo is not really > >>practical for browsing the modern Internet, due to missing > >>support for frames, CSS, Javascript, and other commonly used > >>standards and protocols. It also lacks support for anti-aliased > >>text, something even Linux desktop users have long taken for > >>granted, and appears to have only rudimentary HTML error handling > >>capabilities. > > > > The HTML error handling has improved a lot (the bug meter can > >atest that), but yes, error handling is not as advanced as with > >Firefox. > > > > Anyway, sometimes there're pages with a few hundred mistakes > >handled gracefully. ;-) > > > > > >>Nonetheless, Dillo is extremely fast and lightweight, using less > >>memory in some cases than popular text-based browsers such as > >>lynx. And, since it supports CGI, it could be useful as a > >>framework for simple device interfaces based on Web standards, > >>such as survey kiosks and other closed, "walled garden" > >>applications. > > > > BTW, the new Dillo with a statically linked FLTK2 is about > >820 Kilobytes. > > > >> > >>Additionally, Dillo is popular with web developers due to > >>excellent HTML error reporting. > > > > :-) > > > > > >> > >>Dillo is expected to gain support for anti-aliased text after its > >>development team completes a port to FLTK (fast light toolkit, > >>aka "fulltick"). > > > > [Already there, see above] > > > >> However, founder Jorge Arellano Cid appears > >>adamant that funding be located prior to release of his > >>nearly-complete FLTK port, according to a "save Dillo" campaign > >>page hosted here. > > > > True. > > > > The situation is this: there're two core developers. We need at > >least to be both working on Dillo full time (ideally three devs.) > >otherwise the project would lag behind the moving target that > >Internet browsing is. > > > > Sebastian (the other core developer) is employed fulltime in > >Germany so he has almost no time to Develop. I don't have funds > >to keep on working fulltime too, so if there're no funds the > >project will loose the main developers and their knowledge. > > > > With regard to releasing. That's what I've done for 6+ years > >with GTK1 and no funding happened ;-). > > > > If there were more interested developers in working with Dillo > >(lets say 6 serious and qualified people) I would consider > >releasing because the project could advance in that case. > > > > Believe it or not I asked in dillo-dev, and there was only one > >answer from a dev that could put 4 hours/week and that had no > >FLTK2 knowledge nor on Dillo internals. > > > > Given the current situation, the best option seems to remain > >closed until funding happens. > > > > > >> > >>Other ongoing Dillo development efforts reportedly include CSS > >>support (said to be "70 percent complete") and JavaScript > >>support, as well as additional internationalization (I18n) and > >>localization (l10n) features. > > > > I reported 70% on CSS. This is on the FLTK2 branch, not from > >external efforts. > > > > The interesting part is that we paved the way for all these in > >the newest branch, so now it's much easier to develop them over > >the new code base than with the old branch. > > > > A rough timeline estimation would be near 2 years to have the > >whole set: antialiasing, CSS, I18n, l10n, Frames, Tabs, SSL and > >good Javascript. > > > > We could make a release in 6 months and thenceforth go on > >incrementally adding features in any desired order (probably this > >would be up to the sponsors' needs). > > > > > >>Additional details about Dillo can be found on Dillo's official > >>funding presentations page. For additional background, be sure to > >>read Cid's 2002 introduction to the browser, here. > >> > >>The Dillo project previously sought funding in February of 2004, > >>and was successful in obtaining a one-time grant through the > >>Linux Fund. > > > > > > Thanks a lot for your time and commitment. > > > > > > > -- > Henry Kingman, senior editor > LinuxDevices.com > Ziff Davis Internet > 775 625-4547 >

18 years, 1 month

Re: [Dillo-dev] Dillo on Windows fork

by Jorge Arellano Cid

Hi there, Unfortunately, I find myself compelled to answer to Mr. Robin Rowe's attacks, FUD, and all the false assertions he did about myself. Although I knew very few people would take the time to read the interview and then compare it to what Mr. Rowe says I said, I expected, from the long time you know me on this list, not to beleive his attacks without a hesitation. I'll make quotes and comment them. Please make your own comparisons and decide. Of course, you can browse the mailing list archives for the full threads: http://news.gmane.org/thread.php?group=gmane.comp.web.dillo.devel (search for September 2003) -- I'm quoting my missing emails, in full, here. Once I read that the only way to stop FUD was to rebate it point by point, so here I go: > Now, if you want to make dillo run on M$ Windoze natively, > you're on your own. Some of the reasons may be found in the > interview page: > > http://www.dillo.org/interview.html > > Thanks for the link. Very interesting. You sound quite hostile to Windows > users as a matter of personal politics. Please go to the interview and read it. If not at least search for these keywords: "windo" and "user". > May I ask, what does a policy of denying Dillo technical support to Windows > users accomplish? Unless using CYGWIN we have no Windows users because there's not a working native port yet. How can I be blamed for not supporting non-existent users? > Do you intend to prevent people from using software they > have already paid for anyway? _Ridiculous_. How can I prevent all (or some) of the windows users using their OS of choice. Mr. Rowe puts me as if I was trying to actively deny these people the right to use their SW. How? Turning off theiy machines from my house? Has anyone ever read such an statement from me in this mailing list? I read it again and again and can't understand why I'm bashed this way. > Should I throw away my copy of Windows 2000 to > accommodate your political views? Please, please, read the interview and search for such an statement. Incredible, Mr. Rowe keeps inventing implicit assertions, and then charging them on me. I've never said that. You can chose whatever OS you want. I'm only the project leader of a Free-SW project that aims for POSIX compliance. I even suggested him to try the recipe Kelson prepared about running dillo on Windows with CIGWIN. (http://www.hyperborea.org/software/dillo/cygwin.html) > To what point? I don't know, it was Mr. Rowe who invented this false accusation and blamed me for it. > You can't think it could > hurt Microsoft. And he suggests what I think too! Amazing. > You must know they aren't going to give me a refund. Please search for the keyword "refund" in the interview. You will not find it. It is just another invention that I'm accused for by Mr. Rowe. > If you change your mind and decide to answer my questions about what a few > troublesome pieces of Dillo code are intended to do that would be nice. Gentle words after the bashing. (this can confuse the careless reader, and make him think he's going through valid statements.) > But, if you prefer not to it is no big deal. Interesting. Then why did he take the time to prepare a set of false statements to attack me? > I've ported much more difficult > programs without help. To some extent, this is a compliment (I believe in Raph Levien's words that "SW design is a constant struggle against complexity"), but frankly I think his intention wasn't that. ...and as if this wasn't material enough, here are some other quotes from the next emails he sent: > In response to my request for technical information about Dillo to make it > easier for me to debug the Windows port, Jorge sent me an email off-list > last week in which he told me, "you're on your own" and directed me to > his interview at http://www.dillo.org/interview.html for the reason why. > What Jorge says there is he is opposed to supporting Windows users as a > matter of personal politics. Another lie! He says: "Jorge says there is he is opposed to supporting Windows users as a matter of personal politics". Here's my email: <q> On Thu, 28 Aug 2003, Robin Rowe wrote: > Jorge, > > I have Dillo built now as a native Windows VC++ 6 project and am debugging > it. Seems to be my unstable 1.14 version of GTK for Windows that is causing > Dillo to hang on load. By the way, I'm the new GTK1 for Windows maintainer. > Tor and GIMP for Windows are moving to GTK2, but CinePaint is staying with > GTK1. > > Can we talk about Dillo design portability a bit? Dillo is designed to run on POSIX compatible systems. If CYGWIN provides that, let it be (as stated in Kelson's doc). Now, if you want to make dillo run on M$ Windoze natively, you're on your own. Some of the reasons may be found in the interview page: http://www.dillo.org/interview.html (search for "windows", is quite a large text). Cheers Jorge.- </q> ------------------------------------- and here's my previous answer to him: ------------------------------------- <q> On Tue, 26 Aug 2003, Robin Rowe wrote: > Hi. I'm the project leader for CinePaint, an open source paint program used > mainly by the motion picture industry. Our code was branched from GIMP in > 1998. Hi! Yes, I knew about your project by the time we were applying to LinuxFund... > > How would the Dillo project feel about Dillo being embedded in another > application as a help browser? Very good. In fact it has been done in the past with the Sylpheed-claws email client: it embeds dillo for secure HTML mail viewing. In fact we're working in a remote control plugin for dillo to allow better support for this kind of functionality. Currently applications can launch Dillo and let the user navigate the help docs without problems. Now, if the app. wants to provide context sensitive help, it needs to end dillo and launch another instance to make it display the required page (quite fast, but not optimal), and here's where we're improving it. > We're looking for a new help system browser and considering Dillo. We are > impressed how compact your implementation is. We only need a limited set of > HTML features: links, images, tables, bullet lists, number lists, headings, > ordinary text, bold, and italic. In these features we need the browser to be > absolutely stable. Any issues there? None! You'll hardly find a browser that's more stable. And for any issue that may arise, you can email us back for support. > > We support all platforms, including Windows. One of the first things I would > intend to do is port Dillo to Windows. I saw in your archives that you had > made some effort in that direction, but it seemed to peter out. What are the > problems? If you need dillo to run on the dark side, take a look at: http://www.hyperborea.org/software/dillo/cygwin.html Cheers Jorge.- </q> ----------- Now, please excuse me if I don't want to answer any other email from Mr. Robin Rowe. I refuse to answer to Mr. Rowe because he has not the minimal manners to communicate politely and objectively (at least with me), and he attacks me upon false statements. ----------- Now, onto the technical reasons why I decided to aim dillo for POSIX and not for Windows (the use of advanced features of POSIX is a fact documented in a paper I wrote the year 2000). From Dillo project objectives perspective: The project objectives are: * The democratization of Internet information access. * Security and personal privacy. * High software efficiency. 1.- The democratization of Internet information access. Windows requires a modern machine to run (at least supported versions of it), and the pay of a licence fee. People with such a HW/SW configuration already have the means to afford their internet access. Now considering what happened to Netscape when trying to run on Windiws platforms it was quite clear there was no much future on that line. 2.- Security and personal privacy. Definitively a hard conflict with the windows platforms. A lot has been written about this topic, but let me suggest: http://www.hevanet.com/peace/microsoft.htm 3.- High software efficiency. A carefully crafted browser, with every single bit of speed we could think of, running over a bloated monster that makes modern computers feel slow? Now, as a tiny client for help documents, it may be, but Explorer is already loaded so... If someone someday makes dillo run on windows, I'll ask him to warn the users that they don't have the Security and personal privacy the original Dillo strives for (one of the best ways to spy any browser is to do in the internal firewall. You have all the HTTP traffic, the user IDs, etc.) Judge yourselves, I've had enough of it. Sincerely Jorge.-

21 years, 2 months

Re: Updated unveil patch

by Rodrigo Arias

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

3 months, 2 weeks

Re: [Dillo-dev] The kind of computer that is perfect for Dillo

by Jorge Arellano Cid

Hi, On Thu, Aug 31, 2006 at 09:47:00PM -0700, Globe Trotter wrote: > Hi, > > I read this thread and every post on here, and decided to respond. I really > love dillo and am frustrated that I still have to use other hogs such as > firefox and would really love to see it move so that I don't have to. I've devoted almost seven years of my life to make it happen. Of course I'd also love to see Dillo fulfilling its goals! Now, with lack of manpower/funds, that's not going to happen. Even if only one core developer gets to be working full time on it, it's not enough manpower to keep the pace of the moving target that a web browser is. With two core developers plus the usual free-lance developers: it could be. > > --- Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > > Although I certainly regard the "i18n" patch-gathering as a > > good thing for the user, IMO dillo-gtk1 is a dead end from the > > development point of view (even if the gathered patches were in > > line with the rest of dillo's design, which is not the case). > > > > GTK1 is an abandoned library, it has become the much bigger, > > slower and capable GTK2, precisely because it was not suited for > > solving certain "desktop" problems. > > > > You can read Owen Taylor's "Internationalization in GTK+" paper > > for a more solid basis on i18n design decisions (Owen is one of > > the main authors of GTK1 and GTK2). > > > > http://developer.gnome.org/doc/whitepapers/gtki18n/index.html > > > > It can be thought that Dillo "i18n" would have more hope if > > ported to GTK2. Following this line, we made some benchmarks, > > investigated in more depth, I had some emails with Owen, we had a > > discussion in the mailing list, and it turned out that: > > > > * GTK2 could double Dillo's footprint. > > * GTK2 has different expose model that woul require a redesign > > of the incremental rendering inside Dillo. > > * Dillo would become much slower and resource hungry. > > > > If Dillo becomes slower and has a bigger footprint, its main > > advantages start to dissapear when compared with let's say > > Firefox or Opera. In that case even I'd prefer to wait a bit > > longer for Firefox to start and then have a featureful browser. > > > > Dillo's main advantage is a tradeoff of features for speed. If > > the speed edge disappears, what do we have? > > > > In short, after lots of investigation we decided to port Dillo > > to FLTK2 (Although there's plenty of information about this in > > the mailing list, I realize it would be good to recapitulate this > > story and make this information together with future plans > > available from one page in our site. This mail is the first step > > in that direction). > > I agree, but when are you planning on releasing the FLTK2 port? _Probably_ when funding happens. > I think a lot > of people are waiting for this before they even start doing anything with > developing more, etc. If there's people willing to develop for Dillo seriously (6 months+ period) reading this, please show up on this thread! We need steady developers, that's the way to advance the project. Of course fixing small glitches helps, but that's polishing, not mainline. > > With regard to Javascript, yes we also agree that we need to > > support some scripting language (ECMA or whatever). We've > > developed in this direction too (For instance we have the DOM > > code almost ready, and dpi can provide the link to the script > > interpreter; we even have developed a prototype for scheme). > > > > Tabs are easy to add too, and although I hate frames, they > > should be supported (sigh). BTW, I always had this in mind and > > that's why it was easy to make a frames patch. The networking > > code was already designed for the parallelism this task requires. > > It's a matter of implementing its rendering. > > > > Somehow people tend to believe that features are not there > > because the core team doesn't want them. Or even because they do > > not have room in a minimalistic browser. This is _not_ true. The > > main reason is lack of manpower. > > Agreed: no question. Developing any product, much less a fabulous one like > dillo, needs huge manpower. Thanks for recognizing our effort. > > > > The other reasons are the GTK1 issue explained above and that > > these patches were not in line with the rest of the design, and > > that they break several things too (I've always asked authors to > > let their users know what each patch breaks). > > > > Having another design idea is valid, but it can't be pushed > > against those who think different (see LKML for examples! ;-). > > Forks had been announced but none thrived. > > > > > > > I also believe that Dillo shouldn't try to get CSS support; the last > > > thing I want is yet another browser with buggy CSS that I have to > > > design around. If Dillo is going to support CSS, I don't think the > > > support should become a part of a stable release of Dillo until Dillo > > > can render ACID2 perfectly. A site that uses CSS is perfectly usable, > > > albeit a bit ugly, in a browser that doesn't have CSS. > > > > We think Dillo needs CSS, > > so don't panic dillo-dev subscribers! :-) > > > > As a matter of fact, the widget style structures inside Dillo > > are shaped for CSS, and we presented a CSS parser prototype at > > FOSDEM 2005. Merging the CSS parser into the current tree would > > start CSS support. > > > > As for your concerns, disabling this is a piece of cake. > > > > > > > Anyway, these are just my 2 millicents. I understand that it takes > > > either real code or real money to make these changes real, and since > > > I'm currently offering neither, feel free to cheerfully ignore my thoughts > > > or to flame me to a crisp. :) > > > > Real money is a problem I haven't figured how to solve yet. > > > > For instance, there're plenty of embedded-focused companies > > that are interested, or already working with Dillo. They seem > > to prefer to wait for us to develop, with a view to lower costs, > > rather than to contribute (patches or money) or fund some > > development. These are the cheap companies. > > > > Other companies have interest and money to fund and foster > > Dillo development. The problem here is that managers prefer to > > make a choice for the "tried and true" and not to risk their jobs > > in the company in case of failure. > > > > I don't know yet how to solve the second problem. Any help is > > welcomed. > > I don't see this dollars-problem being solved. One of the issues is that dillo > tries to be too strict in some regard. For instance, the https is disabled by > default and has to be enabled in the source code. Most users perhaps take a > binary from some RPM or somewhere, so it stays default most of the time. It > would really be nice if this was enabled/disabled by means of a "switch" and > one did not have to recompile the whole source code. I must say that this does > not solve the dollars question, but this is an issue worth considering. I whish it was that easy! Enabling https is a piece of cake, but some sites would lock dillo (the https dpi doesn't support multiple requests for the same site yet), and it's _not_ secure because it's not validating the certificates. Go try to explain that to a user, and sign a dillo version with https enabled. We can't because we're commited to security. We can let the user choose later to loose all protection, but this is his decision. (same as with the linux kernel). > Have you considered moving dillo to a community project model? It _is_ like that. > I know that > there are core developers and they could vet things submitted, but it would be > better if there were more contributor developers who submitted their > improvements. Something like, for instance, the R project in statistical > computing. Or for that matter, octave or xemacs and the like. Somehow, > somewhere earlier on, I got the impression that contributions are not really > encouraged: if it does not meet the core team's objectives, it is not cared > for. This is the situation for every single OSS project. Try to submit a patch against Linus' design decisions to LKML! > Maybe what I am suggesting is already done and maybe this is a false > impression on my part, and I am sorry if that is so. It was sad for me to re-read some posts by one guy that came with lots of radical ideas (not code), as rewriting the IO, eliminating the dillo plugin system, eliminating the CCC control chain "nightmare". (this is writing a different browser) He whined a lot and was very rude sometimes. Finally he decided to start a fork (IIRC), that in his view, would be much better than official Dillo. The fork never happened. Where's that code? Unfortunately what he said, more or less convinced some people in dillo-dev. From above it made sense. OTOH, he never realized that the CCC structure wasn't about just passing data, but about parallelism! That's why IMHO experienced developers tend to consider what the core team of any project thinks. We all know the core team may make mistakes, but they talk from experience and have deep knowledge of the systems they develop. It's also well known that when a core developer leaves, it's a _BIG_ loss. You can certainly find great developers elsewhere, buy no one will have the specific knowledge and experience of the one that leaves. It takes time to get there. Note: Oh, there were more brags (someone here remembers the one that bashed me and promised a much better and complete Dillo for windows in six months?) Years have passed since... Note2: making a patch and maintaining it are different things. Note3: making a patch that works, and one that fits with the design are also different things. The second one has less side effects and is easier to maintain. > I only know that I want dillo to succeed and replace firefox, the so-called > lightweight browser. I wish Dillo to succeed. We need manpower/funds. Can anyone here help with that? -- Cheers Jorge.-

18 years, 2 months

Dillo-dev search results for query "plugin"