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

[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