- Dillo-dev - lists.mailman3.com

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