- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev]HTTPS Cleanup

by Jorge Arellano Cid

On Fri, Jul 23, 2004 at 01:10:42PM -0400, Garrett Kajmowicz wrote: > I have gone through and modified the https.c file to use (what I believe are) > your preferred coding standards, with one exception. Done. (i.e. commited). > I *cannot* stand unbraced if statements (or any other statements), and thus I > braced them in two locations. I also don't care for use of the tertiary > operator, but you wrote the function it is used in, so I don't plan on > touching it. No problem. Always-braced if statements probably is a better practice! > > I would also like your opinion on how to "clean up" the function > save_certificate_home() > It has three exit points, and dropping it to fewer would be somewhat of a > challenge to do cleanly. OK, I'll look at it. > There are a few loctions where I believe you broke a statement which would ift > on one line, specifically snprintf statements. I might have dont this > (though I can't think of why). If this is the case, could you let me know > your reasoning behind this? I'd like to learn from this if possible... Those statements were originally in your patch! :-) <q> [...] + /*Attempt to create .dillo/certs blindly - check later*/ + snprintf(buf,4096,"%s/.dillo/", + g_get_home_dir() + ); + mkdir(buf, 01777); + snprintf(buf,4096,"%s/.dillo/certs/", + g_get_home_dir() + ); + mkdir(buf, 01777); + + do{ + snprintf(buf,4096,"%s/.dillo/certs/%x.%u\0", + g_get_home_dir(), + X509_subject_name_hash(cert), i + ); [...] </q> You can make them one line. --- BTW, g_free() tests for NULL so this statements: if (http_query != NULL){ g_free(http_query); http_query = NULL; } can simply become: g_free(http_query); because the variable is local, there's no need to NULL it. Except for 'root_url' which can also be made local. Finally, please send the patches to me directly (not to the list), but comments belong to the list. This saves some band width to hundreds of subscribers. Thanks for taking my advice. It'so much easier to review the patches now. Cheers Jorge.-

July 23, 2004

[Dillo-dev]HTTPS Cleanup

by Garrett Kajmowicz

I have gone through and modified the https.c file to use (what I believe are) your preferred coding standards, with one exception. I *cannot* stand unbraced if statements (or any other statements), and thus I braced them in two locations. I also don't care for use of the tertiary operator, but you wrote the function it is used in, so I don't plan on touching it. I would also like your opinion on how to "clean up" the function save_certificate_home() It has three exit points, and dropping it to fewer would be somewhat of a challenge to do cleanly. There are a few loctions where I believe you broke a statement which would ift on one line, specifically snprintf statements. I might have dont this (though I can't think of why). If this is the case, could you let me know your reasoning behind this? I'd like to learn from this if possible... - Garrett Kajmowicz

July 23, 2004

Re: [Dillo-dev]HTTPS certificate support

by Garrett Kajmowicz

> Producing code quick is not the goal. The point is to produce > well designed code that works OK, and that's easy to > read/review/follow and thus to maintain. I'm spending a lot of time on this because I've been working on a project for several months to revamp some PCs with 32MB of RAM to be sent to the homes of deaf people. I'm running a uClibc based distribution, but I need a good web browser which works. Thus I want to get this done as soon as possible. > The problem I found (and probably your classmates) is that > reviewing rushed-code takes more time than necessary, and once > understood, it changes. In my case is a bit worst because I took > the extra time to polish it, only to find it back with my work > wasted. I crank out a lot of code because I think quickly and clearly, and have no life. If I could comit often enough, I could gurantee you about 4 hours/day solid development for the next month and a half. More if I dropped another pet programming project and some metal work I am doing. I am usually the person doing the code reviews. I'm also the person who tends to put the most documentation into my code to make the most redably readable. > Let me suggest you a second stage after your code is working. > Stop, and take the same amount of time polishing it. Think of the > design, long functions, multiple exit points, global variables, > data structures, future additions, variable names, memory > management, comments, etc. > > Once you finish this second stage, testing for robustness will > be much easier (third stage). Once you've done it, your > classmates will love your code. Most of my classmates can't program *snort*. Then again, neither can the comp sci professors..... > Just an example, multiple exit points make code more complex to > grasp because you have to understand the flow of execution of > each one of the exits, before having confidence of not breaking > it with some changes. I would disagree with that point. With single exit point functions, you have to carry a variable (extra stack allocation) through the application and all code. Thus you can either have large numbers of nested statements (which is very effective and reasonably clean, but excedes line length) or you have your finalized variable being carried through the rest of the application with nothing else to do. With the multi-exit point strategy, you can exit the application as soon as you are done done whatever it is that you need to do. This way you aren't hanging around in the code any more. I have found that tends to make for better code than single-exit writing. > > Another big problem comes with finalization code (freeing > memory, leaving variables in a stable state, return codes, side > effects...). > > Take for instance yes_ssl_support(). Look at the many exit > points and its finalization code, and compare with a single exit > code version. > > It took a lot of time. > > Please follow my advice. Since this is the preffered coding standard (I suggest adding it to the coding standards on the web) I will follow it as you wish. I will follow any coding standards to the letter, and will take suggestions as I see fit. I will modify everything that I have writen to conform to your preferences, and resubmit. I'm tempted to blow away all of my work and start over sust so I can have a sync'd tree to make sane diffs against. *sigh* - Garrett

July 23, 2004

Re: [Dillo-dev]HTTPS certificate support

by Garrett Kajmowicz

I accepted nearly all of the changes you requested. In recards to switch statements, in the updated function there is a need to deal with 3 possabilities, thus I kept the switch statement. The rest of the locations I converted to braced if statements which use else statements to return an abort code as the alternative option. Though computer science dictates that there should be only one entry and one exit point from a function, using break calls not only hurts my eyes, it produces code which is less readable. Thus all locations where a function might exit for one purpose I have the code to exit for all purposes, with a catch-all return -1 at the function. Personal preference. Once again, please evaluate. - Garrett Kajmowicz

July 22, 2004

Re: [Dillo-dev]HTTPS certificate support

by Garrett Kajmowicz

> > ## Why do we need these functions back again commented out? I originally wrote them to parse the response number from the displayed dialog. When I submitted my post, you wrote a new function in https, thus the old one was no longer needed and I commented it out, as that is what I presumed you wanted to do. If you prefer it, please continue to use it. > > ## This can be avoided with g_get_home_dir(). I spent quite a few minutes looking for such a function, but I guess I just missed it in the API reference. With the function name, I know what I am looking for and will rewrite immediately. I'm going to redo this whole thing and resubmit. Part of my problem is trying to maintain multiple versions, working after I submit one patch but before it is applied. My school mates hate me for it - I crank out code like a mad man! - Garrett Kajmowicz

July 22, 2004

Re: [Dillo-dev]HTTPS certificate support

by Jorge Arellano Cid

On Wed, Jul 21, 2004 at 07:30:51PM -0400, Garrett Kajmowicz wrote: > OK - this patch backs out a few trivial changes which were made about 2 > patches ago due to code redundancy and are no longer needed. > > This patch detects self-signed certificates and gives the user the option to > permanently trust them, autosaving to the .dillo/certs directory. Please > give this a whirl, and then commit it. Let me know when done so I can while > my current devel tree clean and get a new copy - this way I don't have to > manually correct all of the spelling errors with each patch :-) Oh!??? This patch may be not what you intended, as I found many weird things I prefer to comment it, and wait for the version 2 of it... (my comments start with "##") diff -rpu dillo-cvs/dillo/dpi/dpiutil.c dillo-dev/dillo/dpi/dpiutil.c --- dillo-cvs/dillo/dpi/dpiutil.c 2004-07-16 22:19:00.000000000 +0000 +++ dillo-dev/dillo/dpi/dpiutil.c 2004-07-21 15:06:53.000000000 +0000 @@ -11,6 +11,7 @@ */ #include "dpiutil.h" +#include <unistd.h> #include <stdio.h> #include <string.h> #include <glib.h> @@ -127,7 +128,7 @@ gint send_stream_4(FILE *in_stream, gcha return 0; } -gint send_stream_mode(FILE *in_stream, gchar *url, int mode) +gint send_stream_mode(FILE *in_stream, gchar *url, gint mode) { switch (mode){ case SEND_STREAM_MODE_CHAR: @@ -143,3 +144,43 @@ gint send_stream_mode(FILE *in_stream, g return -1; } +/*gint dpi_message_response_number(){ + gint response_number; + gint rd_len; + gchar buf[4096]; + gchar * response = 0; +*/ + /*Read in user responce*/ +/* rd_len = read(STDIN_FILENO, buf, 4096); + response = Get_attr_value(buf, rd_len, "msg" ); + + if(response == NULL){ + return -1; + } + + sscanf(response, "%d", &response_number); + g_free(response); + response = NULL; + return response_number; + +} +*/ ## Why do we need these functions back again commented out? + +char * get_environment_variable_value(char ** envp, char * var){ + int i; + int var_length; + + var_length = strlen(var); + + for(i=0;i<10000;i++){ + if(envp[i] == NULL){ + return NULL; + } + if(strncmp(var, envp[i], var_length) == 0){ + /*We have found wanted variable*/ + return (envp[i] + var_length + 1); + } + } + + +} ## This can be avoided with g_get_home_dir(). diff -rpu dillo-cvs/dillo/dpi/dpiutil.h dillo-dev/dillo/dpi/dpiutil.h --- dillo-cvs/dillo/dpi/dpiutil.h 2004-07-13 21:42:22.000000000 +0000 +++ dillo-dev/dillo/dpi/dpiutil.h 2004-07-21 15:05:54.000000000 +0000 @@ -65,4 +65,17 @@ gint send_stream_4(FILE *in_stream, gcha #define SEND_STREAM_MODE_COARSE 3 #define SEND_STREAM_MODE_COARSE_FAST 4 -gint send_stream_mode(FILE *in_stream, gchar *url, int mode); +gint send_stream_mode(FILE *in_stream, gchar *url, gint mode); + + +/* + * Get dialog response number + */ +//gint dpi_message_response_number(); + +/* + * Process environmental variables, returning a specific one + * or NULL if it cannot be found + */ + +char * get_environment_variable_value(char ** envp, char * var); ## As with the commented functions, this is not necessary. diff -rpu dillo-cvs/dillo/dpi/https.c dillo-dev/dillo/dpi/https.c --- dillo-cvs/dillo/dpi/https.c 2004-07-21 14:49:16.000000000 +0000 +++ dillo-dev/dillo/dpi/https.c 2004-07-21 23:20:50.000000000 +0000 @@ -49,10 +49,10 @@ #include <sys/wait.h> #include <errno.h> #include <sys/time.h> +#include <sys/stat.h> #include <glib.h> #include "dpiutil.h" - #ifdef ENABLE_SSL #include <openssl/ssl.h> @@ -60,13 +60,17 @@ static int get_network_connection(gchar * url); static int handle_certificate_problem(SSL * ssl_connection); +static int save_certificate_home(X509 * cert); #endif +int main(int argc, char ** argv, char ** envp); ## The whole environment can be avoided by using g_get_home_dir(). ## (If the need arises for env variables, getenv() can be used) /*---------------------------------------------------------------------------*/ +char ** env; /*Points inside envp so no freeing*/ ## Not needed. +gchar * root_url; /*Holds the URL we are connecting to*/ #ifdef ENABLE_SSL @@ -99,7 +103,6 @@ static void yes_ssl_support(void) { SSL_CTX * ssl_context = NULL; SSL * ssl_connection = NULL; - X509 * remote_cert = NULL; FILE *F_stdin; gchar *dpip_tag = NULL, *cmd = NULL, *url = NULL, *http_query = NULL; @@ -125,11 +128,18 @@ static void yes_ssl_support(void) /*Set directory to load certificates from*/ /*FIXME - provide for sysconfdir variables and such*/ - SSL_CTX_load_verify_locations(ssl_context, NULL, "/etc/ssl/certs/" ); + if(SSL_CTX_load_verify_locations(ssl_context, NULL, "/etc/ssl/certs/" ) == 0){ + g_printerr("Error opening system x509 certificate location\n"); + } + snprintf(buf, 4095, "%s/.dillo/certs/", get_environment_variable_value(env, "HOME") ); + + if(SSL_CTX_load_verify_locations(ssl_context, NULL, buf )==0){ + g_printerr("Error opening user x509 certificate location\n"); + } ssl_connection = SSL_new(ssl_context); if (ssl_connection == NULL){ - printf("Error creating SSL connection\n"); + g_printerr("Error creating SSL connection\n"); } /*Need to do the following if we want to deal with all possible ciphers*/ @@ -168,6 +178,7 @@ static void yes_ssl_support(void) if (network_socket<0){ /*Cleanup*/ g_printerr("Network socket create error\n"); + g_free(root_url); g_free(http_query); g_free(url); g_free(cmd); @@ -181,6 +192,7 @@ static void yes_ssl_support(void) /* Configure SSL to use network file descriptor */ if (SSL_set_fd(ssl_connection, network_socket) == 0){ g_printerr("Error connecting network socket to SSL\n"); + g_free(root_url); g_free(http_query); g_free(url); g_free(cmd); @@ -195,6 +207,7 @@ static void yes_ssl_support(void) /*Actually do SSL connection handshake*/ if (SSL_connect(ssl_connection) != 1){ g_printerr("SSL_connect failed\n"); + g_free(root_url); g_free(http_query); g_free(url); g_free(cmd); @@ -206,53 +219,23 @@ static void yes_ssl_support(void) return; } - /*Now check to see what kind of certificate we have*/ - /*Do we have a certificate at all?*/ - remote_cert = SSL_get_peer_certificate(ssl_connection); - if (remote_cert == NULL){ - if (handle_certificate_problem(ssl_connection) < 0){ - g_printerr("Certificate not found and abort\n"); - g_free(http_query); - g_free(url); - g_free(cmd); - g_free(dpip_tag); - close(network_socket); - fclose(F_stdin); - SSL_free(ssl_connection); - SSL_CTX_free(ssl_context); - return; - } - g_printerr("Certificate not found but continuing\n"); - } else { - /* We have no use for the certificate, so call free. This is - * important if we go to convert this to a server, or if we - * use the app. on a machine without protected memory. - */ - X509_free(remote_cert); - remote_cert = NULL; - /*Check to see the verification on the certificate*/ - if (SSL_get_verify_result(ssl_connection) != X509_V_OK){ - if (handle_certificate_problem(ssl_connection) < 0){ - g_printerr("Certificate not verified and abort\n"); - g_free(http_query); - g_free(url); - g_free(cmd); - g_free(dpip_tag); - close(network_socket); - fclose(F_stdin); - SSL_free(ssl_connection); - SSL_CTX_free(ssl_context); - return; - } - g_printerr("Certificate not verified but continuing\n"); - } + /*Use handle error function to decide what to do*/ + if (handle_certificate_problem(ssl_connection) < 0){ + g_printerr("Certificate not found and abort\n"); + g_free(root_url); + g_free(http_query); + g_free(url); + g_free(cmd); + g_free(dpip_tag); + close(network_socket); + fclose(F_stdin); + SSL_free(ssl_connection); + SSL_CTX_free(ssl_context); + return; } - g_printerr("Do http stuff here\n"); - /*Send query we want*/ SSL_write(ssl_connection, http_query, strlen(http_query)); - g_printerr("Sending: %s\n", http_query); /*Analyse response from server*/ @@ -268,6 +251,7 @@ static void yes_ssl_support(void) /*Begin cleanup of all resources used*/ g_printerr("Resource cleanup\n"); + g_free(root_url); g_free(http_query); g_free(url); g_free(cmd); @@ -318,6 +302,7 @@ static int get_network_connection(gchar url_look_up = url + url_offset; } + root_url = g_strdup(url_look_up); hp=gethostbyname(url_look_up); /*url_look_uip no longer needed, so free if neccessary*/ @@ -355,59 +340,143 @@ static int get_network_connection(gchar static int handle_certificate_problem(SSL * ssl_connection) { gint response_number; - long ssl_st; - int retval = -1; + int retval; + char buf[4096]; ## retval was set to -1 for security. The safest way for doing checks ## is to assume everything is forbidden unless explicitly allowed. ## That's way the functions were rearranged this way. X509 * remote_cert; remote_cert = SSL_get_peer_certificate(ssl_connection); - if (remote_cert == NULL){ + if(remote_cert == NULL){ /*Inform user that remote system cannot be trusted*/ printf("<dpi cmd='dialog' msg='%s' alt1='%s' alt2='%s'>", - "The remote system is NOT presenting a certificate.\n" - "This site CAN NOT be trusted. Sending data is NOT SAFE.\n" - "What do I do?", + "The remote system is not presenting a certificate and cannot be trused", "Continue", "Cancel" ); fflush(stdout); ## Reversing the new message's text? ## This's waht made me think this patch wasn't generated as intended. - /*Read in user response*/ + /*Read in user response*/ response_number = dialog_get_answer_number(); - - /* Abort on anything but "Continue" */ - if (response_number == 1) - retval = 0; - - } else { - X509_free(remote_cert); - /*Figure out why (and if) the remote system can't be trusted*/ - ssl_st = SSL_get_verify_result(ssl_connection); - switch (ssl_st) { - case X509_V_OK: /*Everything is Kosher*/ - retval = 0; - break; - default: /*Need to add more options later*/ - printf("<dpi cmd='dialog' msg='%s' alt1='%s' alt2='%s'>", - "The remote system presented a certificate that" - " can NOT be verified.\n" - "This site CAN NOT be trusted. Sending data is NOT SAFE.\n" - "What do I do?", - "Continue", "Cancel" - ); - fflush(stdout); - - response_number = dialog_get_answer_number(); - - /* Abort on anything but "Continue" */ - if (response_number == 1) - retval = 0; - break; + + switch(response_number){ + case 1: /*Continue*/ + return 0; + case 2: /*Cancel*/ + return -1; + default: /*Safety - abort*/ + return -1; + } ## This switch statements were removed so the function has one clear ## flow of execution with a single exit, and not multiple exits ## (this is easier to understand, and less prone to errors) + }else{ + /*Figure out if (and why) the remote system can't be trusted*/ + retval = SSL_get_verify_result(ssl_connection); + switch (retval){ + case X509_V_OK: /*Everything is Kosher*/ + X509_free(remote_cert); + remote_cert = 0; + return 0; + case X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT: + /*Either self signed and untrusted*/ + /*Extract CN from certificate name information*/ + strncpy(buf, (strstr(remote_cert->name, "/CN=") + 4), + strstr(strstr(remote_cert->name, "/CN=") + 4, "/") - + strstr(remote_cert->name, "/CN=")- 4); + /*Add terminating NULL*/ + buf[strstr(strstr(remote_cert->name, "/CN=") + 4, "/") - + strstr(remote_cert->name, "/CN=")- 3] = 0; + printf("<dpi cmd='dialog' msg='%s%s' alt1='%s' alt2='%s' alt3='%s'>", + "The remote certificate is self-signed and untrusted:\n For address:", + buf, "Continue", "Cancel", "Trust Certificate" + ); + fflush(stdout); + response_number = dialog_get_answer_number(); + switch(response_number){ + case 1: + X509_free(remote_cert); + remote_cert = 0; + return 0; + case 2: + X509_free(remote_cert); + remote_cert = 0; + return -1; + case 3: + /*Save certificate to a file here and recheck chain*/ + /*Potential security problems because we are writing filesystem*/ + save_certificate_home(remote_cert); + X509_free(remote_cert); + remote_cert = 0; + return 1; + default: + X509_free(remote_cert); + remote_cert = 0; + return -1; + } + default: /*Need to add more options later*/ + printf("<dpi cmd='dialog' msg='%s%i' alt1='%s' alt2='%s'>", + "The remote certificate cannot be verified", + retval, "Continue", "Cancel" + ); + fflush(stdout); + response_number = dialog_get_answer_number(); + X509_free(remote_cert); + remote_cert = 0; + switch(response_number){ + case 1: + return 0; + case 2: + return -1; + default: + return -1; + } ## Ditto as above. } } return retval; } +int save_certificate_home(X509 * cert){ + char buf[4096]; + + FILE * fp = NULL; + unsigned int i = 0; + + /*Attempt to create .dillo/certs blindly - check later*/ + snprintf(buf,4096,"%s/.dillo/", + get_environment_variable_value(env, "HOME") + ); + mkdir(buf, 01777); + snprintf(buf,4096,"%s/.dillo/certs/", + get_environment_variable_value(env, "HOME") + ); + mkdir(buf, 01777); + + do{ + snprintf(buf,4096,"%s/.dillo/certs/%x.%u\0", + get_environment_variable_value(env, "HOME"), + X509_subject_name_hash(cert), i + ); ## All get_environment_variable_value() can be avoided + + fp=fopen(buf, "r"); + if(fp == NULL){ + /*File name doesn't exist so we can use it safely*/ + fp=fopen(buf, "w"); + if(fp == NULL){ + g_printerr("Unable to open cert save file in home dir\n"); + return 1; + }else{ + PEM_write_X509(fp, cert); + fclose(fp); + g_printerr("Wrote certificate\n"); + return 0; + } + }else{ + fclose(fp); + } + i++; + } while( i < 1024 ); + + return 1; +} + + ## Please use "if (" and "} else {" #else @@ -480,9 +549,9 @@ static void no_ssl_support(void) /*---------------------------------------------------------------------------*/ -int main(void) +int main(int argc, char ** argv, char ** envp) { - + env=envp; #ifdef ENABLE_SSL yes_ssl_support(); #else -- Cheers Jorge.- PS: Do you prefer me to make the changes for you to sync with CVS? :) PS2: Patches of this size can be sent directly to me.

July 22, 2004

[Dillo-dev]HTTPS certificate support

by Garrett Kajmowicz

OK - this patch backs out a few trivial changes which were made about 2 patches ago due to code redundancy and are no longer needed. This patch detects self-signed certificates and gives the user the option to permanently trust them, autosaving to the .dillo/certs directory. Please give this a whirl, and then commit it. Let me know when done so I can while my current devel tree clean and get a new copy - this way I don't have to manually correct all of the spelling errors with each patch :-) - Garrett

July 21, 2004

Re: [Dillo-dev]More https goodness

by Garrett Kajmowicz

> > > https://www.paypal.com/en_US/i/icon/secure_lock_2.gif > 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). No, I have not checked that out. I will take a look at it to see how it looks. I personally figure that OpenSSL is more likely to be installed on a given system than GnuTLS (which is an issue) and more thoroughly tested. But I will definetively check to see if it gives us any significant advantages. > > > > 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? The certificate seems to be trustable to me, but the lock is an image that is sent wether or not the connection is secure. In short, it is just there to make the customer feel better. I'll have more stuff for you shortly. - Garrett Kajmowicz

July 21, 2004

Re: [Dillo-dev]any documents about html parser?

by Jorge Arellano Cid

On Mon, Jul 19, 2004 at 05:32:33PM +0800, Calvin Yu wrote: > Hello everyone: > Are there any documents about html parser in Dillo? It seems > HtmlParser.txt is too brief. And it is not easy to analyse the > code about html parser. > Thanks a lot! I guess you're thinking of making dillo able to render chinese. There're several issues about this, I made an answer for the soon-to-be-publised Dillo FAQ. <q> ----------------------------------------------------------------- Q: Internationalization and Localization (i18n & l10n) The main problem for doing this is that the underlying library that Dillo uses (GTK+-1.2.x), doesn't support UTF-8 character rendering. Dillo currently supports ISO-LATIN1 and works internally with this encoding. GTK+-2.x supports UTF-8 but it's too big to be used with Dillo. After a long feasibility analysis FLTK was chosen as the next widget library for Dillo. Among other things FLTK supports UTF-8 and before Dillo is ported to it, i18n and l10n is frozen. There're some patches that enable Dillo to view some other encodings though. Beware that as Dillo works internally in Latin1, these patches do break some functionality and don't expect them to work flawlessly (specially with FORMS and entities). That's why they're not included in the main source tree. OTOH, we know they're worth to people longing to see their native language. These patches may apply to an old version of Dillo. Please don't hesitate to write to the original authors if you update them. Problems with these patches don't belong to our mailing list. If you update the patch, and the original author is no longer interested, you may tell us to update the link. Russian (also suports other encodings): http://bobuk.ipost.ru/packages/dillo/ Japanese: http://oldeee.see.ed.ac.uk/~rjt/dillo/japanese.html Polish: http://www.chemia.px.pl/cgi-bin/archiwum.cgi#dillo Some comments about Hindi and Chinese: these languages need an special technology to render, and they're not currently supported under FLTK, but the possibility is open. This is, the best path to add support for them in Dillo, when it runs over FLTK, is to add Chinese/Hindi support directly into FLTK. The FLTK developing team should be contacted for the details. Some References: Glibc's Texinfo documentation on iconv() (`info iconv`). http://developer.gnome.org/doc/whitepapers/gtki18n/index.html http://www.pango.org/ </q> Sorry if my guess was wrong! Cheers Jorge.-

July 21, 2004

Re: [Dillo-dev]form fields too narrow

by Jorge Arellano Cid

Hi Thorben, On Wed, Jul 14, 2004 at 06:05:24PM +0200, Thorben Thuermer wrote: > Hello, > > it seems that dillo renders all text input fields in forms one > character too narrow, for example on: > http://www.efa.de/gvh/XSLT_TRIP_REQUEST2?language=en > we have: > <INPUT NAME="itdTimeHour" VALUE="17" SIZE="2" MAXLENGTH="2" ...> > (field for the hour of the time) > which clearly requests to be two charcters, but ends up having space > for only one, making it hard to use (horizontal scrolling). > > in the source (html.c) i found: > if ((attrbuf = Html_get_attr(html, tag, tagsize, "size"))) > gtk_widget_set_usize(widget, strtol(attrbuf, NULL, 10) * > gdk_char_width(widget->style->font, '0'), 0); > > which makes the fields too narrow... > changing it to (1+strtol(attrbuf, NULL, 10)) fixes the problem. > i can only assume that 'gtk_widget_set_usize' sets the *outside* > dimensions of the widget? (or that something else is off there...) Done! I couldn't find anything hintful in the doc nor the source of gtk_widget_set_usize(). Anyway, tests showed it to work OK, so it's commited now. Thanks Jorge.- PS: Sorry for the delay.

July 21, 2004

[Dillo-dev]Replying to lists (was: dpip dialog for https (and dpis in general))

by Sebastian Geerken

Hi Brian (and other Mutt users), On Mon, Jul 19, Brian Hechinger wrote: > On Fri, Jul 16, 2004 at 04:49:09PM -0400, Jorge Arellano Cid wrote: > > > > Oh, I almost forgot: > > > > It's not necessary to CC' me, I do read dillo-dev! :) > > i'm lazy, if i just hit r for reply, it goes to you, but if i hit g for group > reply, it goes to both you and the list (notice that you are in the To: field > and the list is in the CC: field) > > i believe mutt has some sort of fancy list groking, and maybe i should look > into setting that up and using it. :) Put the line lists dillo-dev ... into ~/.muttrc, and then press shift+L to reply to the list. R will make private replies possible. Sebastian

July 21, 2004

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

July 21, 2004

Re: [Dillo-dev]More https goodness

by Garrett Kajmowicz

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. > > 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. 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. > > gives me the warning dialog. Is this OK? Warnings are OK. 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? 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. Thanks. - Garrett Kajmowicz

July 21, 2004

Re: [Dillo-dev]More https goodness

by Jorge Arellano Cid

Hi Garret, On Fri, Jul 16, 2004 at 08:05:43PM -0400, Garrett Kajmowicz wrote: > I am going to start by appologizing: this diff contains two separate items. I > needed to do one to get the other to work, and I didn't want to risk having > one patch getting applied before the other. > > Anyways, two things done: > 1) Added a function to dpiutils which does the complete read in from stdin > for the dpi response tag and returns the option number selected. Please feel > free to add comments about error return values and so forth. > > 2) Added *preliminary* error checking in the https dpi which notifies the > user in the event that no certificate is presented or that the certificate is > not verified. I will do a more thorough breakdown and other options once I > know that this meets spec. Let me know if you prefer different wording on > the messages as well. > > In short, please review and commit. 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(...) 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 gives me the warning dialog. Is this OK? Cheers Jorge.- PS: For those using CVS, you can avoid the dialogs by setting 'retval = 0' in https.c.

July 21, 2004

Re: [Dillo-dev]dpip dialog for https (and dpis in general)

by Brian Hechinger

On Fri, Jul 16, 2004 at 04:48:01PM -0400, Jorge Arellano Cid wrote: > > Hi Brian, hi there! > Well, now you need to wait a bit for Garret to hook the dpip > dialog to https and thus enable GUI dialogs through Dillo. ok, cvs is setup and going here, so as soon as things are checked in, i can grab the changes. > Excellent. It needs careful review, particularly from crypto > savvy guys. i'm not super savvy, but i've got a pretty good clue as to what i'm doing. i'll run it through its paces. > Those are m4 macros for other programs that need polishing. > It's unrelated to Dillo. ahh, ok, good!! -brian -- "Suits, man. They are as incapable of logical thought as they are of honesty." -- Dave McGuire --

July 19, 2004

Re: [Dillo-dev]dpip dialog for https (and dpis in general)

by Brian Hechinger

On Fri, Jul 16, 2004 at 04:49:09PM -0400, Jorge Arellano Cid wrote: > > Oh, I almost forgot: > > It's not necessary to CC' me, I do read dillo-dev! :) i'm lazy, if i just hit r for reply, it goes to you, but if i hit g for group reply, it goes to both you and the list (notice that you are in the To: field and the list is in the CC: field) i believe mutt has some sort of fancy list groking, and maybe i should look into setting that up and using it. :) -brian -- "Suits, man. They are as incapable of logical thought as they are of honesty." -- Dave McGuire --

July 19, 2004

[Dillo-dev]cookies giving me problems

by Brian Hechinger

The cookies file has a file lock: disabling cookies in this dillo! this worked great on my NetBSD/macppc box (NetBSD 2.0 BETA) but does not work on my NetBSD/i386 box (NetBSD 1.6.2). any hints? -brian -- "Suits, man. They are as incapable of logical thought as they are of honesty." -- Dave McGuire --

July 19, 2004

[Dillo-dev]any documents about html parser?

by Calvin Yu

Hello everyone: Are there any documents about html parser in Dillo? It seems HtmlParser.txt is too brief. And it is not easy to analyse the code about html parser. Thanks a lot!

July 19, 2004

Re: [Dillo-dev]Cookie problem

by Brian Hechinger

On Sun, Jul 18, 2004 at 01:49:57PM -0400, Todd Slater wrote: > Try > > .ebay.com ACCEPT > > Todd bingo!! that's it, thanks!! -brian -- "Suits, man. They are as incapable of logical thought as they are of honesty." -- Dave McGuire --

July 18, 2004

Re: [Dillo-dev]Cookie problem

by Todd Slater

On Sun, Jul 18, 2004 at 11:11:08AM -0400, Brian Hechinger wrote: > i told him about cookiesrc, he's going to try that. but that brings me to a > cookie issue of my own. i have: > > ebay.com ACCEPT > > in my cookiesrc, but ebay keeps telling me that my browser is rejecting cookies. > am i doing something silly? > > -brian Try .ebay.com ACCEPT Todd

July 18, 2004

Re: [Dillo-dev]Cookie problem

by Brian Hechinger

i told him about cookiesrc, he's going to try that. but that brings me to a cookie issue of my own. i have: ebay.com ACCEPT in my cookiesrc, but ebay keeps telling me that my browser is rejecting cookies. am i doing something silly? -brian On Sat, Jul 17, 2004 at 12:38:31PM +0200, Claus Conrad wrote: > Dear dillo community, > > I have subscribed to this list because I'm developing a PHP-based website > which I want to be compatible with dillo. The site is located at > http://www.kabbeleje.dk/vask/ . It uses PHP's session management, sending a > cookie named PHPSESSID to the browser on login. This works great in most > other browsers I tried, but somehow not in dillo. > > The PHP code I'm using looks something like > if (login_successful) { > session_start(); > // ... > header("Location: http://" . $_SERVER['HTTP_HOST'] . > dirname($_SERVER['PHP_SELF']) . "/index.php?PHPSESSID" . > strip_tags(session_id())); > } > > I added the get parameter to the redirect URL after trying without; both > ways seem to work in e. g. Mozilla, but it doesn't change anything in dillo. > The redirect works, but the user isn't logged in. I guess it's just a minor > erroneous piece in the code, but don't know where to look. Any help would be > very much appreciated. A test login is available on request, if necessary. > Thanks a lot in advance. > > Regards, > Claus > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev -- "Suits, man. They are as incapable of logical thought as they are of honesty." -- Dave McGuire --

July 18, 2004

Re: [Dillo-dev]https patch

by Jorge Arellano Cid

On Fri, 16 Jul 2004, Garrett Kajmowicz wrote: > This patch allows the https dpi to release the memory used by the X509 > certificate. This is a trivial patch. The call used to check the > certificate increases a reference count, but it is never decreased, causing > the memory not to be freed at the optimum time. This is not actually needed > on a Linux system because of the MMU, but in the event this is converted to a > server or run on a MMU-less processor, this could cause problems - I'm not > familiar enough with the internals of OpenSSL to be certain. > > Anyways, please apply the following patch to CVS. Done! Jorge.- Return-path: <gkajmowi(a)tbaytel.net> Received: from front1.tbaytel.net ([216.211.26.100]) by free.wearlab.de with esmtp (Exim 3.35 #1 (Debian)) id 1Blcez-0000pp-00 for <dillo-dev(a)lists.auriga.wearlab.de>; Sat, 17 Jul 2004 02:02:37 +0200 Received: from [216.211.55.127] (HELO gkajmowicz.garrett.dyndns.biz) by front1.tbaytel.net (CommuniGate Pro SMTP 4.1.8) with ESMTP id 10289746 for dillo-dev(a)lists.auriga.wearlab.de; Fri, 16 Jul 2004 20:02:05 -0400 From: Garrett Kajmowicz <gkajmowi(a)tbaytel.net> Reply-To: gkajmowi(a)tbaytel.net To: Dillo mailing list <dillo-dev(a)lists.auriga.wearlab.de> Date: Fri, 16 Jul 2004 20:05:43 -0400 User-Agent: KMail/1.6.82 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_X1G+Azi/XGRRdxA" Message-Id: <200407162005.43310.gkajmowi(a)tbaytel.net> Subject: [Dillo-dev]More https goodness Sender: dillo-dev-admin(a)lists.auriga.wearlab.de Errors-To: dillo-dev-admin(a)lists.auriga.wearlab.de X-BeenThere: dillo-dev(a)lists.auriga.wearlab.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: <mailto:dillo-dev-request@lists.auriga.wearlab.de?subject=help> List-Post: <mailto:dillo-dev@lists.auriga.wearlab.de> List-Subscribe: <http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev>, <mailto:dillo-dev-request@lists.auriga.wearlab.de?subject=subscribe> List-Id: For dillo web browser developers <dillo-dev.lists.auriga.wearlab.de> List-Unsubscribe: <http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev>, <mailto:dillo-dev-request@lists.auriga.wearlab.de?subject=unsubscribe> List-Archive: <http://lists.auriga.wearlab.de/pipermail/dillo-dev/> --Boundary-00=_X1G+Azi/XGRRdxA Content-Type: text/plain; charset="us-ascii"; boundary="" Content-Transfer-Encoding: 7bit Content-Disposition: inline I am going to start by appologizing: this diff contains two separate items. I needed to do one to get the other to work, and I didn't want to risk having one patch getting applied before the other. Anyways, two things done: 1) Added a function to dpiutils which does the complete read in from stdin for the dpi response tag and returns the option number selected. Please feel free to add comments about error return values and so forth. 2) Added *preliminary* error checking in the https dpi which notifies the user in the event that no certificate is presented or that the certificate is not verified. I will do a more thorough breakdown and other options once I know that this meets spec. Let me know if you prefer different wording on the messages as well. In short, please review and commit. - Garrett --Boundary-00=_X1G+Azi/XGRRdxA Content-Type: text/x-diff; charset="us-ascii"; name="dillo-initial-https-prompting.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dillo-initial-https-prompting.diff" diff -pur dillo-cvs/dillo/dpi/dpiutil.c dillo-dev/dillo/dpi/dpiutil.c --- dillo-cvs/dillo/dpi/dpiutil.c 2004-07-16 22:19:00.000000000 +0000 +++ dillo-dev/dillo/dpi/dpiutil.c 2004-07-16 23:43:54.000000000 +0000 @@ -11,6 +11,7 @@ */ #include "dpiutil.h" +#include <unistd.h> #include <stdio.h> #include <string.h> #include <glib.h> @@ -143,3 +144,22 @@ gint send_stream_mode(FILE *in_stream, g return -1; } +gint dpi_message_response_number(){ + gint response_number; + gint rd_len; + gchar buf[4096]; + gchar * response = 0; + + /*Read in user responce*/ + rd_len = read(STDIN_FILENO, buf, 4096); + response = Get_attr_value(buf, rd_len, "msg" ); + + if(response == NULL){ + return -1; + } + + sscanf(response, "%d", &response_number); + g_free(response); + response = NULL; + return response_number; +} diff -pur dillo-cvs/dillo/dpi/dpiutil.h dillo-dev/dillo/dpi/dpiutil.h --- dillo-cvs/dillo/dpi/dpiutil.h 2004-07-13 21:42:22.000000000 +0000 +++ dillo-dev/dillo/dpi/dpiutil.h 2004-07-16 23:35:27.000000000 +0000 @@ -66,3 +66,9 @@ gint send_stream_4(FILE *in_stream, gcha #define SEND_STREAM_MODE_COARSE_FAST 4 gint send_stream_mode(FILE *in_stream, gchar *url, int mode); + + +/* + * Get dialog response number + */ +gint dpi_message_response_number(); diff -pur dillo-cvs/dillo/dpi/https.c dillo-dev/dillo/dpi/https.c --- dillo-cvs/dillo/dpi/https.c 2004-07-13 21:42:22.000000000 +0000 +++ dillo-dev/dillo/dpi/https.c 2004-07-16 23:57:09.000000000 +0000 @@ -329,7 +329,56 @@ int get_network_connection(gchar * url) */ int handle_certificate_problem(SSL * ssl_connection) { - + gint response_number; + int retval; + FILE * fp; + + X509 * remote_cert; + + remote_cert = SSL_get_peer_certificate(ssl_connection); + if(remote_cert == NULL){ + /*Inform user that remote system cannot be trusted*/ + printf("<dpi cmd='dialog' msg='%s' alt1='%s' alt2='%s'>", + "The remote system is not presenting a certificate and cannot be trused", + "Continue", "Cancel" + ); + fflush(stdout); + + /*Read in user responce*/ + response_number = dpi_message_response_number(); + + switch(response_number){ + case 1: /*Continue*/ + return 0; + case 2: /*Cancel*/ + return -1; + default: /*Safety - abort*/ + return -1; + } + }else{ + X509_free(remote_cert); + /*Figure out why (and if) the remote system can't be trusted*/ + retval = SSL_get_verify_result(ssl_connection); + switch (retval){ + case X509_V_OK: /*Everything is Kosher*/ + return 0; + default: /*Need to add more options later*/ + printf("<dpi cmd='dialog' msg='%s' alt1='%s' alt2='%s'>", + "The remote certificate cannot be verified", + "Continue", "Cancel" + ); + fflush(stdout); + response_number = dpi_message_response_number(); + switch(response_number){ + case 1: + return 0; + case 2: + return -1; + default: + return -1; + } + } + } return 0; } --Boundary-00=_X1G+Azi/XGRRdxA-- Return-path: <lists(a)clausconrad.com> Received: from 62.79.172.2.adsl.brh.tiscali.dk ([62.79.173.2] helo=CLAUS2) by free.wearlab.de with esmtp (Exim 3.35 #1 (Debian)) id 1Blma9-0002qd-00 for <dillo-dev(a)lists.auriga.wearlab.de>; Sat, 17 Jul 2004 12:38:18 +0200 Received: from CLAUS2 ([127.0.0.1]) by CLAUS2 with Microsoft SMTPSVC(6.0.3790.0); Sat, 17 Jul 2004 12:38:31 +0200 From: "Claus Conrad" <lists(a)clausconrad.com> To: <dillo-dev(a)lists.auriga.wearlab.de> Date: Sat, 17 Jul 2004 12:38:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Thread-Index: AcRr4r/tMjm9VSHvSAaMiR/YmFGcTAABNXwA In-Reply-To: <20040717094502.7683.47919.Mailman(a)free.wearlab.de> Message-ID: <CLAUS2CoyRwKBEK0ZMC00000002@CLAUS2> X-OriginalArrivalTime: 17 Jul 2004 10:38:31.0671 (UTC) FILETIME=[34459070:01C46BEA] Subject: [Dillo-dev]Cookie problem Sender: dillo-dev-admin(a)lists.auriga.wearlab.de Errors-To: dillo-dev-admin(a)lists.auriga.wearlab.de X-BeenThere: dillo-dev(a)lists.auriga.wearlab.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: <mailto:dillo-dev-request@lists.auriga.wearlab.de?subject=help> List-Post: <mailto:dillo-dev@lists.auriga.wearlab.de> List-Subscribe: <http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev>, <mailto:dillo-dev-request@lists.auriga.wearlab.de?subject=subscribe> List-Id: For dillo web browser developers <dillo-dev.lists.auriga.wearlab.de> List-Unsubscribe: <http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev>, <mailto:dillo-dev-request@lists.auriga.wearlab.de?subject=unsubscribe> List-Archive: <http://lists.auriga.wearlab.de/pipermail/dillo-dev/> Dear dillo community, I have subscribed to this list because I'm developing a PHP-based = website which I want to be compatible with dillo. The site is located at http://www.kabbeleje.dk/vask/ . It uses PHP's session management, = sending a cookie named PHPSESSID to the browser on login. This works great in most other browsers I tried, but somehow not in dillo. The PHP code I'm using looks something like if (login_successful) { session_start(); // ... header("Location: http://" . $_SERVER['HTTP_HOST'] . dirname($_SERVER['PHP_SELF']) . "/index.php?PHPSESSID" . strip_tags(session_id())); } I added the get parameter to the redirect URL after trying without; both ways seem to work in e. g. Mozilla, but it doesn't change anything in = dillo. The redirect works, but the user isn't logged in. I guess it's just a = minor erroneous piece in the code, but don't know where to look. Any help = would be very much appreciated. A test login is available on request, if = necessary. Thanks a lot in advance. Regards, Claus

July 16, 2004

Re: [Dillo-dev]https patch

by Jorge Arellano Cid

On Fri, 16 Jul 2004, Garrett Kajmowicz wrote: > This patch allows the https dpi to release the memory used by the X509 > certificate. This is a trivial patch. The call used to check the > certificate increases a reference count, but it is never decreased, causing > the memory not to be freed at the optimum time. This is not actually needed > on a Linux system because of the MMU, but in the event this is converted to a > server or run on a MMU-less processor, this could cause problems - I'm not > familiar enough with the internals of OpenSSL to be certain. > > Anyways, please apply the following patch to CVS. OK, I'll review it. > > btw, my configuration script diff seems not to have been applied yet. Are > there any standards that I should be complying with that I am not? It got in while you were writting this email! > Thanks. More stuff to follow tonight. Great. BTW, here's an old email of mine with regard to GnuTLS. It comes with some interesting information: http://article.gmane.org/gmane.comp.web.dillo.devel/2093/match=gnutls Cheers Jorge.-

July 16, 2004

Re: [Dillo-dev]Configure script patch

by Jorge Arellano Cid

On Wed, 14 Jul 2004, Garrett Kajmowicz wrote: > This patch updates the configuration system to chack for OpenSSL libraries, > and compile appropriately. I have tested to make sure that the system work > with both ssl enabled and disabled, though I do not know how well it will > react to not have OpenSSL present at all. > > Along wwith those changes go changes to the https.c file to take advantage of > this newly available information. In the event that it is compiled without > ssl support, an error page will come back indicating that the dpi was > compiled without ssl support, and link to the openssl website. Commmited. It'd be interesting to know whether it detects GnuTLS. This library is under the GPL, implements SSL and even has a wrapper for OpenSSL. It'd not be rare if it worked out of the box. BTW, some time ago I made a little skim on it and it had a good session caching scheme (almost transparent to the API), done internally. Cheers Jorge.-

July 16, 2004

[Dillo-dev]https patch

by Garrett Kajmowicz

This patch allows the https dpi to release the memory used by the X509 certificate. This is a trivial patch. The call used to check the certificate increases a reference count, but it is never decreased, causing the memory not to be freed at the optimum time. This is not actually needed on a Linux system because of the MMU, but in the event this is converted to a server or run on a MMU-less processor, this could cause problems - I'm not familiar enough with the internals of OpenSSL to be certain. Anyways, please apply the following patch to CVS. btw, my configuration script diff seems not to have been applied yet. Are there any standards that I should be complying with that I am not? Thanks. More stuff to follow tonight. - Garrett

July 16, 2004

Re: [Dillo-dev]dpip dialog for https (and dpis in general)

by Jorge Arellano Cid

Oh, I almost forgot: It's not necessary to CC' me, I do read dillo-dev! :) Cheers Jorge.-

July 16, 2004

Re: [Dillo-dev]dpip dialog for https (and dpis in general)

by Jorge Arellano Cid

Hi Brian, > On Fri, Jul 16, 2004 at 10:24:20AM -0400, Jorge Arellano Cid wrote: >> >> The changes are now in the CVS. > > gotten. :) Well, now you need to wait a bit for Garret to hook the dpip dialog to https and thus enable GUI dialogs through Dillo. > >> Brian: unless you're interested in dpi development, or want to >> alpha test the https dpi, I'd recommend 0.8.2 as an upgrade. > > i'm interested in https. i will do my best to break it. :) Excellent. It needs careful review, particularly from crypto savvy guys. > > i run into this issue running autogen.sh though: > > wonko@zaphod$ ./autogen.sh > aclocal found > autoheader found > autoconf found > automake found > [Checks passed] > Generating... > /usr/pkg/share/aclocal/pkg.m4:5: warning: underquoted definition of PKG_CHECK_MODULES > run info '(automake)Extending aclocal' > or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal > /usr/pkg/share/aclocal/libtasn1.m4:12: warning: underquoted definition of AM_PATH_LIBTASN1 > /usr/pkg/share/aclocal/libgnutls.m4:12: warning: underquoted definition of AM_PATH_LIBGNUTLS > /usr/pkg/share/aclocal/libgnutls-extra.m4:12: warning: underquoted definition of AM_PATH_LIBGNUTLS_EXTRA > /usr/pkg/share/aclocal/libgcrypt.m4:23: warning: underquoted definition of AM_PATH_LIBGCRYPT > /usr/pkg/share/aclocal/gtk.m4:7: warning: underquoted definition of AM_PATH_GTK > /usr/pkg/share/aclocal/gpg-error.m4:7: warning: underquoted definition of AM_PATH_GPG_ERROR > /usr/pkg/share/aclocal/glib.m4:8: warning: underquoted definition of AM_PATH_GLIB > /usr/pkg/share/aclocal/audiofile.m4:12: warning: underquoted definition of AM_PATH_AUDIOFILE > /usr/pkg/share/aclocal/ao.m4:9: warning: underquoted definition of XIPH_PATH_AO > configure.in: installing `./install-sh' > configure.in: installing `./missing' > configure.in:6: installing `./config.guess' > configure.in:6: installing `./config.sub' > dpi/Makefile.am: installing `./depcomp' > > just warnings, but i thought you should know. 'info automake' (or autoconf) explains this. Those are m4 macros for other programs that need polishing. It's unrelated to Dillo. Cheers Jorge.-

July 16, 2004

Re: [Dillo-dev]dpip dialog for https (and dpis in general)

by Brian Hechinger

On Fri, Jul 16, 2004 at 10:24:20AM -0400, Jorge Arellano Cid wrote: > > The changes are now in the CVS. gotten. > Brian: unless you're interested in dpi development, or want to > alpha test the https dpi, I'd recommend 0.8.2 as an upgrade. i'm interested in https. i will do my best to break it. :) i run into this issue running autogen.sh though: wonko@zaphod$ ./autogen.sh aclocal found autoheader found autoconf found automake found [Checks passed] Generating... /usr/pkg/share/aclocal/pkg.m4:5: warning: underquoted definition of PKG_CHECK_MODULES run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal /usr/pkg/share/aclocal/libtasn1.m4:12: warning: underquoted definition of AM_PATH_LIBTASN1 /usr/pkg/share/aclocal/libgnutls.m4:12: warning: underquoted definition of AM_PATH_LIBGNUTLS /usr/pkg/share/aclocal/libgnutls-extra.m4:12: warning: underquoted definition of AM_PATH_LIBGNUTLS_EXTRA /usr/pkg/share/aclocal/libgcrypt.m4:23: warning: underquoted definition of AM_PATH_LIBGCRYPT /usr/pkg/share/aclocal/gtk.m4:7: warning: underquoted definition of AM_PATH_GTK /usr/pkg/share/aclocal/gpg-error.m4:7: warning: underquoted definition of AM_PATH_GPG_ERROR /usr/pkg/share/aclocal/glib.m4:8: warning: underquoted definition of AM_PATH_GLIB /usr/pkg/share/aclocal/audiofile.m4:12: warning: underquoted definition of AM_PATH_AUDIOFILE /usr/pkg/share/aclocal/ao.m4:9: warning: underquoted definition of XIPH_PATH_AO configure.in: installing `./install-sh' configure.in: installing `./missing' configure.in:6: installing `./config.guess' configure.in:6: installing `./config.sub' dpi/Makefile.am: installing `./depcomp' just warnings, but i thought you should know. -brian -- "Performing a Google search on the fairly unique name you've chosen weeks ago for a piece of software you're writing, only to discover that the sole occurance of that name is as a pen-name for someone who spends his spare time writing X-rated PowerPuff Girls fan fiction is pretty-much a buzzkill." -- Jonathan Patschke --

July 16, 2004

Re: [Dillo-dev]dpip dialog for https (and dpis in general)

by Jorge Arellano Cid

Garret, Brian, CC: anyone interested ;) On Fri, 16 Jul 2004, Brian Hechinger wrote: > On Thu, Jul 15, 2004 at 11:31:12PM -0400, Jorge Arellano Cid wrote: >> >> I'll test and upload tomorrow. > > let us know, i'd love to test it. i just setup a new machine, and the latest > dillo in NetBSD's packages collection is 0.8.1, so i'm ready to upgrade > anyway. ;) The changes are now in the CVS. Example code can be find in the hello dpi (and also in nav.c). For instance, after upgrading the dpi binaries, launch Dillo and load this url "dpi:/hello/world". It will pop up a dialog, make a choice and look at the answer. repeat the test by going Back and Forward (the hello dpi is set to always reload). The relevant code is well commented. Look inside the hello dpi and you can also review the new dpiapi.[ch] files. Nav.c has an example of use for a_Interface_question_dialog() too. This should be enough for asking the user about certificates that can't be authenticated. Note that the code is not final, i.e. it needs some polishing and extensions. The good news is that in clearly illustrates the process and now is much easier to do it so. even the data structures and interface was thought to be extensible. Cheers Jorge.- Brian: unless you're interested in dpi development, or want to alpha test the https dpi, I'd recommend 0.8.2 as an upgrade.

July 16, 2004

[Dillo-dev]dpip dialog for https (and dpis in general)

by Jorge Arellano Cid

Hi there, In the afternoon I had a prototype working, wich BTW was very pleasing to see working, after living a long time as an abstract design. It needed some touches, and while working on them, some hidden bugs outside its scope showed in nav.c's repost dialog. Short story, I decided to integrate some code in interface.c with the new dialog renderer, use a more flexible design and fix the bugs. I'll test and upload tomorrow. Cheers Jorge.-

July 16, 2004

Re: [Dillo-dev]Configure script patch

by Jorge Arellano Cid

On Wed, 14 Jul 2004, Garrett Kajmowicz wrote: > This patch updates the configuration system to chack for OpenSSL libraries, > and compile appropriately. I have tested to make sure that the system work > with both ssl enabled and disabled, though I do not know how well it will > react to not have OpenSSL present at all. > > Along wwith those changes go changes to the https.c file to take advantage of > this newly available information. In the event that it is compiled without > ssl support, an error page will come back indicating that the dpi was > compiled without ssl support, and link to the openssl website. Ok, I'll check it after copding the dpip dialog. Yesterday some seasickness and stomach aches kept me away from the computer. I hope it gets better today... > btw, is there any easy command which will delete all of the non CVS files? > make distclean seems to keep the configure script around, along with other > cache information. I don't know! ;) BTW, I made a shell script to do it... Just in case you want to generate patches easily, keep a CVS repository tree and a working copy, that way: diff -pru dillo-cvs dillo-wc > Mydiff works very well. Cheers Jorge.-

July 15, 2004

[Dillo-dev]Configure script patch

by Garrett Kajmowicz

This patch updates the configuration system to chack for OpenSSL libraries, and compile appropriately. I have tested to make sure that the system work with both ssl enabled and disabled, though I do not know how well it will react to not have OpenSSL present at all. Along wwith those changes go changes to the https.c file to take advantage of this newly available information. In the event that it is compiled without ssl support, an error page will come back indicating that the dpi was compiled without ssl support, and link to the openssl website. btw, is there any easy command which will delete all of the non CVS files? make distclean seems to keep the configure script around, along with other cache information. - Garrett Kajmowicz

July 14, 2004

Re: [Dillo-dev]Re: HTTPS

by Garrett Kajmowicz

> Typical console error mesage (from yahoo mail secure logon page) > > lookes like: > |----------------- > > Nav_open_url: > Url=>https://login.yahoo.com/config/login?.branch=&.src=ym&.v=0&.u=bh9jje50 >fau8u&.last=&promo=&.intl=us&.bypass=&.partner=&pkg=&stepid=&.done=< url_str > = > https://login.yahoo.com/config/login?.branch=&.src=ym&.v=0&.u=bh9jje50fau8u >&.last=&promo=&.intl=us&.bypass=&.partner=&pkg=&stepid=&.done= main.c:153: > get_command: dpid tag is NULL > > : main.c:326: main: get_command failed > : {In https.filter.dpi} > > SSL_connect failed > Dpi: [Dpi_process_io] IOClose > > |----------------- > > and dillo provides no other feedback. Since I usually involk > dillo from my window manager, the console output is not normally > availible to me. I will take a look at it as soon as a I get a chance. > > Perhaps returning a SSL connection failed page would be nice. I'll see what I can do. I'm worried about code bloat, esp since Dillo prides itself on being very small. > > Dumb question: Is http 1.1 authentication amenable to a similar > treatment? That is one of the features I really miss. http 1.1 *anything* would require Dillo to support HTTP 1.1 When workingo n the HTTPS plugin, all of the requests that I pass through are HTTP 1.0 messages, meaning that we are indicating, at least to the other server, that we don't support any HTTP 1.1 features. Actually, all the HTTPS filter DPI does is open up an SSL connection to the remote computer and then pass all the HTTP connections through. THe only thing that makes it complicated at all is dealing with certificate isssues if they are invalid. - Garrett Kajmowicz

July 14, 2004

Re: [Dillo-dev]Re: HTTPS

by David McKee

On Tue, 13 Jul 2004, Jorge Arellano Cid wrote: > I just finished uploading my patches to the dpis (those that > were independent from your code but that required a merge) and > the tarball tree you sent me. Compiled and ran find on my Debian 3.0 system. Compiled on my tweaked RedHat 6.2 system, but it won't actually open some of the https URLs I tried. Typical console error mesage (from yahoo mail secure logon page) lookes like: | |----------------- Nav_open_url: Url=>https://login.yahoo.com/config/login?.branch=&.src=ym&.v=0&.u=bh9jje50fau8u…< url_str = https://login.yahoo.com/config/login?.branch=&.src=ym&.v=0&.u=bh9jje50fau8u… main.c:153: get_command: dpid tag is NULL : main.c:326: main: get_command failed : {In https.filter.dpi} SSL_connect failed Dpi: [Dpi_process_io] IOClose |----------------- | and dillo provides no other feedback. Since I usually involk dillo from my window manager, the console output is not normally availible to me. Perhaps returning a SSL connection failed page would be nice. The funny part is I could open a yahoo mail account over a secure connection from the Debian machine... Nor do I understand why it opens some, but not all secure URLs. Anyway, it looks like a good start and I'm very pleased to see it. Dumb question: Is http 1.1 authentication amenable to a similar treatment? That is one of the features I really miss. Thanks all, -- -- David McKee -- dmckee(a)jlab.org -- (757) 269-7492 (Office)

July 14, 2004

[Dillo-dev]form fields too narrow

by Thorben Thuermer

Hello, it seems that dillo renders all text input fields in forms one character too narrow, for example on: http://www.efa.de/gvh/XSLT_TRIP_REQUEST2?language=en we have: <INPUT NAME="itdTimeHour" VALUE="17" SIZE="2" MAXLENGTH="2" ...> (field for the hour of the time) which clearly requests to be two charcters, but ends up having space for only one, making it hard to use (horizontal scrolling). in the source (html.c) i found: if ((attrbuf = Html_get_attr(html, tag, tagsize, "size"))) gtk_widget_set_usize(widget, strtol(attrbuf, NULL, 10) * gdk_char_width(widget->style->font, '0'), 0); which makes the fields too narrow... changing it to (1+strtol(attrbuf, NULL, 10)) fixes the problem. i can only assume that 'gtk_widget_set_usize' sets the *outside* dimensions of the widget? (or that something else is off there...) - Thorben

July 14, 2004

Puppy Linux 0.9.1 has Dillo, works fine

by Barry Kauler

Hi guys, Just a comment because I started a thread a little while ago, that never got resolved. The 0.8.x series of Puppy Linux had all the apps compiled against uClibc, which saved about 1M but caused various compatibility problems. One of those was the Dillo plugins not working right. That problem never got resolved, however it is now academic as far as Puppy is concerned, as I recompiled everything against glibc, for Puppy 0.9.0 (using Mandrake 9.2 as the host). Having finished with that, I wish to make one further interesting comment. Puppy is a tiny distro, the live-CD is only 49M, designed to fit on a business-card-size CD, and easily install to usb pen drive or Zip drive. The widget libraries used are only GTK 1.2, Xaw95 and Tk/tix/bwidget. I also installed the gdkxft package, which is a fairly small library that bolts font antialising onto GTK 1.2 apps. I wish to report that it works brilliantly with Dillo. The latest Puppy. v0.9.1, has Dillo with font antialiasing and it sure looks good. Note that one interesting thing about gdkxft, for anyone else interested in trying it, is that it can be applied on a per-application basis, without recompiling the app. You just install libgdkxft.so, then do this when launching Dillo: LD_PRELOAD=/usr/lib/libgdkxft.so dillo There is a config file, /etc/gdkxftrc I think it's called, and all you do is put a single "*" in it, which means apply antialiasing to all fonts. Puppy home page: http://www.goosee.com/puppy News page: http://www.goosee.com/puppy/news.htm Regards, Barry Kauler

July 14, 2004

Re: [Dillo-dev] Puppy Linux 0.9.1 has Dillo, works fine

by Garrett Kajmowicz

> Hi guys, > Just a comment because I started a thread a little while ago, that never > got resolved. > > The 0.8.x series of Puppy Linux had all the apps compiled against uClibc, > which saved about 1M but caused various compatibility problems. > One of those was the Dillo plugins not working right. > > That problem never got resolved, however it is now academic as far as Puppy > is concerned, as I recompiled everything against glibc, for Puppy 0.9.0 > (using Mandrake 9.2 as the host). That is too bad. My development system for Dillo is a chroot environment running off of uClibc. Regular glib and gtk were installed. If you are looking for a good distro to base your Linux distro off of, check out uwoody at www.uclibc.org - Garrett Kajmowicz

July 14, 2004

[Dillo-dev]Re: HTTPS

by Jorge Arellano Cid

Hi Garret, I just finished uploading my patches to the dpis (those that were independent from your code but that required a merge) and the tarball tree you sent me. It comes with some minor modifications ... > Let me know what you think of the coding style, etc. Very clean and compliant with our Naming&Coding in general. I did minor changes, like keeping it inside 80 columns and switching "if(" to "if (" (not a requirement but just to be consistent with the rest of Dillo). Only in one function I needed to reindent to 3 spaces... Unto less trivial stuff, Makefile.am was modified so dpiutil.h gets in the tarball produced with `make dist`. It would be great if you can add some SSL library detection routine to configure.in so https.c uses the no_ssl_support() function when the libarry is not present (or detected). > Also, if you could give me some direction on how to implement the prompt for > unverified certificates (and the code/location to save them to), it would be > greatly appreciated. I'm working on this. Maybe tomorrow... For those that feel curious, you can get the latest CVS and test the new dpis. Just remember to install them after typing make! :-) More seriously, kill dpid and any running dpi before: 'make install' (or 'make install-strip'). Best Jorge.- PS: great start for 0.8.3-pre!

July 13, 2004

Re: Fwd: Re: [Dillo-dev]Plugin infrastructure

by Jorge Arellano Cid

On Mon, 12 Jul 2004, Garrett Kajmowicz wrote: >> In the discussions before introduction of dpi was the point UI could >> entierely be done using standart html, rendered by dillo itself. >> >> Maybe we could use this here. >> >> I would see two (new) dpi commands: >> -Pop a new dillo window (maybe with some args: modal, no toolbar, no >> addressbar..., set its size, url) >> -Make a window reload >> >> So dpi could make a window pop for asking anything about certificates, >> with a standart html form in it. It would allow to change window title >> (through <title>) and make the gui customisable for future needs, and >> even be portable for gtk->other toolkit change. >> >> I thought of the 'reload window' feature not directly for https, but for >> download dpi. This would allow us to update the status of current >> downloads; shown in a dedicated window, somewhat ala Firefox, but again, >> entierely in html. Yes Nicolas, the html interface is an important part of the dpip feature set. Now, each dpi is different and that's why flexibility is important. I mean, for bookmarks and preferences (and probably for general purpose applications like the dillo-based control center of DSL linux), HTML is perfect. For the downloads, a native GUI inside the dpi, is an easier approach, and in the https case, dialog windows through Dillo by means of a dpip request seem to be the most adequate. > > That is very interesting, but causes two problems. First of all, from what I > have seen , it looks like it would be difficult to implement modal dialog > boxes. This is important for security warnings so that they are not hidden > or confused with other Dillo warnings. > > Secondly, this approach causes some problems. I am approaching this from the > perspective of the https filter dpi, but I assume that the same problem would > apply to any other related dpi. > > Firstly, a filter dpi runs in its own process for each call, not as a server. > Thus every time a call is made to the https filter dpi, it runs in its > entirety. This makes it difficult to handle a response from the user because > the dpi is then required to write a web server capable of at the very least > parsing http GET requests, which means opening up a socket and so forth. > Needless to say, handling that is somewhat of a challenge from a filter dpi > perspective. > > Secondly, for the https application, cookie/post/get datais likely to be > sent, which means that any rerequest would have to be able to pass that data > on exactly. > > Third, the https verification needs to be done after the ssl session is > estabilshed, but before the http request is made (for security reasons). > Thus any complicated scheme could result in multiple connections being made. > > Fourthly, I don't like it. That's the most important one of all :-) It's important to notice that coding the https dpi as a server (instead of a filter) has some advantages. BTW, this is what we have in mind with Madis. A server https dpi can more easily manage session caching and certificate management (remembering, saving, loading, ...). A single instance that forks or launches threads to do the work while keeping a common central management. BTW, we agree that implementing and testing with a filter dpi before turning it into a server dpi is a good approach. > > The html prompt window isn't a bad idea, but causes a lot of coding headaches > on the dpi other end. But that's just my thought. If you think that an > html prompt window would work, I'd appreciate a modified "hello" filter dpi > as an example from which I could implement the required code. In this case we'll try the dialog window with dpip... I foresee this tasks (by my side): 1.- Merge the https into the CVS so you can sync from there. 2.- implement a dpip command to provide for a simple dialog. (so handle_certificate_problem() can be filled in). 3.- Polish the common API for developing dpis and adjust the dpi set to the new functions. 4.- Implement a dpip_build_command() function into the lib and make the dpi set use it. 5.- Merge my new patches for bookmarks, downloads, and interface inside dillo. 6.- Review the file dpi. I hope to have this done and uploaded by Friday (1 to 5). Now, only 1.- and 2.- constitute a bottle neck for https, so I'll try to push them first (hopefully by Wednesday). The idea is to remove the bottleneck so you can keep on working and testing the https dpi. Cheers Jorge.-

July 13, 2004

[Dillo-dev]0.8.2 - No PNG support, but config cound PNG available (attachment)

by Geek

Hi, I just compiled and installed 0.8.2 on my Debian stable and gave it a shakedown. It doesn't display PNG images. 0.8.1 and earlier, no problems. I have attached the config.log file Thanks for any assistance. -- Gregg t3h g33k http://geek.scorpiorising.ca

July 13, 2004

RE: [Dillo-dev]Plugin infrastructure

by Eric Gaudet

Dillo's html rendering capabilities are what we should use for advanced forms. We don't want to duplicate the form widgets into a native-gtk version like mozilla does with xul. The pageflow, the forms, images etc ought to be in html, even if it's a dpi serving them. Having a login/password modal box seems to be what people are used to, so I can see why we'd like to have that. I can imagine dpis other than https needing a login/password box, but I'm not sure I can imagine that for non-login purposes. In any case, anything more complicated than one string, one or two text boxes with lables (possibly hidden for passwords) and 1 or 2 buttons certainly belongs to a dedicated html page the dpi would build. I could live with an intermediate html login page for https or any other dpi myself. Best, EG > -----Original Message----- > From: dillo-dev-admin(a)auriga.wearlab.de > [mailto:dillo-dev-admin@auriga.wearlab.de] On Behalf Of > Garrett Kajmowicz > Sent: Monday, July 12, 2004 3:26 PM > To: dillo-dev(a)auriga.wearlab.de > Subject: Re: [Dillo-dev]Plugin infrastructure > > > I just came up with two other dialog box types we might need: > > A window with alterable caption/message text and either one > or two text boxes > with associated labels. One or both of the boxes should be > able to be set in > "password" mode. > > I'm not sure if that counts as one or two, so I'm inflating > my estimates to > look more impressive :-) > > - Garrett Kajmowicz > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-> bin/mailman/listinfo/dillo-dev > >

July 12, 2004

Re: [Dillo-dev]Plugin infrastructure

by Nicolas Pouillon

[Mon, 12 Jul 2004 09:33:55 -0400] Garrett Kajmowicz <gkajmowi(a)tbaytel.net> eut le bonheur d'écrire: > Something with the DPI instrastructure needs to be considered - what > to do if a plugin needs to prompt the user for some information. [...] In the discussions before introduction of dpi was the point UI could entierely be done using standart html, rendered by dillo itself. Maybe we could use this here. I would see two (new) dpi commands: -Pop a new dillo window (maybe with some args: modal, no toolbar, no addressbar..., set its size, url) -Make a window reload So dpi could make a window pop for asking anything about certificates, with a standart html form in it. It would allow to change window title (through <title>) and make the gui customisable for future needs, and even be portable for gtk->other toolkit change. I thought of the 'reload window' feature not directly for https, but for download dpi. This would allow us to update the status of current downloads; shown in a dedicated window, somewhat ala Firefox, but again, entierely in html. -- Nipo

July 12, 2004

Re: [Dillo-dev]Plugin infrastructure

by Garrett Kajmowicz

I just came up with two other dialog box types we might need: A window with alterable caption/message text and either one or two text boxes with associated labels. One or both of the boxes should be able to be set in "password" mode. I'm not sure if that counts as one or two, so I'm inflating my estimates to look more impressive :-) - Garrett Kajmowicz

July 12, 2004

Fwd: Re: [Dillo-dev]Plugin infrastructure

by Garrett Kajmowicz

> In the discussions before introduction of dpi was the point UI could > entierely be done using standart html, rendered by dillo itself. > > Maybe we could use this here. > > I would see two (new) dpi commands: > -Pop a new dillo window (maybe with some args: modal, no toolbar, no > addressbar..., set its size, url) > -Make a window reload > > So dpi could make a window pop for asking anything about certificates, > with a standart html form in it. It would allow to change window title > (through <title>) and make the gui customisable for future needs, and > even be portable for gtk->other toolkit change. > > I thought of the 'reload window' feature not directly for https, but for > download dpi. This would allow us to update the status of current > downloads; shown in a dedicated window, somewhat ala Firefox, but again, > entierely in html. That is very interesting, but causes two problems. First of all, from what I have seen , it looks like it would be difficult to implement modal dialog boxes. This is important for security warnings so that they are not hidden or confused with other Dillo warnings. Secondly, this approach causes some problems. I am approaching this from the perspective of the https filter dpi, but I assume that the same problem would apply to any other related dpi. Firstly, a filter dpi runs in its own process for each call, not as a server. Thus every time a call is made to the https filter dpi, it runs in its entirety. This makes it difficult to handle a response from the user because the dpi is then required to write a web server capable of at the very least parsing http GET requests, which means opening up a socket and so forth. Needless to say, handling that is somewhat of a challenge from a filter dpi perspective. Secondly, for the https application, cookie/post/get datais likely to be sent, which means that any rerequest would have to be able to pass that data on exactly. Third, the https verification needs to be done after the ssl session is estabilshed, but before the http request is made (for security reasons). Thus any complicated scheme could result in multiple connections being made. Fourthly, I don't like it. That's the most important one of all :-) The html prompt window isn't a bad idea, but causes a lot of coding headaches on the dpi other end. But that's just my thought. If you think that an html prompt window would work, I'd appreciate a modified "hello" filter dpi as an example from which I could implement the required code. Thanks for the feedback - Garrett Kajmowicz -------------------------------------------------------

July 12, 2004

Re: [Dillo-dev]Plugin infrastructure

by Garrett Kajmowicz

> In the https case, it seems we only need (by now) a yes/no > answer for a certificate that can't be verified. > > Please send me the list for all the question/generic dialogs > you foresee. > If we are going to allow dialogs we need to have something generic enough that developers will not feel straightjacketed, which concrete enough that it isn't a nightmare to implement. Ideally it will not be tied to the underlying widget library so that we can switch widget libraries(if need be) without having to rewrite plugins in the future. There are a few dialog types that I see as being useful. The first is the file save-as dialog. This might simplify some of the FTP code (I haven't looked at the core app side of things). Next, a generic dialog which supports a custom message, as well as customizable text on up to three buttons. Custom caption for the window is nice. I think we can assume that it's a modal dialog box. This will allow the programmer to deal with almost any situation needed. In the https example, consider the options of: trusting indefinitely, trusting for this connection only, or refusing the connection. That requires three buttons. The indefinite trust is required to deal with self-signed sites that we don't want to have to click "yes" to for every file. These are the two which come to mind immediately. I would avoid limiting the possabilities so that when we come up with something we had not anticipated we will not run into any problems. > The question dialog through dpip for continuing or aborting > over non-verifiable certificates, is the bottle-neck now. I'll > start coding it ASAP. Thanks. Please let me know what you are doing so that I can follow everything. This will make it easier for me to contribute. You noted that you had made some changes to what I sent you. Have you commited the changed to CVS? If so, I'll blow away my current tarball tree and pull everything down from CVS. If not, please let me know where you are going so I can adjust my development accordingly. Thanks. - Garrett Kajmowicz

July 12, 2004

[Dillo-dev]sparc success for 0.8.2

by Riccardo Mottola

Hey, I just wanted to report that the final release of dillo compiles and seems to work fine here on solaris 6 -Riccardo

July 12, 2004

Re: [Dillo-dev]Plugin infrastructure

by Jorge Arellano Cid

Hi Garret, I just finished reading the whole tarball you sent me. It's very interesting. I'm planning to make some modifications on it to provide a generic new API for sending data (I also have a new dpi for file:/, some fixes for buffering in the transfer for bookmarks, some changes to downloads, also to consider cookies and preferences). BTW, with bookmarks I had already changed the data sending routines to provide for streams and flushing. Something like: <q> int send_data_chunk(int OutFD, char *Data, size_t DataSize, int flush); int send_data_string(int OutFD, char *str, int flush); </q> that provides for better tunning from each dpi (e.g. the new bookmarks transfers also run quickly on the 2.6.x series of the linux kernel). The idea of grouping common functions into something like a dpi library was present from a long time ago. This is a good opportunity to start with it. :) I have to think a bit more about the API for data sending. The plan is to have it merged on CVS before Friday. On Mon, 12 Jul 2004, Garrett Kajmowicz wrote: > Something with the DPI instrastructure needs to be considered - what to do if > a plugin needs to prompt the user for some information. Yes, this was considered. ...and it is much like what you describe. > > The need for this first came about while developping the https plugin - there > needs to be a way to prompt the user in the event that the foreign system > isn't trusted. > > This can currently be done through the use of direct calls to Gtk (I assume), > but this is not the best result. It requires that everybody who needs to do > user prompting write their own dialogs. It creates additional dependancies > for the dpis. And it makes code upgrades more difficult - Should Dillo > switch to another toolkit in the future for whatever reason (perhaps Gtk2?), > all of the DPIs need to be rewritten. And in the event of multiple instances > of Dillo running, it becomes impossible to determine which instance the > prompt is for. Yes, those are the two possibilities: a) Dialogs through Dillo (using dpip). b) Native dialogs. Currently b) seems inadequate, but for graphical dpis, it's different (for instance the graphical downloads: it's simpler to add "cancel" buttons in the native window). In the case of https, a) looks better. > > My proposed solution to this problem is to create a new dpi command which is > used to prompt the user for what to do. It should allow (require/default?) > modal dialog boxes so that the prompt is associated with the Dillo instance > the plugin is using. > > I am suggesting that the dpi command be 'prompt_user'. There would be one > manditory field, 'type' which would indicate the type of prompt to use. > Example values might be 'dialog' or 'file_save'. These types would be > extensible. > > From there, additional tags would be allocated based on the type of prompt. > For example, a 'file_save' prompt might have a default_filename tag. A > 'dialog' would likely have a title, a message, and up to 3 button texts. > > In all cases, the responce should be a dpi message of type 'user_response' > with a 'response' tag holding the value of the user input. I'll have to search my archives. I'm sure I wrote something about this long ago... AFAIR, there was the "question dialog" with fixed alternatives, and things like that. In the https case, it seems we only need (by now) a yes/no answer for a certificate that can't be verified. Please send me the list for all the question/generic dialogs you foresee. > At least this is my proposal. I'd like some feedback on it, and especially > suggestions or better ideas. The question dialog through dpip for continuing or aborting over non-verifiable certificates, is the bottle-neck now. I'll start coding it ASAP. Of course it would be very helpful to know in advance the other possible dialogs. To design a good API, that is. Cheers Jorge.-

July 12, 2004

[Dillo-dev]Plugin infrastructure

by Garrett Kajmowicz

Something with the DPI instrastructure needs to be considered - what to do if a plugin needs to prompt the user for some information. The need for this first came about while developping the https plugin - there needs to be a way to prompt the user in the event that the foreign system isn't trusted. This can currently be done through the use of direct calls to Gtk (I assume), but this is not the best result. It requires that everybody who needs to do user prompting write their own dialogs. It creates additional dependancies for the dpis. And it makes code upgrades more difficult - Should Dillo switch to another toolkit in the future for whatever reason (perhaps Gtk2?), all of the DPIs need to be rewritten. And in the event of multiple instances of Dillo running, it becomes impossible to determine which instance the prompt is for. My proposed solution to this problem is to create a new dpi command which is used to prompt the user for what to do. It should allow (require/default?) modal dialog boxes so that the prompt is associated with the Dillo instance the plugin is using. I am suggesting that the dpi command be 'prompt_user'. There would be one manditory field, 'type' which would indicate the type of prompt to use. Example values might be 'dialog' or 'file_save'. These types would be extensible. From there, additional tags would be allocated based on the type of prompt. For example, a 'file_save' prompt might have a default_filename tag. A 'dialog' would likely have a title, a message, and up to 3 button texts. In all cases, the responce should be a dpi message of type 'user_response' with a 'response' tag holding the value of the user input. At least this is my proposal. I'd like some feedback on it, and especially suggestions or better ideas. - Garrett Kajmowicz

July 12, 2004

Re: [Dillo-dev]HTTPS

by Jorge Arellano Cid

On Sun, 11 Jul 2004, Garrett Kajmowicz wrote: > OK - I have created a preliminary HTTPS implementation using openssl. It > checks to see if a site certificate chain is valid. Unfortunately, I'm not > sure how to create a dialog to prompt the user, so the "ask the user" > function just returns continue. Should I use glib/gtk or some dpi > communication message? > > The totality of the dpi stuff I have done is about 15k or so. Please let me > know if you are interested Absolutely! I got so tired after managing everything to be on place for the last release, that decided to stay away from the computer for the weekend... Please excuse me, but receive our welcome anyway! > and I will email it to you post haste. Yes, it's very interesting and I surely want to give it a try. I'll resume my duties this monday. Cheers Jorge.-

July 12, 2004

[Dillo-dev]HTTPS

by Garrett Kajmowicz

OK - I have created a preliminary HTTPS implementation using openssl. It checks to see if a site certificate chain is valid. Unfortunately, I'm not sure how to create a dialog to prompt the user, so the "ask the user" function just returns continue. Should I use glib/gtk or some dpi communication message? The totality of the dpi stuff I have done is about 15k or so. Please let me know if you are interested and I will email it to you post haste. - Garrett Kajmowicz

July 11, 2004