Search results for "plugin" - Dillo-dev

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.-

16 years, 9 months

[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.-

16 years, 8 months

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.

3 weeks

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.-

16 years

[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();

3 months, 2 weeks

Re: https dpi

by Jorge Arellano Cid

On Sat, 25 Oct 2003, Madis Janson wrote: > I read the https.c included in dillo/dpi and seams, that it just > gets url and and dumps html. Yes, it's basically a dpi filter plugin. > What about content-type, cookies and POST > requests? Since https is http over ssl, it seems natural to use dillo's > http protocol implementation for these things (like i did with my https > proxy for dillo), but is it possible with dpi? > > Also, there seems to be one process for one connection, which makes hard > to implement SSL session cache. Unfortunatelly I don't have definitive answers for these questions. There's more than one way to do it and the choice somewhat depends on what the underlying purpose of the bigger picture is. For instance: distributed design vs monolithic, quick implementation vs a more flexible one, low library dependencies vs linking dillo to a bigger set. Personally, I think that patching dillo with an integrated quick implementation of https (like Indan's) while we develop a more flexible dpi that provides at least the same, can be a good approach. I'll try to briefly comment your concerns: > Also, there seems to be one process for one connection, which makes hard > to implement SSL session cache. Yes, that happens with dpi filters. The idea in this case is to have an http dpi that's able to handle several connections at the same time (like the downloads dpi). That is: a dpi server instead of a dpi filter. With that scheme session cache is easy to implement. (and BTW much easier for the developer because he can arrange things much more freely than when patching inside dillo). > content-type (as above). The https dpi would need to listen the HTTP stream and so has access to the content-type sent by the remote https server. > Cookies Cookies will end being a dpi! Currently dillo enables cookies for the first instance only (this is old problem of sharing a single resource among several clients). Fortunately dpi solves this, as with the current bookmarks dpi server that can be shared by multiple running instances of dillo. When this port is done, the one-instance-only restriction for cookies will be gone. > POST POST data can be passed to the https dpi using dpip. This information is inside the DilloUrl. > Since https is http over ssl, it seems natural to use dillo's > http protocol implementation for these things (like i did with my https > proxy for dillo), but is it possible with dpi? Yes I agree with that reusing dillo's http may come handy. Now, dillo does http 1.0 only so having it done inside a dpi can also bring http 1.1 (as with wget and current https.c). The other interesting point is that the SSL/TLS library spec states that appart from making a socket secure, the details of handling the possible errors should be solved by the client application depending on the protocol and what it is being used for. So having a generic SSL/TLS gateway may look interesting but it can get tricky to implement. For intance: handshake_failure(40), bad_certificate(42), unsupported_certificate(43), certificate_revoked(44), certificate_expired(45), certificate_unknown(46), illegal_parameter(47), unknown_ca(48), are to be handled in different ways regarding what the protected protocol using SSL/TLS is, the transport circumstances and the user's choice. (ah, and all the alerts can have a "level" of fatal or not). With a gateway, having only the option of closing the connection is not enough. Question dialogs can be implemented in the gateway process itself though (a GUI inside the dpi), and you also have to take care of differentiating the protocols. With dpi, the questions and actions can be communicated to dillo with dpip or be made part of the dpi server. It provides more flexibility. Making SSL a part of IO, comes with the burden of having to develop all of this error handling knowledge inside the IO layer (making dillo grow in size and complexity). Including questions, actions a protocol differentiation. HTH Jorge.-

21 years

Re: [Dillo-dev] [patch] Cleanup of IO.c

by Indan Zupancic

Hello, The patch was downloaded 14 times, and zero feedback... Great. I wanted to cleanup http.c in a similar way, but never mind. I feel sad and frustrated because of the lack of feedback from the Dillo developers. I tried to improve Dillo, to add some extra features. Dillo is a nice browser and I thought that spending my time on it would be appreciated, but it seems I was wrong. I give up, I'm not going to waste my time on improving Dillo while all efforts are just ignored or told to be useless because of the "that mess is fine as it is now" attitude. If the neutral and obviously (somehow I start doubting that now) improving IO cleanup patch is ignored, then what chance do I have with cleaning up the CCC horror... To give you an idea how bad it is: There are at least 24 ways of calling a ccc function. That is a conservative estimation, because I only counted the possible parameter combinations (values, types), you still need to know which variant of the many you need to use with a certain module. Also I counted only the ccc functions of the IO, cache, file, http and dns module, I didn't count the dpi and capi modules (just didn't come that far). This mess means that modules can't communicate transparantly with eachother, because they need to know exactly which data to give, implicating that they need to know with which module they're talking. That makes the whole CCC construction worthless, because one of it goals, or so I guess, was to have a chain like communication where linked elements could do their's stuff and notify the next element without knowing anything specific about eachother. With the current situation the CCC structure only adds unnecessary complexity to the overall code, obfuscating it. If that's what you want, fine, but then say so, instead of saying that it's hard to replace. Yes, duh, you made a spaghetti mountain, of course it's hard to clear that up. I truly hope that the rest of Dillo is cleaner, and from what I saw of it, the GUI part doesn't look that bad. Next grief: DPI's. What was meant like a simple plugin system turned out to become the sauce over the spaghetti, to stay with the previous metaphor. It seems like the cache api code handles dpi's differently, at least there is plenty dpi specific code in the capi.c file, so it seems like it's in the wrong place. I mean, if it's not part of the cache api, then what is it doing in that file? capi.c has even it's own CCC function only for dpi's, so an extra module in a wrapper?? Worst is, making a dpi isn't as simple as making a CGI, as it should be. And of course the whole dpid construction makes no sense. not really anyway: you can find all the dpi's the same way as you find the dpid... Sure, dpid has some minor advantages, but everyhting has _some_ advantages. All the dpi code (not including bookmarks.c) is 14K big, just imagine what you could implement with so much code (native ftp support comes into mind). Not even talking about how much resources the dpi's use, because they have such an awkward interface and need to do things that Dillo already could do, duplicating code and features. I'm aware that certain people already wasted too much time on the current dpi code, so it has zero chance of being changed, I'm not so naive to think it would. I just give my oppinion on it. I had put my hope on the IO/CCC mess. Sigh, if only Dillo went the GTK2 way, then I could say goodbye without trouble, but now it seems like Dillo will use FLTK it's even more depressing. --- Oh well, enough rambling, if someone wants an updated version of the installer, then say so. I won't do much with the https patch, because as it is now it can't be improved much without cleaning up IO, CCC or/and http, or at least without merging the IOData structures, so more than synching with CVS and tiny changes won't happen. Good luck and take care, Indan

20 years, 11 months

[Dillo-dev]About porting Dillo to FLTK.

by Jorge Arellano Cid

Hi there, We've had long email threads (between our core developers and some FLTK core devs.) dicussing about how the port of dillo to FLTK could be done. We've explored different paths (in abstract) and posting all the threads to dillo-dev would add more to confussion than clarity because each one was explored as it were the chosen one. For simplicity and to keep all the developers in dillo-dev well informed (and certainly inviting the interested ones to take part in the process), I prepared this recapitulation about the more relevant issues. It's a long document with a lot of information. Cheers Jorge.- PS: Previous background on this topic can be found at dillo-dev's archives: http://www.dillo.org/search-dillo-dev.html. For instance: search for "FLTK" by "jcid" sorted by "Relevance". This will not only bring my posts but also the ones from Michael Sweet that I forwarded to dillo-dev. ---------------------------------------------------------------- > [Sebastian] > Furthermore, I have plans to extract at least the core of Dw, and make > an own library of it. The package is already finished, I'm just > polishing another package, which uses Dw. (This is "rtfl", the program > for which the macros in "debug.h" are for.) > > Perhaps it is at least possible, to make Dw itself independent of the > widget toolkit (Gtk/FLTK), ... > [Sebastian] > Dw can be rather simply extracted, and probably it is the best to > start with a testbed. I've attached a test program (I searched > for it somewhere in the mailing list, therefore the french > identifiers :-), you have to build dillo first, to run > it. Perhaps it is simpler to include it into the dillo tarball > itself. > [Sebastian] > Another aspect is portability: When using other toolkits than Gtk, > GtkDwViewport may be replaced. > > For archieving this, the following new design will be sufficient: > > +--------------------+ 1 * +-------------------+ > | DwRenderingContext |---------->| DwRenderingWindow | > +--------------------+ +-------------------+ > 1 ^ | 1 > | | > viewport | | child (the top-level DwWidget) > | | > * | V 0..1 > +----------+ 0..1 > | DwWidget |--. parent > +----------+ | > * | | > `-------' > (children) > [Sebastian] > As for the actual porting, I'm currently working on two topics, which > should make porting simpler, since they reduce the Gtk/Gdk specific > stuff into single modules: > > 1. I'm currently changing the design of image handling as I > described in doc/DwImage.txt in the tarball, section "Future > Extensions". As I've seen now, this is also necessary for > topic 2. > > 2. After this, I'll implement the ideas I wrote before (abstraction > of the actual drawing), in the best case, it should be a simple > matter to write a replacement for the viewport, plus some > changes in dw_style.[ch]. (Dependance of the GtkObject model not > yet considered.) > [Matt] > Abstraction is definitely the best thing to do here. I am pretty sure > we can cross reference between the a-layer and whatever FLTK has to > offer. Spontaneously I see the need for buttons and input fields, line, > box, text and image drawing, image scaling and the dreaded 16-bit vs. > 32-bit coordinates. > > [Jorge] > > Once again, I'd wish to know how a seasoned FLTK developer > > foresees the merging path (from their point of view). With regard > > to Dw, you're the authoritative source! ;) > > [Matt] > At this point - if you guys are still interested - I guess I should > take an extensive tour through the Dw code and see, which parts map > directly onto FLTK, and which parts would need modifications or even > rewriting. ------------------ 32 bit coordinates ------------------ > [Jorge] > > Hi Michael, > > We have been extensively discussing how to port Dillo to FLTK > with Mattias M. and Sebastian. One of the key points is how to > provide for a widget that overcomes the problem of 16 bit > coordinates (GtkLayout currently solves this). > > In a formar email you told me that FLTK2.0 had 32 bit > coordinates, but suggested me to use 1.2.x release that would > also come with 32 bit coordinates. > > Matt was somewhat surprised by this... > [Matt] > I talked to Mike. He changed the coordinates to 32 bit in his local > version already. So in short, fltk 1.2 will have 32 bit coordinates. > Versions 1.1 and 1.0 will not be changed anymore, however 1.2 should > become the standard as soon as we release it, since it is source code > compatible to 1.1. > [Matt] > I went through the current CVS code yesterday, and it seems like we had > a mixup between 1.1 and 1.2. Not a biggie, but I re-merged with a > previous CVS version. The current CVS is now fully 32 bit. tested and > working. > [Jorge] > So we have to use 1.2.x CVS, but which docs are recommended for it? > > [Matt] > The 1.2 cvs contains the full 1.1 documentation and is beeing corrected > to reflect 1.2 changes and additions. I am in the process of adding > doxygen style comments to all fltk classes and methods (95% done), so > simply running the command 'doxygen' will create a second, more > 'techie' documentation in docs/html/index.html. ------- Signals ------- > [Jorge] > Appart from that, the 32 bit issue and the signals (perhaps > solved with Fl_Signal). > [Sebastian] > As for signals: This should be rather simple to re-implement. I just > hacked a prototype of very simple framework for signals, which can be > downloaded at <http://www.dillo.org/misc_files/signals-0.0.1.tar.gz>. > It lacks events returning boolean (which we need), and some more > features (which we do not need), but shows that signals aren't really > a problem. ------- Plugins ------- >> OK, there's no plugin API in FLTK. > > Do you mean what GtkPlug/GtkSocket does? There protocol has been (or > is currently?) standardized at freedesktop.org, if an implemtation is > possible (and why should it not?), this is certainly a candidate for > merging into FLTK. > > > [Matt] > > Yeah, I talked to Bill, and we decided that we will create an Fl > > utility library that offers cross platform access to files and sockets, > > provides threads and locks, and also some standardised plugin > > interface. We will be smarter this time and write it in FLTK2 with an > > FLTK1 compatibility layer... . ------------------------------ About how to approach the port ------------------------------ > > >> [Sebastian] > > >> I'm more > > >> than ever convinced that this was the right decision, especially since > > >> then, incremental resizing has been added, what would have been very > > >> difficult in Gtk. Furthermore, this shows the benefit of having an own > > >> widget set, which can be infinitively changed to our needs. > > > > > > [Jorge] > > > In that case, it seems that the path to go is to port Dw to > > > FLTK, and maybe get rid of some widgets (as DwImage) when they > > > can be replaced by an FLTK embedded one. > > > > > > In anycase, Matt is better qualified than me to comment on > > > this. > > > > [Matt] > > All images in FLTK can be resized at any point. > > > > I understand that you prefer to have your own widget set, and I surely > > don't want to convince you different (because we wanted the same thing > > and that's why we wrote FLTK in the first place). However, should you > > decide to go with FLTK, then all the source code is available to you, > > so you can do the same modifications that you would do in your code. If > > those changes (or additions) are useful for the FLTK toolkit, I'll be > > happy to do them for you (ah, that's where the benefit is for you). > > [Jorge] > This is a very interesting collaboration scenery. I believe we > could start as Sebastian suggests, and merge those features you > see could benefit FLTK. (as for images, and maybe the "complex > resize" widget using size hints to name two). > > [Sebastian] > To make this clear again: What we currently have is an own widget > toolkit within Gtk, i.e. Dw widgets, from which the page is build, are > not Gtk widgets, but instead, for Gtk, a tree of Dw widgets is a just > _one_ huge Gtk widget. (With the exception of Gtk widgets embedded > into Dw.) > > I'd like to stick with the same design (with FLTK instead of Gtk), > also on the long run. For this, there are rather few requirements for > the GUI toolkit, mainly only the 32 bit issue. Integrating both > toolkits, in the way that Dw widgets will become FLTK widgets, will > however make things generally more complicated, we will have a hybrid > which has to deal with both rendering HTML (and other) documents on > one hand and GUIs on the other hand. The duplicate code in the current > design (like event handling), is rather minimal, but integrating would > mean one of the following possibilities: > > 1. Making FLTK as abstract as possible: This would make Dw as > complex as it is now, but instead add an unneccessary > dependency, where the development of dillo will often have to > deal with the limits which any GUI toolkit has. > > 2. Incorperating stuff from Dw into FLTK: This would IMO a very bad > decision of the FLTK team. Dw was designed for rendering > documents etc., and its layout mechanism has several ad hoc > features (size hints, width extremes, incremental resizing), > which should not be in a toolkit for GUIs. Actually, the design > is quite ugly at some points. > > Furthermore, the design often changes, some historical examples: > > - Dw widgets had baselines from the beginning, but they were > fist used much later. (I was indeed hesitating at the > beginning.) > - Tables made it neccessary to introduce width extremes. > (Very ad hoc: Why not height extremes? Because texts are -- > in most languages -- written horizontally, and then > vertically split into lines.) > > - Also with tables (although noticed some time later), it > became clear that the current resizing mechanism was > inefficient and had to be extended. (Notice that Dw > requires that several resizes per second must be handled, > much more what is neededfor GUIs.) > > These were certainly not the last changes, e.g. for CSS, we will > have some other requirements, which are yet not specified. Also, > this shows that most requirements are not obvious before they > are first needed. > > If FLTK wants to adopt Dw features, it will be neccecary to > change FLTK often, and since it is not part of dillo, the > development of dillo will be slowed down, until new FLTK > releases. > > 3. We move stuff from Dw into our own version of FLTK: This would > probably the worst possible desicion, we would fork FLTK and > have to maintain it, also the parts which deal with pure GUI > aspects. > > Dw will work fine with FLTK in the way analogue to the current way, > and the problems with this split are really not as dramatic as Jorge > describes it. The FLTK developers should not make the mistake to take > just one (probably rather prominent) project and change their work so > that it just fits within it. And dillo should keep it dependencies as > low as neccessary. ------------ Porting Plan ------------ > [Sebastian] > I'd suggest the following: > > 1. Finish the planned abstractions. The general idea is to have the > Gtk/FLTK specific code in small modules, which may be rewritten in > a simple way. > > 2. Extract Dw from dillo, and write a test program for several aspects > of Dw. > > 3. Rewrite those modules mentioned in 1, and adjust the test > program. This step will still make Gtk necessary, because of the > Gtk object model, but UI control, event handling etc. will be done > by FLTK. > > AFAIS, the affected modules are the new GtkDwViewport, ImgBuf, and > DwStyle. The abstraction in step 1 may taken a bit more extreme, by > splitting up the latter two into toolkit-dependant and -independant > parts, we'll see. The dillo widgets themselves should not be > modified, if this is really necessary, this is a fault of the said > abstraction. > > After this, we will have a version of Dw, which works with FLTK. The > next step is to see how the parts we take from Gtk (object model with > signals) and GLib (several utilities) can be replaced, so that we can > get rid of the Gtk dependencies. Another topic it the port of the > actual UI; AFAIS, there should be no major problems. Appendix -------- -------------- About printing -------------- > > [Jorge] > > Is printing lost because the widget tree is not native FLTK, or > > is it assured by using FLTK's drawing primitives? > > [Sebastian] > Some remarks on this. First, we still have a "native" FLTK widget, > just that we have one large, complex FLTK widget (which complexity is > manages by Dw), instead of multiple smaller and simpler FLTK > widgets. The reimplementation of the viewport should use FLTK methods > for drawing, so there is no problem at all. > > Second, the abstraction described above should make this possible with > any toolkit, it should be simple to write a printing "viewport". > > Third, printing will anyway become more complex, for several > reasons. For one reason, I quote myself from a mail I sent Jorge, this > may also be interesting for Matt: > > <q> > I'm very sceptical about the idea to use the current rendering for > printing, for two reasons: First, the current rendering is designed > for dealing with viewports, not for pages. Pages are in some ways > different, e.g. you must break pages (instead of having one page of > unlimited height), and you cannot widen the page, you must break a > word, when it does not fit into the line, while it is more > reasonable to let the user scroll to the right, when this is > possible. (Furthermore, from a typographic point of view, dillo's > typesetting quality is sufficient for screen rendering, but rather > poor for printing, especially page breaking cannot be done as > simply as line breaking.) > > Second, most of the complexity has its roots in the requirement of > incremental rendering, which is neither needed, nor desired for > printing. Actually, it makes use for printing more complicated and > inefficient. (Although one rendering iteration has a nearly > constant time, it is as a whole still slower than a simple > non-iterative run.) > > [...] > </q> > > Furthermore, even if we would use Dw for printing (with ugly page > breaks etc.), we would need another widget tree, with the same content > of the current one, but with a state, which is different, e.g. the > top-level available width, which is the window width for the screen, > but the standard paper width for the printer.

20 years, 6 months

Re: [Dillo-dev]More https goodness

by Jorge Arellano Cid

Hi Garret, On Wed, Jul 21, 2004 at 10:47:21AM -0400, Garrett Kajmowicz wrote: > On July 20, 2004 09:09 pm, Jorge Arellano Cid wrote: > > Hi Garret, > > > > OK, I reviewed it an made some changes (now on CVS). > > > > I pondered a long time whether to make a generic function for > > parsing dpip dialog answers. Something like: > > > > a_Dpiutil_dialog_parse_answer(...) > > I created a specific function because in this case a numerical response can be > expected, and thus returning a char answer requires the programmer to do more > work for this specific value. Modularizing functionality is usually a good > idea. Yes it is! This is sort of a tradeoff... For instance html.c does all its parsing with a function very much like Get_attr_value(). One alternative that I've been thinking of for a long time, is to just parse HTML tags once and return something like a: struct pair { char *attr_name; char *attr_value; }; struct pair *parsed_tag; Or the same pairs in a simple list: char **parsed_tag; with NULL marking the end. The advantage is that tag-parsing is done once, but now the caller has to go through the list to find out what attr_names are present. In the case of the dpip dialogs the current method looked simpler, at least by now... > > > > To me it seems that according to the simplicity principle of > > API design, sticking with Get_attr_value() instead of one custom > > parsing function per each dpip command is better... > > > > The same logic applies to the a_Dpip_build_command() I was > > thinking of. The interface for sending data may survive though. > > > > Anyway, the most important point of this patch is that after > > applying the patch, it seems not to trust even paypal! > > > > For instance: > > > > https://www.paypal.com/en_US/i/icon/secure_lock_2.gif > > I have checked this out. I have written a fair bit more code (now I have to > merge changes *ugh*). The issue is probably a lack of issuer certificates. > Currently the https module checks /etc/ssl/certs. > > I'm trying to think of a way to put the directory in the configure script, but > that will have to wait a little while. Don't worry, that can be done later. Let's test it first. > Right now I'm working on allowing > self-signed certificates to be accepted long-term. OpenSSL has some weird > ideas on how to do things. BTW, have you given a look to GnuTLS? (It has an OpenSSL compatibility layer and seems better documented). > > > > gives me the warning dialog. Is this OK? > > Warnings are OK. Yes, I meant to ask: Is really PayPal sending this image with a certificate that can't be trusted? > I'm adding more and more code in to handle all possible > error conditions. Previously there was no warning if there was a problem - > just a likely insecure connection. Now the system is warning on everything, > and hopefully will be able to deal with a large number of these problems in > code giving *useful* error messages. One thing at a time, though. > > Side question, do you have a regular Dillo mailing list > view-parse-evaluate-and-commit schedule? No. I try to work based on priorities. But sometimes something of higher priority steps in and things get rescheduled... > I know you prefer smaller patches > to larger patches, but it gets a little annoying for me when I submit > something and I don't know when it will be reviewed and commited. The time > doesn't bother me, but if I know your schedule I can schedule my work > appropriately. My schedule is very hard to predict. Different things come my way everyday, and I have to manage lots of things in different areas. Don't get scared though. This patch took some time to commit because I had to think of things that affect the other plugins. OTOH having a patch in the CVS doesn't give it a lot of exposure. The number of people using Dillo from CVS and testing is smaller than one expects. We usually tend to work on our local trees until something is stable enough for broader testing before making the commit. Things should go faster in the future... Cheers Jorge.-

20 years, 3 months

Various minor patches

by jcid＠dillo.org

On Wed, Jan 30, 2008 at 03:40:52PM +0100, Christian Kellermann wrote: > * 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. Did the new test in configure.in work? I assume not because of the silence. You wrote: > In a way yes. because my solution was to add -liconv to my LDFLAGS. and > 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. I assume you set LDFLAGS=-L/usr/local/lib... but this is expected to be done by the test at configure.in:96. The test can fail though! Would you mind posting the output of: cpp -v in your system. -- Cheers Jorge.-

16 years, 9 months

Dillo-dev search results for query "plugin"