Search results for "plugin" - Dillo-dev

dillo-2.1.tar.bz2

by jcid＠dillo.org

On Thu, Jun 18, 2009 at 09:01:39PM +0200, Devid Antonio Filoni wrote: > 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) Good! After reading it and the suggested URLs, especially [1], it looks like our current tarball (rc2) is enough. No new tarball is needed! I consider this point solved, so let's move to the second one... [1] http://www.openssl.org/support/faq.html#LEGAL2 -- Cheers Jorge.-

June 18, 2009

Future of dillo2

by jcid＠dillo.org

On Sun, May 04, 2008 at 08:30:32PM +0200, Sebastian Geerken wrote: > Hi, Hi Sebastian! > just if you were courious: I'm still living and will continue working > on dillo. That's very good news. New developers are helping to push the project forward, and your presence is a very important asset for the team. > > On Sun, Apr 20, Jorge Arellano Cid wrote: > > [...] > > We could: > > > > * Attract new developers with a dillo2 release, > > leveraging the excellent documentation that we have. > > We have: > > - extensive documentations on the critical parts of dillo, expecially > on Dw, > - a prototype for CSS, and > - some more documents and prototypes on future ideas, including > scripting and graphical plugins. > > These should be copied on the web sever, and there should be a > prominent note on the web site linking to a new delevolers' section. > (Since attracting developers has high priority, this is what a visitor > should notice first.) Yes, I was planning on stating the quest for more developers in the splash page of the next release. BTW, it'd be great to also convert dillo2's plain text docs to doxygen format someday. > For those not listening to dillo-dev, it is important to know that > dillo is still an active project. I think we can sort the house and then make a release so the world knows. That's why having TABS and at least a CSS prototype matters. I don't want reviews to end with the typical line: "but no TABS and no CSS". ;-) If we have TABS (a thing I can spare some time to implement) and a CSS protoype published somewhere, the message will be more like: "it comes with: ..., antialiased fonsts, low-dependencies, UTF-8, TABS, and they already started with CSS." That sounds much better! > > * Planning for CSS, floating objects and TABS. > > (this are important features to a nice browsing experience) > > Just FYI: I've started a bit on floats. Jorge, I once told you that it > would take a week; actually it is a bit more complicated, nevertheless > it is not a big job like CSS. Speaking about floats, I was trying to make NBSP (non breaking spaces) work for pages like: http://fltk.org/newsgroups.php?gfltk.development+T (with a narrow window, the parenthesis are spared). but found that NBSP-handling wasn't coded in textblock yet: /* NOTE: Most code relies on that all values of nowrap are * equal for all words within one line. */ I planned to give it a try, but didn't know what was the model for handling it (a flag in the previous word, a flag in the previous and next word, an empty word, etc). Now that you're working in the textblock, can you give it a review? The attached patch is what the parser (html.cc) could look like to handle this. It uses WHITE_SPACE_NOWRAP in style, but I didn't know whether to use: addText(strdup(""), S_TOP(html)->style); or DW2TB(html->dw)->addSpace(S_TOP(html)->style); for NBSP whitespace. It should be simple to test with it. > > * Coordinate with FLTK2, DSL (Damn small linux) and other > > lightweight distros, Debian installer team, MINIX3, etc. > > Perhaps we can find there other "lightweight zealots". :-) Yes, and maybe someday people will start liking/using this lightweight browser. AMEN -- Cheers Jorge.-

May 11, 2008

Various minor patches

by Christian.Kellermann＠nefkom.net

* Jorge Arellano Cid <jcid(a)dillo.org> [080130 15:36]: > 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? > In a way yes. because my solution was to add -liconv to my LDFLAGS. Thanks for looking at this -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

Jan. 30, 2008

dillo 2.1

by sandshrew＠gmail.com

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 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. 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). 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). 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. 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? 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. 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. 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? 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... PS: how to install dillo 2.1 claws-mail plugin? -- Brain: an apparatus with which we think we think. - A. Bierce

June 22, 2009

Re: Dillo not rendering HTML with comments before <!DOCTYPE>

by Rodrigo Arias

Hi, On Thu, Apr 25, 2024 at 09:23:38AM +1000, Kevin Koster wrote: >Thanks for the explanation, this also makes clearer an issue I had with >XHTML image indexes generated by ImageMagick Montage which were getting >(by an unusual sequence of events) the incorrect HTTP Content-Type type >of "text/xml" (and they don't contain a meta tag). They'd load properly >via file:// but show as text over http://. Now I know to ideally force >the HTTP Content-Type to "application/xhtml+xml" instead of "text/html" >which I used to fix the problem originally. For Dillo, "application/xhtml+xml" and "text/html" are handled by the same HTML parser, which later identifies which version of HTML/XHTML is the document, based on the doctype. The problem is failing to set the content type to any of those two, like when using "text/xml". AFIK, the proper content type for XHTML is "application/xhtml+xml", which should be set on the HTTP Content-Type header. >> Regarding the type guessing bug, I think I can improve it by assuming >> that if we find the "<!doctype html" string in the first 1024 bytes or >> so, it is an HTML-like type, but it incurrs in more overhead. > >But if it aborts that search upon encountering the first thing that >isn't "spaces, newlines, tabs, and comments", most text files will be >detected within the first few bytes. > >I'm not sure how that approach would work with ImageMagick image index >XHTML pages which start like this though: > <?xml version="1.0" encoding="US-ASCII"?> > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> > >Example: >http://www.ombertech.com/cnk/dillo/STS-133_Pictures/photo_index.html > >I don't really understand how XHTML is supposed to work, and I don't >have time to learn, so perhaps I'm ignoring a distinction between >differet flavours of XHTML that can begin in different ways? Anyway I >like how ImageMagick image map pages are viewable in Dillo at the >moment. We can improve the content detection to handle both HTML and XML-style comments, but I prefer to defer it after the 3.1.0 release. Websites shouldn't rely on the browser to guess the content type, it should be stated in the HTTP header or the meta tag. So I don't consider this a priority that should block the release for longer. If you want to work on it, feel free to do so :-) >> So I think for now we can rely on the correction of "text/xhtml" to >> "application/xhtml+xml", which seems to work fine. I don't like adding >> quirks, but I will keep this one as it was already there. Here is the >> PR: >> >> https://github.com/dillo-browser/dillo/pull/140 > >I've built Dillo from that branch and pages on www.lemis.com now render >correctly, thanks! If I save the homepage as lemis.xhtml it still shows >as plain text when loaded with file://, though it is rendered if the >comments before <!DOCTYPE> are removed or if the original file is saved >as lemis.html. Not much of an issue, but it could cause confusion for >someone. I pushed another patch that should fix this issue. It is caused primarily by the ".xhtml" extension not being recognized by the file plugin, which then tries to detect the doctype and fails in the same way, falling back to text/plain. Best, Rodrigo.

April 25, 2024

Various minor patches

by jcid＠dillo.org

On Wed, Jan 30, 2008 at 04:37:09PM +0100, Johannes Hofmann wrote: > 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. OK, I modified configure.in in CVS. This approach may work. Beware I don't have how to test this patch, so you will probably have to try and tweak. -- Cheers Jorge.-

Jan. 30, 2008

[PATCH]: Fixing https step 1: Have a basic dpi dialog window working again

by jcid＠dillo.org

Hi Christian, Sorry for the late answer, but I've had little spare time, and several topics to answer. Probably you have already read: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2007-September/003211.ht… an got some info from there. On Sat, Mar 15, 2008 at 02:02:07PM +0100, Christian Kellermann wrote: > * Christian Kellermann <Christian.Kellermann(a)nefkom.net> [080315 09:49]: > > Dear list, > > > > In order to fix the https plugin I have stumbled upon the fact, > > that the former dialog code seems to be removed from cvs. To see > > what's goign on further down the code I have added a basic Yes/No > > popup using the existing a_Dialog_choice3 function. For this the > > numbering of the buttons have changed also in https. Dialogs with > > more than two alternatives will have the additional choices dropped > > silently. This is good for now but I really like to have it done > > right. Which function should get used instead of a_Dialog_choice3? > > > > Also what's the real purpose of http_request? At the moment I cheat > > and set it to url in case it is empty. Which value is to be expected > > when calling the document root in a URL? "/"? "/index.html"? or am > > I getting this all wrong? > > > > Whith this patch I can bypass the "certificate could not get verified" > > case but not much further. Also cancelling the dialog seems to leave > > some data behind, another call of https URLs won't do anything. But > > this is a bit better than it has been before... > > > > I am not sure whether I should stop beating this dead horse or > > continue. What's your advice? > > > > Ignore the http_request part I figured it out. > > Ok, I have changed the proto comparison from "https" -> "proto.https" > and I am able to view https sites again. This module still needs a > lot of cleanup. As a next step I want to implement simple certificate > caching so accepted certificates won't get prompted again. This > will be memory only at first, making the certificate valid (or > invalid) as long as the dpid lives. > > The updated patch is attached below. A long time ago, browsing was mainly fetching pages and images. It made a lot of sense to use an external tool (as wget) to grab https pages. Implementing this idea with dpi was also simple. Now, it may be not the case. You have to keep track of certificates, sessions, sometimes keep an open connection, etc. Years ago SSL wasn't widespread, today is an everyday need, so it may make sense to consider having it inside dillo. It can take some design time at the beginning but will be easier to maintain and extend than to have it living in an external dpi. Developers is what we need, so if you want to work on https, you're more than welcome. Lack of manpower is our biggest problem! "place" implemented gzip decoding in dillo2, he may help you with ideas on how to add an extra layer/decoding-stage for SSL. (With regard to your specific questions about https, you'll have to wait some time until I can look at it again in depth. IIRC there was a five option dialog requested through dpip that sent the answer back on what to do. It was removed from the code while porting, delayed for future implementation). Again, my suggestion is to consider an internal implementation. -- Cheers Jorge.-

March 15, 2008

Re: Towards 3.2.0

by Rodrigo Arias

Hi all, On Thu, Oct 24, 2024 at 10:45:49PM +0200, Xavier Del Campo Romero wrote: >I would have preferred to resume my work on multipart/form-data, but I >have been too busy with other projects and IRL. The required changes >were way too complex to shoehorn into this release, so I assume they >will have to wait for the next one :) No worries :-) On Thu, Oct 24, 2024 at 11:09:46PM +0200, a1ex(a)dismail.de wrote: >I don't know about the complexity, but it worked fine here! Yeah, but I prefer to move to a new file when the format is more stable, so you can keep your rules intact. Now I'm experimenting. >Sounds good, but in that case, maybe we should provide an example >handler script in the docs, since that could be a barrier for some >users. > >I'm still using a variant of this[1] patch, but with multiple >entries, which still seems to be the easiest way of allowing external >actions. > >[1] https://alex.envs.net/patches/00-ext-link-handler.patch Yeah, maybe I could also make it like this so you can specify a program directly: actions="Open with external tool:/path/to/the/handler.sh default $URL" actions="Open as audio:/path/to/the/handler.sh audio \"$URL\"" actions="Open with MPV:mpv $URL" actions="Open with Firefox:firefox $URL" But this won't work well when the URL has characters that are interpreted by the shell. It "should" be like: actions="Open with external tool:/path/to/the/handler.sh default \"$URL\"" actions="Open as audio:/path/to/the/handler.sh audio \"$URL\"" actions="Open with MPV:mpv \"$URL\"" actions="Open with Firefox:firefox \"$URL\"" But is quite ugly. And I'll have to check if you can still inject some command in the URL, which would be dangerous. On Fri, Oct 25, 2024 at 09:12:21AM +1000, Kevin Koster wrote: >One action which would probably complicate things, but likely be >among the most used for me, would actually be something like "View >as text" (in Dillo). Effectively the inverse of "Save link as...". > >Websites with annoying MIME settings can give links that one wants >to view as text (eg. source code files), but the server assigns a >MIME value to them that makes Dillo download them to file. This >would force Dillo to display the link as a Text file regardless. Yes, I have also experienced this annoyance. It may be nice yes, not sure how complex to implement. >Also the view source plugin/rendering can choke a bit >performance-wise (on the modestly-powered computers I use, at >least) with the multi-MB webpages that are common today. Just >viewing as text might be a quicker option, eg. when looking to >manually extract a URL meant to load via Javascript. I think for very long text files this may continue to choke Dillo. Maybe you could add a external tool that pipes it to more(1) or less(1). >> Then, your handler will be invoked using the label as: >> >> /bin/the-handler <URL> <action-label> >> >> And you do whatever you find convenient in your handler, so you have >> more context to decide the proper action based on the label. I think >> this would cover most of the use cases of opening URLs with other >> programs without being too convoluted. > >What would the default behaviour be? Will Dillo install a default >handler with its own separate configuration file for setting up the >default 'action' behaviours? Or does the feature only appear after >each user has created their own handler? By default, no extra options. As you add the actions they appear on the menu. We may want to distribute an example handler for users to have a reference. Best, Rodrigo.

Oct. 25, 2024

Feature Request

by jcid＠dillo.org

On Sun, Nov 09, 2008 at 01:12:01PM +0100, Michal Nowak wrote: > 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 :) ). Thanks a lot for the explanation! Although it may be difficult to get a FLTK2 package in the distro because FLTK2 doesn't have a stable release yet. I mean, if policies mandate not to include alpha or beta libraries, we're out... It'd be good to know this (for Fedora, Ubuntu and Debian at least). That way we can ask the FLTK team about their schedule plans. -- Cheers Jorge.-

Nov. 9, 2008

[PATCH v2] Unveil patch

by a1ex＠dismail.de

Hi, Here is version 2 of my unveil patch. Many thanks to Rodrigo for his kind assistance! 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) - 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 +} /* * -- 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();

Aug. 1, 2024

Dillo-dev search results for query "plugin"