June 2004 - Dillo-dev - lists.mailman3.com

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

by Sebastian Geerken

On Wed, Jun 02, Jorge Arellano Cid wrote: > With regard to the new widget for buttons, and the inminence of > 0.8.2 release, if you like it could be the last enhancement > before the release (I'd also add the context-menu indicator to > the bug-meter pixmaps). Yes, I think it should be finished within a few days (Sunday or so). Sebastian

June 3, 2004

Re: [Dillo-dev][bug] ppc64 crash on right-click / bug tracking system

by Jorge Arellano Cid

On Thu, 3 Jun 2004, Thomas Cort wrote: > Hi, Hi! > I ran into a problem where dillo crashes when I right click on any > part of a webpage. A full bug report is below this paragraph. When I > went to use the bug tracking system I noticed the "Max 256 chars" > notice. Is it possible to get this increased? I couldn't get my bug > report into <= 256 characters. The <=256 limit is to keep things concise. It helps developers a lot to skim all the bugs when reviewing the bugtrack... Of course there're times when this is not possible (just a few in four years!), and you can resort to the mailing list. > > Dillo 0.8.1 on GNU/Linux (yellowdog 3.0) ppc64 (Apple G5) > > configure options: > --prefix=/home1/students/tcort > > To reproduce bug: > ssh with X11 forwarding and compression turned on, start dillo, and > right click on any part of the webpage. > > Notes: > I don't have local access to this machine, so I don't know if it's an > X11 forwarding bug or a ppc64 specific bug. Browsing webpages works > fine as long as you don't right click. Using other programs with X11 > forwarding from this machine, such as gimp, work fine. > > Output: > tcort@pepsi tcort $ ssh -X -C turing.ubishops.ca > tcort(a)turing.ubishops.ca's password: > [tcort@turing tcort]$ bin/dillo > dillo_dns_init: Here we go! > Disabling cookies. > Nav_open_url: Url=>about:splash< > Gdk-ERROR **: BadWindow (invalid Window parameter) > serial 2306 error_code 3 request_code 38 minor_code 0 > Gdk-ERROR **: BadAccess (attempt to access private resource denied) > serial 2307 error_code 10 request_code 102 minor_code 0 > [tcort@turing tcort]$ I recognize not to have a clue about this problem, but... > Gdk-ERROR **: BadAccess (attempt to access private resource denied) looks as we have a permission problem here. A google search for: "Gdk-ERROR **: BadAccess (attempt to access private resource denied)" led to: http://www.cygwin.com/ml/cygwin-xfree/2004-04/msg00348.html It seems that you need to use the "-Y" switch instead of "-X". Read the thread for details and tell us how it went. Cheers Jorge.-

June 3, 2004

[Dillo-dev][bug] ppc64 crash on right-click / bug tracking system

by Thomas Cort

Hi, I ran into a problem where dillo crashes when I right click on any part of a webpage. A full bug report is below this paragraph. When I went to use the bug tracking system I noticed the "Max 256 chars" notice. Is it possible to get this increased? I couldn't get my bug report into <= 256 characters. Dillo 0.8.1 on GNU/Linux (yellowdog 3.0) ppc64 (Apple G5) configure options: --prefix=/home1/students/tcort To reproduce bug: ssh with X11 forwarding and compression turned on, start dillo, and right click on any part of the webpage. Notes: I don't have local access to this machine, so I don't know if it's an X11 forwarding bug or a ppc64 specific bug. Browsing webpages works fine as long as you don't right click. Using other programs with X11 forwarding from this machine, such as gimp, work fine. Output: tcort@pepsi tcort $ ssh -X -C turing.ubishops.ca tcort(a)turing.ubishops.ca's password: [tcort@turing tcort]$ bin/dillo dillo_dns_init: Here we go! Disabling cookies. Nav_open_url: Url=>about:splash< Gdk-ERROR **: BadWindow (invalid Window parameter) serial 2306 error_code 3 request_code 38 minor_code 0 Gdk-ERROR **: BadAccess (attempt to access private resource denied) serial 2307 error_code 10 request_code 102 minor_code 0 [tcort@turing tcort]$

June 3, 2004

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

by Sebastian Geerken

On Wed, Jun 02, Jorge Arellano Cid wrote: > On Wed, 2 Jun 2004, Sebastian Geerken wrote: > > Using the middle button on menu entries should probably be possible, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > perhaps we'll have to write a new widget for it, as I did with > > GtkButton. However, the new behaviour should be an extension to the > > standard, while the current behaviour is IMO very unusable. > > Note: I don't mean to be able to pop-up the history menu with > the middle button, but to have the option of middle-clicking its ^^^^^^^^^^^^^^^^^^^ > entry to open a new window or tab. ^^^^^ Yes, this is also what I mean. Sebastian

June 2, 2004

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

by Jorge Arellano Cid

On Wed, 2 Jun 2004, Sebastian Geerken wrote: > On Tue, Jun 01, Jorge Arellano Cid wrote: > > On Mon, 31 May 2004, 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. > > > > > > 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. > > This is somehow adopted by other widgets as well, I'm not sure what > other X programs do. Anyway, I don't care much about, apply it, if you > want the behaviour changed. Ok, done. I just used: 0.96 * allocation->height to allow for an overlapping of roughly one line. Comments welcome. > > > > 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? > > Don't wait on me. I'm currently not able to tell when I'm finished. > > > > PS: I'm currently working on huge changes in Dw, so committing patches > > > to Dw shold currently avoided when possible. > > In some cases, smaller patches may be applied; if merging fails, I'll > have to adjust it by hand. Anyway, I'd like to be explicitly told > about the changes, so I can better react on it. With regard to the new widget for buttons, and the inminence of 0.8.2 release, if you like it could be the last enhancement before the release (I'd also add the context-menu indicator to the bug-meter pixmaps). Cheers Jorge.-

June 2, 2004

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

by Jorge Arellano Cid

On Wed, 2 Jun 2004, Sebastian Geerken wrote: > On Tue, Jun 01, Jorge Arellano Cid wrote: > > On Mon, 31 May 2004, Sebastian Geerken wrote: > > > 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". > > In most cases, the most "abstract" events should be used, i.e. > "clicked" for buttons, and "activate" for menu entries. Thanks for the tip! > > If a new implementation acts the same as the current one, from > > the user's point of view, it's perfect for me. > > If should act different! The bugmeter window should be shown as soon > as the user *releases* the button (as always). Yes, I meant that, but failed to explain it properly. ;) > > [...] > > > (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. > > Using the middle button on menu entries should probably be possible, > perhaps we'll have to write a new widget for it, as I did with > GtkButton. However, the new behaviour should be an extension to the > standard, while the current behaviour is IMO very unusable. Note: I don't mean to be able to pop-up the history menu with the middle button, but to have the option of middle-clicking its entry to open a new window or tab. > > > > 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. > > I'll look at it later. Ok. Cheers Jorge.-

June 2, 2004

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

by Jorge Arellano Cid

On Wed, 2 Jun 2004, Madis Janson wrote: > > 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). Good! > > 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. I read a lot of the GnuTLS manual, and found some interesting facts and functions that could help. Including a function somewhat like what you sketched: > 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 > Here follos an abridgment of interesting information inside the GnuTLS manual: <q> http://www.gnu.org/software/gnutls/manual/gnutls/gnutls.html -- Description: Technically GnuTLS is a portable ANSI C based library which implements the TLS 1.0/1.1 and SSL 3.0 protocols, accompanied with the required framework for authentication and public key infrastructure. The library is available under the GNU Lesser GPL license1.2. Important features of the GnuTLS library include: * Support for TLS 1.0, TLS 1.1 and SSL 3.0 protocols. * Support for both X.509 and OpenPGP certificates. * Support for handling and verification of certificates. * Support for SRP for TLS authentication. * Support for TLS Extension mechanism. * Support for TLS Compression Methods. Additionally GnuTLS provides a limited emulation API for the widely used OpenSSL1.3 library, to ease integration with existing applications. --- Verifying peer's certificate A TLS session is not secure just after the handshake procedure has finished. It must be considered secure, only after the peer's certificate and identity have been verified. That is, you have to verify the signature in peer's certificate, the hostname in the certificate, and expiration dates. Just after this step you should treat the connection as being a secure one. The following function is a simple example on how to verify a single certificate. Real world programs should be able to handle certificate chains as well. --- /* This function will try to verify the peer's certificate, and * also check if the hostname matches, and the activation, expiration dates. */ void verify_certificate(gnutls_session session, const char* hostname) [...] --- Resuming Sessions: The gnutls_handshake function, is expensive since a lot of calculations are performed. In order to support many fast connections to the same server a client may use session resuming. Session resuming is a feature of the TLS protocol which allows a client to connect to a server, after a successful handshake, without the expensive calculations. This is achieved by using the previously established keys. GnuTLS supports this feature, and the example resume client illustrates a typical use of it. --- http://msmtp.sourceforge.net/ (GPL) Version 1.0.0: - correctly handle certificate chains in tls.c GnuTLS code --- Interview (Nikos Mavroyanopoulos): http://www.gnu-friends.org/story/2003/12/17/14525/717 </q> Some remarks: The msmtp project is interesting because is GPLed, and handles certificate chains, so it can be reused. The "Resuming Sessions" feature is also interesting because it could initially account for what we've been calling "connection caching". (i.e. instead of keeping an SSL socket alive to communicate with the server, a new session can be requested, and GnuTLS' "resuming sessions" does the rest). The documentation is clear and comes with several examples. Please give it a look Madis. Cheers Jorge.-

June 2, 2004

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

by Sebastian Geerken

On Tue, Jun 01, Jorge Arellano Cid wrote: > On Mon, 31 May 2004, 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. > > > > 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. This is somehow adopted by other widgets as well, I'm not sure what other X programs do. Anyway, I don't care much about, apply it, if you want the behaviour changed. > > 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? Don't wait on me. I'm currently not able to tell when I'm finished. > > PS: I'm currently working on huge changes in Dw, so committing patches > > to Dw shold currently avoided when possible. In some cases, smaller patches may be applied; if merging fails, I'll have to adjust it by hand. Anyway, I'd like to be explicitly told about the changes, so I can better react on it. Sebastian

June 2, 2004

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

by Sebastian Geerken

On Tue, Jun 01, Jorge Arellano Cid wrote: > On Mon, 31 May 2004, Sebastian Geerken wrote: > > 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". In most cases, the most "abstract" events should be used, i.e. "clicked" for buttons, and "activate" for menu entries. > If a new implementation acts the same as the current one, from > the user's point of view, it's perfect for me. If should act different! The bugmeter window should be shown as soon as the user *releases* the button (as always). > [...] > > (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. Using the middle button on menu entries should probably be possible, perhaps we'll have to write a new widget for it, as I did with GtkButton. However, the new behaviour should be an extension to the standard, while the current behaviour is IMO very unusable. > > 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. I'll look at it later. > 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. Yes. It got a bit complicated, since in the old design, DwWidget and DwGtkViewport interacted very tightly, and DwWidget assumed too much about DwGtkViewport. Anyway (in case anybody thinks that a port could be simpler :-), as I already stated, this redesign is rather useful for the future, not only for the port (and it increases the code quality, since it reduces dependencies). Sebastian

June 2, 2004

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