- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev]https (eg for posting to ps2 bulletin boards)

by Madis Janson

On Tue, 1 Jun 2004, Jorge Arellano Cid wrote: > The current prototype for SSL (using dpi) provides for an easy > way of implementing connection caching, and for asking the user > (using dillo's API) whether to continue on unverified > connections, the SSL part of this verification is not yet done > though. > > As Madis put it: > > > Most important thing missing from the ssl specific code is certificate > > verification - it MUST be done in order to have any actual security. > > In its current form it just gives a way to access SSL sites, but not > > secure access. > > I know people look forward to the day when they can complete > their online shopping with dillo, but we must be very careful to > provide real security. This is key. I hope to look at it (probably in july). > Unfortunately I'm not an encryption expert, and we need some > help from a savvy guy (the chances of a SSL freshman to make > mistakes is very high). Yes, it is a hard thing. There were for example a same SSL certification chain handling bug in IE and Konqueror. It would help, when someone would write a library-like code for verifing peers certificate with simple interface. I'd look the existing implementations in Konqueror SSL plugin and Mozilla for reference. For example something similar to this: /** * Check the peer's certificate. * * \param connection current SSL connection * \param result the verifications result * 0 - ok * 1 - we don't know wtf it is, ask confirmation * and tell user, that good answer is NO. * 2 - error, couldn't do the verification * .... * \return message for user */ char* chain_verify(SSL *connection, int *result); /** * User said, that he likes that one... * * \param cert certificate to remember * \return 0 - error (message in openssl error stack), 1 - OK */ int remember_certificate(X509 *cert); > I'd love to have a TLS based dpi for https (TLS lib is GPLed > and is a requisite to NPTL, so it'll become as ubiquitous as SSL > lib). The current prototype is SSLlib based, but is enough to > start polishing and extending the code. > > Some time ago Madis wrote an SSL gateway for Dillo. After some > work, I decided to integrate it through the dpi framework (to > empower it with dpip and also to avoid some quirks by using the > standard way to extend dillo). That is the current prototype. http://www.zone.ee/myzz/dillo/https_dpi/https_dpi.tar.gz But if someone knowledgeable of crypto, SSL and TLS library goes to write the TLS version of it, do it (and tell the list). I do not know the TLS library by myself.

June 2, 2004

Re: [Dillo-dev]https (eg for posting to ps2 bulletin boards)

by robert w hall

In article <Pine.LNX.4.58.0406012204150.740(a)infinity.cl>, Jorge Arellano Cid <jcid(a)dillo.org> writes > > >On Sun, 30 May 2004, robert w hall wrote: > >> Every time I read the playstation2-linux lists I realise how very useful >> dillo will be when it gets just a little further. > > Please elaborate a bit on this subject. Well it's a lovely browser for that sort of machine (300MHz MIPS R5900 processor, 32MB of RAM), and I usually recommend anyone who is asking on the official site (www.playstation2-linux.com) to go get a copy in preference to, or at least along with, the gargantuan firefox. But it's a bit hard to have to tell a newbie that he won't actually be able to use dillo to post back to the same site he's reading from (needs SSL to post). They usually just go off and use firefox and s*d the disc thrashing! It doesn't need to be a very secure implementation (though I note and respect your reasoning here) - there was a patch available all though the 0.6 and 0.7 series which I think usually got implemented in the pre- compiled dillo downloads at the ps2 site... With the recent dropping in price of the ps2-linux kit, there are quite a few new-starters, who are trying to see what they can use on the net, and so a slightly-extended dillo would (IMHO) be very timely. Bob -- robert w hall

June 2, 2004

Re: [Dillo-dev]https (eg for posting to ps2 bulletin boards)

by Jorge Arellano Cid

On Sun, 30 May 2004, robert w hall wrote: > Every time I read the playstation2-linux lists I realise how very useful > dillo will be when it gets just a little further. Please elaborate a bit on this subject. > How's the short/medium term future of https looking?(*) > If an official plugin is in the offing then that's probably what we > should all wait for. The short term looks very good, at this time we only need some TLS or SSLlib savvy guys, with some time willing to polish our current prototype. The main problem with the past prototypes and patches is that they don't handle connection caching (nor provided for an easy way to implement that), and the most important, they don't do certificate validation! The current prototype for SSL (using dpi) provides for an easy way of implementing connection caching, and for asking the user (using dillo's API) whether to continue on unverified connections, the SSL part of this verification is not yet done though. As Madis put it: > Most important thing missing from the ssl specific code is certificate > verification - it MUST be done in order to have any actual security. > In its current form it just gives a way to access SSL sites, but not > secure access. I know people look forward to the day when they can complete their online shopping with dillo, but we must be very careful to provide real security. This is key. Unfortunately I'm not an encryption expert, and we need some help from a savvy guy (the chances of a SSL freshman to make mistakes is very high). I'd love to have a TLS based dpi for https (TLS lib is GPLed and is a requisite to NPTL, so it'll become as ubiquitous as SSL lib). The current prototype is SSLlib based, but is enough to start polishing and extending the code. Some time ago Madis wrote an SSL gateway for Dillo. After some work, I decided to integrate it through the dpi framework (to empower it with dpip and also to avoid some quirks by using the standard way to extend dillo). That is the current prototype. Just in case an SSL/TLS savvy person is reading: the work with the dpi is quite simple, you don't need to know about Dillo's internal working, actually the https dpi is a C program that's independent of Dillo. The dpi just needs to make the secure connection to the remote server (and verify the cerificate), then forward the http stream to dillo, or ask whether to close or proceed when it can't verify. This is done with a simple dpid tag, all the SSL stuff happens inside the dpi. > Otherwise, is the patch from 0.7 resurrectable?? Sure, but not worth. At least the current prototype can POST. Cheers Jorge.-

June 2, 2004

Re: [Dillo-dev]Some remarks on the UI

by Jorge Arellano Cid

On Mon, 31 May 2004, Sebastian Geerken wrote: > Hi, > > several remarks on the UI, which should be fixed IMO. > > 1. Bug meter: The bug meter button reacts on the "pressed" event, to > show the window, but it should react on the "clicked" signal. > Popping up a window after a "pressed" signal is usually only done > for volatile windows (like menus, or overview windows, like in > GIMP, which often vanish again, after releasing the mouse button). > > Reacting on "pressed" is always a bit problematic, also because the > pointer grab initiated with this event can cause side-effects. > > Furthermore, it should not have a relief, compare to the "Hide > Controls" button. No problem. I even don't know why "clicked" should be used instead of "release" :-). I just copied the code from the menus. Note that the same code for the bug-meter button is used to handle the bug-meter menu entry in the "page menu". If a new implementation acts the same as the current one, from the user's point of view, it's perfect for me. > > 2. The menus behind the "Back" and "Forward" buttons: Consider the > following scenario: > > (i) The user presses button 3 on the "Back" button, and the menu > is shown. > > (ii) He keeps the button pressed, moves to one entry in the menu, > and releases the button. Nothing happens. > > Currently, the menu items only react on "button_press", which is > anyway wrong (see above). Furthermore, in this situation, the item > should already react on the "release" event, either as described > above, or in the way (i) click on menu, (ii) click on menu > entry. The current behaviour is that much confusing, that a user > may think that it does not work at all. (I did!) Yes. Sometime ago Ricardo Persichetti sent me a patch for this. It's just a couple of lines. Now on CVS for testing purposes, plus enhanced pixmaps for Back and Forward that hint their right click menus. > (The implementation would become a bit tricky, since button 2 will > pop up the page in a new window. Perhaps, I'd even suggest to skip > this feature, if a clean solution is not possible.) I use this feature all the time! Before switching to fluxbox, it was quite handy to spawn new dillo windows, and now, under fluxbox, it's perfect for making new TABS. > BTW, it is not very obvious, that there is a menu behind these two > buttons. Perhaps there should be, in the icon, a small arrow > directed downdwards, or so. Done! > > 3. Attached is the incomplete code of a new widget, which changes the > behaviour of GtkButton: > > (i) It reacts also on button 2 and 3, this would make multiple > functions for one button possible. Actually, this feature > should be reserved for very few situation (since it is simply > confusing), namely the "Clear URL" button, which may also be > used for visiting the URL in the selection buffer. > > (ii) It provides a function for attaching a menu in a better way, > than we have currently, for the "Back" and "Forward" menus, > and for the bug meter. > > Simply copy all files into one directory, call "make", and run > "testprg". Look, what happens with different mouse buttons. Interesting. I went through the code a bit. It's not obvious to me how to modify them to be able to provide the same functionality (new window on middle click on history), and not to screw the design at the same time. > Comments welcome. BTW, are you working on the layering API of Dw we need to go FLTK? I ask because we may have to look at it again when re-making the UI for FLTK. Best Jorge.-

June 1, 2004

Re: [Dillo-dev]dillo as a debian package ..?

by Mattias Östergren

On Tue, 1 Jun 2004 08:39:47 -0400 (CLT) Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > On Mon, 31 May 2004, Mattias Östergren wrote: > > > On Sun, 30 May 2004 11:38:55 -0400 (CLT) Jorge Arellano Cid > > <jcid(a)dillo.org> wrote: > > > > > > > > > > > On Tue, 25 May 2004, Willem van Engen wrote: > > > > > > > Hi all, > > > > > > > > ok, I made a new .deb for 0.8.1 and setup an apt repository on > > > > http://willem.engen.nl/debian > > > > please read debian install instructions there. I did only some > > > > very basic tests and seems to work nicely. Please report if I > > > > missed something. > > > > > > Thanks a lot Willem! > > > > > > I asked a couple of persons to try it, and added a link from > > > the download page. > > > > > > If someone can help with the official package, it'd be very > > > good too... > > > > > > > The official package is now up-to-date. > > > > /Mattias, Debian user. > > Good! > > I updated the download page accordingly. > > BTW, did you update the package? > Is this the same package Willem made? > > Cheers > Jorge.- > Phil Blundell updated it, and I don't think it's the same as Willem's, but I'm not sure. /Mattias

June 1, 2004

Re: [Dillo-dev]page increment (was: very simple question, and many kudos!)

by Jorge Arellano Cid

On Mon, 31 May 2004, Sebastian Geerken wrote: > On Sun, May 30, Jorge Arellano Cid wrote: > > On Fri, 28 May 2004, Brian Hechinger wrote: > > > so far, it's perfect for me. the only thing that i have a question about is > > > PgUp and PgDn only moving half a page at a time. is there a way to get them > > > to move a full page? > > > > Some time ago there was a patch, that i'd gladly apply, for > > that. Maybe Sebastian has it. I'm not sure. Sebastian? > > Scrolling half a page is actually standard behaviour of Gtk, look > e.g. at gtk_layout_size_allocate() (in gtklayout.c), which is more or > less responsible for this in our case, since our code uses > GdkAdjustment::page_increment, which is set there. > > The attached patch "solves" it, but I'm not sure, wether the standard > behaviour should be overridden. Hmmmm well, from time to time I find the current behaviour less useful than a full page scroll. I don't know the rationale for a half page scroll in gtklayout either, but it looks as though a full page scroll would be a good default. > [later you wrote] > > It will probably still take some time, it is a bit more difficult than > I thought. Should I wait a bit for a new version? > PS: I'm currently working on huge changes in Dw, so committing patches > to Dw shold currently avoided when possible. No problem! I want to make a dillo-0.8.2 release real soon. The main reason is that the previous releasse announcement caught freshmeat in the middle of a HW upgrade. When finally they brought back the site, the pending announcements went almost unnoticed (roughly 30 times less visibility!). Cheers Jorge.-

June 1, 2004

Re: [Dillo-dev]Some remarks on the UI

by Nicola Girardi

This is what I replied privately to Sebastian: > BTW, it is not very obvious, that there is a menu behind these two > buttons. Perhaps there should be, in the icon, a small arrow > directed downdwards, or so. In fact I didn't ever discovered there was such (useful) menu. :-( > (ii) It provides a function for attaching a menu in a better way, > than we have currently, for the "Back" and "Forward" menus, > and for the bug meter. Another menu I didn't catch, the bug meter menu. :-) > Comments welcome. Very nice. :-)

June 1, 2004

Re: [Dillo-dev]dillo as a debian package ..?

by Jorge Arellano Cid

On Mon, 31 May 2004, Mattias Östergren wrote: > On Sun, 30 May 2004 11:38:55 -0400 (CLT) Jorge Arellano Cid > <jcid(a)dillo.org> wrote: > > > > > > > On Tue, 25 May 2004, Willem van Engen wrote: > > > > > Hi all, > > > > > > ok, I made a new .deb for 0.8.1 and setup an apt repository on > > > http://willem.engen.nl/debian > > > please read debian install instructions there. I did only some very > > > basic tests and seems to work nicely. Please report if I missed > > > something. > > > > Thanks a lot Willem! > > > > I asked a couple of persons to try it, and added a link from > > the download page. > > > > If someone can help with the official package, it'd be very > > good too... > > > > The official package is now up-to-date. > > /Mattias, Debian user. Good! I updated the download page accordingly. BTW, did you update the package? Is this the same package Willem made? Cheers Jorge.-

June 1, 2004

Re: [Dillo-dev]dillo as a debian package ..?

by Mattias Östergren

On Sun, 30 May 2004 11:38:55 -0400 (CLT) Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > On Tue, 25 May 2004, Willem van Engen wrote: > > > Hi all, > > > > ok, I made a new .deb for 0.8.1 and setup an apt repository on > > http://willem.engen.nl/debian > > please read debian install instructions there. I did only some very > > basic tests and seems to work nicely. Please report if I missed > > something. > > Thanks a lot Willem! > > I asked a couple of persons to try it, and added a link from > the download page. > > If someone can help with the official package, it'd be very > good too... > The official package is now up-to-date. /Mattias, Debian user.

May 31, 2004

Re: [Dillo-dev]page increment (was: very simple question, and many kudos!)

by Sebastian Geerken

On Mon, May 31, Brian Hechinger wrote: > On Mon, May 31, 2004 at 03:09:03PM +0200, Sebastian Geerken wrote: > > > > Scrolling half a page is actually standard behaviour of Gtk, look > > e.g. at gtk_layout_size_allocate() (in gtklayout.c), which is more or > > less responsible for this in our case, since our code uses > > GdkAdjustment::page_increment, which is set there. > > hmmmmmm. can't say i care for that behavior. maybe i should whine to the GTK > folks and see if i can either get that changed, or at least get it setup so > there is some way to override it at run/compile time? They won't probably change it, especially since dillo depends on Gtk 1.2, which development has been closed, AFAIK. > > The attached patch "solves" it, but I'm not sure, wether the standard > > behaviour should be overridden. > > how hard would it be to make it a runtime option? something in dillorc? that > way you can have standard behavior and also the option to change its behavior > to satisfy people like me? Actually, it envolves reading Havoc Pennington's essay "Free software and good user interfaces" (http://ometer.com/free-software-ui.html) especially the section "The Question of Preferences", and considering, whether or not this configuration option should be added. Actually, I'd rather like it either having applied or not (not configurable), the others should apply the patch. (Adding the code is BTW rather simple, just look at how other options are handled in "prefs.c".) > how about this. let me know when the CVS tree stablizes and i'll write that > for you. It will probably still take some time, it is a bit more difficult than I thought. Sebastian

May 31, 2004