*** David Woolley ([EMAIL PROTECTED]) wrote in the Lynx list on Apr...: :) > Content-Transfer-Encoding: BASE64 :) ... :) > Content-Description: Patch for external support of mail program :) > Content-Disposition: ATTACHMENT; FILENAME="mail.patch" :) :) This patch looks like a security hole to me. You seem to be inserting :) uncontrolled text into a shell command using an interface that has no :) meta-character protection (you are relying on < going through OK).
Dear David, Thank you for looking at the patch. I will fix the uncontrolled sprintf, no problem. Good point. Does anyone know which are the functions in Lynx which allow me check for unescaped variables and so on. I would appreciate input. I am not relying on the use of "<", I am giving an example of something that works in my machine (and in many others), there are some other ways to make this work with Pine (not as clean as the one proposed, but it can be done for any system!). I would appreciate if someone told me how to do the same with mutt and elm. If you see the code, you will notice that the command to be executed is determined by the user, not by the patch, the patch just gives the user the parameters to the command to be executed, (To: field, tentative "Subject:" field and a file name containing the web page) nothing more. You are free to ignore them if you like (e.g. You can make the command to be executed a script, which only takes 2 parameters parameters, or removes the ">" at the beginning of the line and then hands it to your mailer, etc). Do you see my point? :) - most Unix email programs given a file on standard input are unable :) to read the console, so can only send it non-interactively; Yes, but again, you don't have to accept that parameter, for all you care, you can define your mailer to be: /path/to/script %s %s %s and script be #/bin/sh my_mail_program -subject "$2" $1 and do not use $3. So, this is not an issue in itself, it's a help if you can use, and can be discarded if not needed or is not possible to be used. That's the way the patch is supposed to help you. :) - Pine appears to have made an inappropriate choice of MIME encoding for :) this email; is it really that good a mailer? The answer to your first question is that is it using mime encoding as descibed in some RFC whose number escapes to me right now. RFC 15XX? :) (Also, I believe References in email should exclude the In-Reply-To :) article.) The standard is RFC 2822 (not RFC 822), and by reading it, I get the impression that it encourages both headers, since they contain information useful for contructing threads. The references header is not mandated (it says that it should be used). Finally, don't hold Pine responsible for that (I mean the Pine Team of couse). I made the modification to the source myself, so that if another person uses my modification, I will be able to see threads correctly, which is what I am after. In any case, my modification still makes Pine RFC compliant. If I recall correctly, Mutt, for example, uses the reference header, not the in-reply-to header, and that may be part of the confusion. I may be way off here though, I don't know for a fact (mutt users cas can tell me though). Thanks! -- Eduardo http://www.math.washington.edu/~chappa/pine/ ; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to [EMAIL PROTECTED]
