* Rant - Emacs mail is not user friendly [not found] <emacs-mail-is-unusable-0> @ 2014-11-15 11:46 ` Stephen J. Turnbull 2014-11-16 12:18 ` Kelly Dean 0 siblings, 1 reply; 22+ messages in thread From: Stephen J. Turnbull @ 2014-11-15 11:46 UTC (permalink / raw) To: Kelly Dean; +Cc: emacs-devel Kelly Dean writes: > Even the worst webmail service I've ever used was more > user-friendly than this, Except that webmail doesn't provide access to configure the message submission process the way feedmail does. And even hackers mostly don't use feedmail. I understand your frustration, but I don't think the source is Emacs. It's that Internet mail is insanely complicated (and powerful to match). You are trying to manually implement some of the complexity that is normally hidden inside the MUA and MTA. In particular, mail queuing is about as complex as things get. MUAs normally delegate queuing to the MTA (that's how I handle disconnected operation on my laptop, for example, and that's the *only* reason I run Postfix on my laptop), and in that sense feedmail.el is a hack. > Yesterday I decided to try using Emacs for email. For sending > messages to my mail server, I'll use a separate program, I'm sure you have good reason for doing that, but that is a very unusual use case. All Emacs MUAs are highly configurable so that they can submit directly to servers (except maybe MH-E, which delegates that function to MH IIRC), and much effort goes into getting that right. The idea of depending a on program that processes a shared queue directory doesn't get the same attention (to say the least). > so I need Emacs just for composing messages, inserting headers > including autogenerated Date and Message-ID headers, encoding file > attachments, and moving completed messages from my drafts folder to > my outbound queue. And you chose Emacs[sic] over which other MUAs capable of being configured to do this? By [sic] I mean that Emacs, in fact, is not an MUA. Rather, it supports at least 5 major ones written in Lisp, plus MH-E which is an Emacs front-end to the MH family of text-based MUAs. To understand the operation of feedmail (or at least the description in the comments in the library) and the baroque suite of interface/configuration variables, it helps to be aware of that background. One issue you seem to have misunderstood is that feedmail.el's queuing feature does *not* seem to be designed for your use case, where the queue will be processed by an external program. Rather, I read the notes to assume that feedmail.el intercepts the message by inserting itself into the send-mail-function hook, then later *reads the queued message into a buffer*, where it invokes the normal function on the message in the queue at user request. That is, the queue is intended to be private to feedmail. That mode of operation could contribute to explaining several of the anomolies you observe (eg, the presence of the header/body separator in the queued message). Bottom line: I think the task you were trying to accomplish is far more complex that you are admitting, and has little to do with "user friendliness" of Emacs MUAs. Regards, ^ permalink raw reply [flat|nested] 22+ messages in thread
* Rant - Emacs mail is not user friendly 2014-11-15 11:46 ` Rant - Emacs mail is not user friendly Stephen J. Turnbull @ 2014-11-16 12:18 ` Kelly Dean 2014-11-16 17:49 ` David Caldwell ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Kelly Dean @ 2014-11-16 12:18 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: emacs-devel > In particular, mail > queuing is about as complex as things get. MUAs normally delegate > queuing to the MTA (that's how I handle disconnected operation on my > laptop, for example, and that's the *only* reason I run Postfix on my > laptop), and in that sense feedmail.el is a hack. It doesn't seem very complex, at least on the user side of things. You might want to consider msmtp instead of Postfix on your laptop. > I'm sure you have good reason for doing that, Yes. Emacs on my machine doesn't have Internet access. > but that is a very unusual use case. I certainly hope not! The usual case is that a person's instance of Emacs has access to his data (otherwise, Emacs wouldn't be very useful); if my use case is unusual, that means the usual case is that his Emacs has access not only to his data, but also to the Internet. With a program like Emacs serving as a bridge, that means his data isn't his data, but instead belongs to some Russian or Chinese hacker, whoever crosses the bridge first, and the original owner is permitted to retain a copy of the data just due to the hacker's mercifulness, or maybe just as bait so the hacker can get even more data later. The years when normal people weren't targets are long gone. > Bottom line: I think the task you were trying to accomplish is far > more complex that you are admitting, and has little to do with "user > friendliness" of Emacs MUAs. My previous, manual workflow was: 0. Compose a message in Emacs, note a subject and recipient, and note any files to attach. 1. Log in to webmail, and click ‟compose message”. 2. Copy the message, subject, and recipient from Emacs to the web browser, and attach the noted files. 3. Click ‟send”. 4. Save the message in Emacs to my file of sent messages (in anticipation of the webmail service's betrayal). That was inconvenient, so I decided a better workflow would be: 0. Compose a message in Emacs in standard format, with Subject and To headers separated from the body by a blank line. 1. Add the From, Date, and Message-ID headers. 2. Save the message to a file foo in an outbox directory. 3. Run ⌜msmtp -t < outbox/foo⌝ 4. If #3 succeeds, then run ⌜mv outbox/foo sent/foo⌝ The Emacs mail-sending functionality I wanted was simply automation of steps #1 (plus let me attach files) and #2 of the better workflow, without also doing steps #3 and #4. That's hardly complex, and in fact is simply _omission_ of the last two steps that MUAs ordinarily do (or equivalents thereof). I looked in the Emacs manual, and it said Emacs can do what I wanted, and said to read feedmail.el to learn how. Nowhere did the manual warn ‟Here be dragons”; had I known to avoid feedmail, that would have saved me the day that I wasted on it. For me, Emacs assists with step #0 except that the ⌜--text follows this line--⌝ is left in, it automates step #1 except that the Message-ID is broken, and it automates step #2 except that it leaves the draft in place after queuing the message. I eventually figured out that I don't need feedmail at all. The broken Message-ID is just because Emacs (in message.el; not feedmail's fault) rejects my ‟localhost” hostname (the machine has no network connection, so it needs no hostname), and the other things are fixable with just a few lines: (defun delete-mail-header-separator () "Delete `mail-header-separator'. This function copied from top of `message-send-mail-partially' in Emacs's message.el." (goto-char (point-min)) (re-search-forward (concat "^" (regexp-quote mail-header-separator) "\n")) (replace-match "\n")) (defcustom message-outbox-directory (file-name-as-directory (expand-file-name "outbox" message-directory)) :type 'directory) ; mv-rename copied from http://code.activestate.com/recipes/578116-move-files-with-rename-if-required/ (defun queue-message-to-outbox () (let ((filename (expand-file-name "out.mail" message-outbox-directory))) (delete-mail-header-separator) (write-file filename) (shell-command (concat "mv-rename " filename " " message-outbox-directory)))) (defun discard-draft () (delete-file (buffer-file-name))) (setq message-send-mail-function 'queue-message-to-outbox) (add-hook 'message-sent-hook 'discard-draft) Also I had to add ⌜(pushnew '(utf-8 . 8bit) mm-body-charset-encoding-alist)⌝ to my init file to make Emacs stop mangling the text. (Yes I know, the mangling is intended as a preemptive surrender to the administrators of broken MTAs that used to dominate the Internet, but those seem to have been mostly vanquished now. At least my messages appear to be getting to the mailing list with no problem.) And Emacs doesn't like it if I open sent/foo that has the ⌜--text follows this line--⌝ deleted and switch to message-mode and try to resend it, so I have to put that back in this case. I don't know what the point of it is, but it's a minor inconvenience and I've already wasted enough time on Emacs email, so I'll live with it. Last problem that I do care about is that Emacs keeps inserting line breaks after 72 characters, so I have to switch out of message-mode or copy/paste from another buffer to make it stop doing that because I can't find the setting to turn it off. Why is it turned on by default? Modern email readers do have word-wrap, after all. Even Emacs. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Rant - Emacs mail is not user friendly 2014-11-16 12:18 ` Kelly Dean @ 2014-11-16 17:49 ` David Caldwell 2014-11-16 22:52 ` Stephen Berman 2014-11-16 23:22 ` Stephen J. Turnbull 2 siblings, 0 replies; 22+ messages in thread From: David Caldwell @ 2014-11-16 17:49 UTC (permalink / raw) To: Kelly Dean; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 1282 bytes --] On 11/16/14 4:18 AM, Kelly Dean wrote: > Last problem that I do care about is that Emacs keeps inserting line > breaks after 72 characters, so I have to switch out of message-mode > or copy/paste from another buffer to make it stop doing that because > I can't find the setting to turn it off. Looks like it runs "auto-fill-mode". You can turn it off, or you can adjust the column that it wraps with the "fill-column" variable. > Why is it turned on by default? Modern email readers do have > word-wrap, after all. Even Emacs. Probably because of tradition. It's generally considered polite to wrap your column somewhere between 72 to 78. The SMTP spec (RFC 821) says: > The maximum total length of a text line including the <CRLF> is 1000 > characters (but not counting the leading dot duplicated for > transparency). So there is a maximum, though it's about a 13 line paragraph (wrapped at 72). Many email clients (including Thunderbird, which I'm using) use the quotable-printable encoding to encode longer lines (which escapes the line with an "=" if it's not meant to end). I guess this idea is to make the raw text mostly readable but still unwrappable. I think it's quite ugly, but it appears to be a pretty universal standard. -David [-- Attachment #2: S/MIME Cryptographic Signature --] [-- Type: application/pkcs7-signature, Size: 4219 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Rant - Emacs mail is not user friendly 2014-11-16 12:18 ` Kelly Dean 2014-11-16 17:49 ` David Caldwell @ 2014-11-16 22:52 ` Stephen Berman 2014-11-17 9:48 ` Kelly Dean 2014-11-16 23:22 ` Stephen J. Turnbull 2 siblings, 1 reply; 22+ messages in thread From: Stephen Berman @ 2014-11-16 22:52 UTC (permalink / raw) To: Kelly Dean; +Cc: emacs-devel On Sun, 16 Nov 2014 12:18:41 +0000 "Kelly Dean" <kelly@prtime.org> wrote: > Last problem that I do care about is that Emacs keeps inserting line > breaks after 72 characters, so I have to switch out of message-mode or > copy/paste from another buffer to make it stop doing that because I > can't find the setting to turn it off. Why is it turned on by default? > Modern email readers do have word-wrap, after all. Even Emacs. Does customizing message-fill-column do what you want? (If you have a message-mode buffer when you change the value, it seems you have to kill the buffer and open it afresh to get the effect.) Steve Berman ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Rant - Emacs mail is not user friendly 2014-11-16 22:52 ` Stephen Berman @ 2014-11-17 9:48 ` Kelly Dean 0 siblings, 0 replies; 22+ messages in thread From: Kelly Dean @ 2014-11-17 9:48 UTC (permalink / raw) To: Stephen Berman; +Cc: emacs-devel Stephen Berman wrote: >> Last problem that I do care about is that Emacs keeps inserting line >> breaks after 72 characters, so I have to switch out of message-mode or >> copy/paste from another buffer to make it stop doing that because I >> can't find the setting to turn it off. Why is it turned on by default? >> Modern email readers do have word-wrap, after all. Even Emacs. > > Does customizing message-fill-column do what you want? Yes, thanks, and David Caldwell pointed out that I can just disable auto-fill-mode. I remember reading about Emacs's hard-wrap ‟filling” feature a couple years ago, but I knew it was a feature I'd never want to use, so I ignored it and forgot what it was called. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Rant - Emacs mail is not user friendly 2014-11-16 12:18 ` Kelly Dean 2014-11-16 17:49 ` David Caldwell 2014-11-16 22:52 ` Stephen Berman @ 2014-11-16 23:22 ` Stephen J. Turnbull 2014-11-17 10:06 ` Kelly Dean 2014-11-17 19:54 ` Richard Stallman 2 siblings, 2 replies; 22+ messages in thread From: Stephen J. Turnbull @ 2014-11-16 23:22 UTC (permalink / raw) To: Kelly Dean; +Cc: emacs-devel Kelly Dean writes: > > In particular, mail > > queuing is about as complex as things get. MUAs normally delegate > > queuing to the MTA (that's how I handle disconnected operation on my > > laptop, for example, and that's the *only* reason I run Postfix on my > > laptop), and in that sense feedmail.el is a hack. > It doesn't seem very complex, at least on the user side of > things. Of course the user doesn't perceive the complexity! It's hidden in the abstractions of "MUA" and "MTA". You're breaking the abstraction by taking on the queuing function of the MTA outside of an MTA. > You might want to consider msmtp instead of Postfix on your laptop. Anything is possible. But why in the world would I want to do that? On the one hand, Postfix was near zero effort to install and configure, and on the other, no problems since. Furthermore, I use it on several other machines, besides needing to be able to support it when Mailman site admins ask questions about Mailman/Postfix configurations. My laptop certainly can spare the cycles. > > I'm sure you have good reason for doing that, > Yes. Emacs on my machine doesn't have Internet access. I don't care about your reason, that's what I said. I only care about what you did, which I have reason to believe was asking for exactly the kind of trouble you experienced. > > but that is a very unusual use case. > I certainly hope not! The usual case is that a person's instance of > Emacs has access to his data (otherwise, Emacs wouldn't be very > useful); if my use case is unusual, that means the usual case is > that his Emacs has access not only to his data, but also to the > Internet. Indeed, it does. That is the usual case, no matter what you hope. You don't have to like it, but it nevertheless informs the design of programs like feedmail. > With a program like Emacs serving as a bridge, that means > his data isn't his data, but instead belongs to some Russian or > Chinese hacker, whoever crosses the bridge first, and the original > owner is permitted to retain a copy of the data just due to the > hacker's mercifulness, or maybe just as bait so the hacker can get > even more data later. The years when normal people weren't targets > are long gone. You have evidence for Emacs being used in that way by crackers? (I agree with you that Emacs that has an attack surface that amounts to the whole world, and practically, that securing it is too hard to think about succeeding, but that's not a popular view on this list. And it's just theory.) > > Bottom line: I think the task you were trying to accomplish is far > > more complex that you are admitting, and has little to do with "user > > friendliness" of Emacs MUAs. > My previous, manual workflow was: Indeed. *Your* *manual* workflow, *mediated by two very complex programs*, the webmail program and the MTA behind it, which have a traditional and well-defined, but fundamentally arbitrary division of labor -- which you are not respecting in your redesigned workflow. Similarly with message-mode and the send-mail module in Emacs. > That was inconvenient, so I decided a better workflow would be: > 0. Compose a message in Emacs in standard format, with Subject and To headers separated from the body by a blank line. > 1. Add the From, Date, and Message-ID headers. > 2. Save the message to a file foo in an outbox directory. > 3. Run ⌜msmtp -t < outbox/foo⌝ > 4. If #3 succeeds, then run ⌜mv outbox/foo sent/foo⌝ An excellent analysis, indeed. So why did you choose an excessively complex program apparently designed for a different workflow, aka feedmail.el, to do step 2? Just save the message using write-file, with a little extra Lisp to construct an appropriate queuefile name and to remove MUA artifacts like the header delimiter line. Add a tiny shell function to do 3 and 4. This amount of Lisp would probably cost less keystrokes and thinking overall, although a bit more design, than configuring feedmail. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Rant - Emacs mail is not user friendly 2014-11-16 23:22 ` Stephen J. Turnbull @ 2014-11-17 10:06 ` Kelly Dean 2014-11-17 13:59 ` Ted Zlatanov 2014-11-17 19:54 ` Richard Stallman 1 sibling, 1 reply; 22+ messages in thread From: Kelly Dean @ 2014-11-17 10:06 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: emacs-devel Stephen J. Turnbull wrote: > You have evidence for Emacs being used in that way by crackers? No. > agree with you that Emacs that has an attack surface that amounts to > the whole world, and practically, that securing it is too hard to > think about succeeding, but that's not a popular view on this list. Securing Emacs isn't necessary. Just don't connect it to an untrusted network, and don't use it to interpret any untrusted data much more complex than plain text. This doesn't unreasonably limit its functionality; mail delivery can still be done using a separate program that only has access to an outbox directory that Emacs writes to, mail receipt can still be done using a separate program that only has access to an inbox directory that Emacs reads from, web browser bookmark and workspace management can be done in Emacs by just feeding URLs and commands to a browser running in a separate virtual machine that does have Internet access, etc. > An excellent analysis, indeed. So why did you choose an excessively > complex program apparently designed for a different workflow, aka > feedmail.el, to do step 2? Because I thought feedmail was responsible for everything that happens when I tell Emacs to send a message, including adding headers and encoding attachments and making the message ready for sending to an SMTP server, leaving just steps #3 and #4 for me to do separately. So I went to set up it, and it became progressively more frustrating until it goaded me into rant-spamming emacs-devel, though my lack of sleep and overconsumption of pumpkin pie may have had some influence too. Then I discovered that the headers are added and attachments are encoded before the message gets to feedmail, so I gladly dumped feedmail and just wrote a bit of glue to delete the mail-header-separator, save the message to my outbox, and delete the draft. > Just save the message using write-file, > with a little extra Lisp to construct an appropriate queuefile name > and to remove MUA artifacts like the header delimiter line. Add a > tiny shell function to do 3 and 4. This amount of Lisp would probably > cost less keystrokes and thinking overall, although a bit more design, > than configuring feedmail. Er, yes, that's exactly what I did, and I included the code in my message that you just replied to. My request to the Emacs devs about this now just is: please banish feedmail from mention in the manual, or at least add a ‟here be dragons” warning. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Rant - Emacs mail is not user friendly 2014-11-17 10:06 ` Kelly Dean @ 2014-11-17 13:59 ` Ted Zlatanov 0 siblings, 0 replies; 22+ messages in thread From: Ted Zlatanov @ 2014-11-17 13:59 UTC (permalink / raw) To: emacs-devel On Mon, 17 Nov 2014 10:06:35 +0000 "Kelly Dean" <kelly@prtime.org> wrote: KD> Securing Emacs isn't necessary. Just don't connect it to an untrusted KD> network, and don't use it to interpret any untrusted data much more KD> complex than plain text. You realize this is completely unrealistic in today's computing world? Ted ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Rant - Emacs mail is not user friendly 2014-11-16 23:22 ` Stephen J. Turnbull 2014-11-17 10:06 ` Kelly Dean @ 2014-11-17 19:54 ` Richard Stallman 2014-11-18 5:30 ` Stephen J. Turnbull 1 sibling, 1 reply; 22+ messages in thread From: Richard Stallman @ 2014-11-17 19:54 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: kelly, emacs-devel [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > (I > agree with you that Emacs that has an attack surface that amounts to > the whole world, and practically, that securing it is too hard to > think about succeeding, but that's not a popular view on this list. > And it's just theory.) We have done substantial work to make Emacs secure against just visiting a malicious file. Has a specific flaw or bug been found? If so, what precisely? -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Rant - Emacs mail is not user friendly 2014-11-17 19:54 ` Richard Stallman @ 2014-11-18 5:30 ` Stephen J. Turnbull 2014-11-21 14:51 ` Richard Stallman ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Stephen J. Turnbull @ 2014-11-18 5:30 UTC (permalink / raw) To: rms; +Cc: kelly, emacs-devel Richard Stallman writes: > > (I agree with you that Emacs that has an attack surface that > > amounts to the whole world, and practically, that securing it > > is too hard to think about succeeding, but that's not a popular > > view on this list. And it's just theory.) > > We have done substantial work to make Emacs secure against just > visiting a malicious file. Yes. But Emacs nowadays depends on a large number of external libraries, many of which are known to have had security flaws. (Specifically, being able to crash a program is considered a security flaw, because crashes usually involve trying to execute unexecutable data -- but if that data happened to be valid machine code, "anything" can happen). Emacs is also capable of handling almost any data known to man "out of the box", which makes it a perfect instrument for "social engineering". Emacs users regularly share Lisp code, for example, including with people who don't know Lisp. I've done it myself, though nothing nastier than a time bomb that pops up "Happy Birthday!" on the victim's birthday. I could have had it mail me the contents of .ssh (and I have a pretty good idea of the individual's preferences in passphrases, and they are obviously short). > Has a specific flaw or bug been found? Aside from the application/x-patch MIME type used by Gnus, I know of none. That one's mostly pedantic, as AFAIK noone proposes to do what is implied by the "application" MIME type, namely, automatically apply the patch. (There's no good reason for diffs sent by mail to be anything but a "text" MIME type.) > If so, what precisely? As above. I don't expect you to agree, nor am I perfectly consistent in following the implications of the analysis. But I don't install Emacsen on machines storing other people's data unless they are isolated from the Internet, and I don't install them on servers I care about (I use TRAMP instead). ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Rant - Emacs mail is not user friendly 2014-11-18 5:30 ` Stephen J. Turnbull @ 2014-11-21 14:51 ` Richard Stallman 2014-11-21 16:07 ` Stefan Monnier 2014-11-22 5:40 ` Stephen J. Turnbull 2014-11-21 16:22 ` Emacs dependencies vs. security Ivan Shmakov 2014-12-19 17:22 ` application/x-patch MIME type used by Gnus? (was: Rant - Emacs mail is not user friendly) Reiner Steib 2 siblings, 2 replies; 22+ messages in thread From: Richard Stallman @ 2014-11-21 14:51 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: kelly, emacs-devel [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > Yes. But Emacs nowadays depends on a large number of external > libraries, many of which are known to have had security flaws. We need to get those problems fixed. I have recruited someone to make a JPG-validator that will thoroughly check for anything incorrect in a JPG file. We need to do this for all the formats. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Rant - Emacs mail is not user friendly 2014-11-21 14:51 ` Richard Stallman @ 2014-11-21 16:07 ` Stefan Monnier 2014-11-22 5:41 ` Stephen J. Turnbull 2014-11-22 11:08 ` Richard Stallman 2014-11-22 5:40 ` Stephen J. Turnbull 1 sibling, 2 replies; 22+ messages in thread From: Stefan Monnier @ 2014-11-21 16:07 UTC (permalink / raw) To: Richard Stallman; +Cc: Stephen J. Turnbull, kelly, emacs-devel > I have recruited someone to make a JPG-validator that will > thoroughly check for anything incorrect in a JPG file. That's nice, but some security bugs strike even when faced with a correct/valid JPG file. What we need to validate is the libjpeg code, not the JPG files. Stefan ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Rant - Emacs mail is not user friendly 2014-11-21 16:07 ` Stefan Monnier @ 2014-11-22 5:41 ` Stephen J. Turnbull 2014-11-22 15:51 ` Stefan Monnier 2014-11-22 11:08 ` Richard Stallman 1 sibling, 1 reply; 22+ messages in thread From: Stephen J. Turnbull @ 2014-11-22 5:41 UTC (permalink / raw) To: Stefan Monnier; +Cc: kelly, Richard Stallman, emacs-devel Stefan Monnier writes: > That's nice, but some security bugs strike even when faced with > a correct/valid JPG file. What we need to validate is the libjpeg code, > not the JPG files. No, you need to validate both. If the input is invalid, anything can happen. Viz, X.org, whose libraries do no validation at all (and whose restrictions are typically undocumented)! ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Rant - Emacs mail is not user friendly 2014-11-22 5:41 ` Stephen J. Turnbull @ 2014-11-22 15:51 ` Stefan Monnier 2014-11-22 16:13 ` Stephen J. Turnbull 0 siblings, 1 reply; 22+ messages in thread From: Stefan Monnier @ 2014-11-22 15:51 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: kelly, Richard Stallman, emacs-devel >> That's nice, but some security bugs strike even when faced with >> a correct/valid JPG file. What we need to validate is the libjpeg code, >> not the JPG files. > No, you need to validate both. Depends on what you mean by "validate the code". In my line of work, a code is not validated if it can fail on some input. I.e. validation of the code includes checking that the code does the proper validation of the data it receives. Stefan ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Rant - Emacs mail is not user friendly 2014-11-22 15:51 ` Stefan Monnier @ 2014-11-22 16:13 ` Stephen J. Turnbull 0 siblings, 0 replies; 22+ messages in thread From: Stephen J. Turnbull @ 2014-11-22 16:13 UTC (permalink / raw) To: Stefan Monnier; +Cc: kelly, Richard Stallman, emacs-devel Stefan Monnier writes: > Depends on what you mean by "validate the code". In my line of work, > a code is not validated if it can fail on some input. I.e. validation > of the code includes checking that the code does the proper validation > of the data it receives. I was assuming you were talking about the validating the JPEG library code, because that is what you need to do to determine how much validation Emacs needs to do of data it's about to hand to libjpeg. The point of my X.org comment is that there is plenty of code out there that doesn't validate input well (and some that prides itself on not validating at all), so Emacs has to do some validation of data. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Rant - Emacs mail is not user friendly 2014-11-21 16:07 ` Stefan Monnier 2014-11-22 5:41 ` Stephen J. Turnbull @ 2014-11-22 11:08 ` Richard Stallman 2014-11-22 15:53 ` Stefan Monnier 1 sibling, 1 reply; 22+ messages in thread From: Richard Stallman @ 2014-11-22 11:08 UTC (permalink / raw) To: Stefan Monnier; +Cc: stephen, kelly, emacs-devel [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > That's nice, but some security bugs strike even when faced with > a correct/valid JPG file. Is this known to happen now, or is it a speculation, or what? -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Rant - Emacs mail is not user friendly 2014-11-22 11:08 ` Richard Stallman @ 2014-11-22 15:53 ` Stefan Monnier 0 siblings, 0 replies; 22+ messages in thread From: Stefan Monnier @ 2014-11-22 15:53 UTC (permalink / raw) To: Richard Stallman; +Cc: stephen, kelly, emacs-devel >> That's nice, but some security bugs strike even when faced with >> a correct/valid JPG file. > Is this known to happen now, or is it a speculation, or what? I don't keep track of specific security bugs nowadays, but just based on the size of the code, the fact that it's written in C and it's history, I don't think I'd take much risk to say that there is such a bug right now. Stefan ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Rant - Emacs mail is not user friendly 2014-11-21 14:51 ` Richard Stallman 2014-11-21 16:07 ` Stefan Monnier @ 2014-11-22 5:40 ` Stephen J. Turnbull 2014-11-22 11:09 ` Richard Stallman 1 sibling, 1 reply; 22+ messages in thread From: Stephen J. Turnbull @ 2014-11-22 5:40 UTC (permalink / raw) To: rms; +Cc: kelly, emacs-devel Richard Stallman writes: > > Yes. But Emacs nowadays depends on a large number of external > > libraries, many of which are known to have had security flaws. > > We need to get those problems fixed. You will never get all of those problems fixed; there's an unending supply of them, as new ones are being created every day. That means that in practice complex applications like Emacs are continuously vulnerable to some attack, although those attacks change over time. As somebody (probably Kelly) put it a few messages back, it's no longer the case that we ordinary users can consider ourselves safe just because there's millions of us. The botnets have millions of CPUs with which to seek out new victims in massively parallel fashion. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Rant - Emacs mail is not user friendly 2014-11-22 5:40 ` Stephen J. Turnbull @ 2014-11-22 11:09 ` Richard Stallman 0 siblings, 0 replies; 22+ messages in thread From: Richard Stallman @ 2014-11-22 11:09 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: kelly, emacs-devel [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > You will never get all of those problems fixed; there's an unending > supply of them, as new ones are being created every day. We still need to fix them. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Emacs dependencies vs. security 2014-11-18 5:30 ` Stephen J. Turnbull 2014-11-21 14:51 ` Richard Stallman @ 2014-11-21 16:22 ` Ivan Shmakov 2014-12-19 17:22 ` application/x-patch MIME type used by Gnus? (was: Rant - Emacs mail is not user friendly) Reiner Steib 2 siblings, 0 replies; 22+ messages in thread From: Ivan Shmakov @ 2014-11-21 16:22 UTC (permalink / raw) To: emacs-devel >>>>> Stephen J Turnbull <stephen@xemacs.org> writes: >>>>> Richard Stallman writes: >>> (I agree with you that Emacs that has an attack surface that >>> amounts to the whole world, and practically, that securing it is >>> too hard to think about succeeding, but that's not a popular view >>> on this list. And it's just theory.) >> We have done substantial work to make Emacs secure against just >> visiting a malicious file. > Yes. But Emacs nowadays depends on a large number of external > libraries, many of which are known to have had security flaws. Fortunately, most (if not all) of these libraries are entirely optional. FWIW, the build I use for Emacs development is linked against GnuTLS, libxml, the compression libraries (Libz, Liblzma), and what seems to be their respective dependencies (Glib, libgcrypt, libtasn1, etc.) […] -- FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A ^ permalink raw reply [flat|nested] 22+ messages in thread
* application/x-patch MIME type used by Gnus? (was: Rant - Emacs mail is not user friendly) 2014-11-18 5:30 ` Stephen J. Turnbull 2014-11-21 14:51 ` Richard Stallman 2014-11-21 16:22 ` Emacs dependencies vs. security Ivan Shmakov @ 2014-12-19 17:22 ` Reiner Steib 2014-12-19 20:01 ` Stephen J. Turnbull 2 siblings, 1 reply; 22+ messages in thread From: Reiner Steib @ 2014-12-19 17:22 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: rms, emacs-devel On Tue, Nov 18 2014, Stephen J. Turnbull wrote: > Richard Stallman writes: > > Has a specific flaw or bug been found? > > Aside from the application/x-patch MIME type used by Gnus, I know of > none. That one's mostly pedantic, as AFAIK noone proposes to do what > is implied by the "application" MIME type, namely, automatically apply > the patch. (There's no good reason for diffs sent by mail to be > anything but a "text" MIME type.) I cannot reproduce this. emacs -Q / M-x message-mail RET / C-c C-a /tmp/foo.patch RET results in type="text/x-diff" here. Maybe your /etc/mime.types specifies "application/x-patch"? The only match for "application/x-patch" in Gnus is this one, that only specifies the coding *if* the type is "application/x-patch": | grep -nH -e application/x-patch *.el | mm-encode.el:38: ("application/x-patch" qp-or-base64) Bye, Reiner. -- ,,, (o o) ---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* application/x-patch MIME type used by Gnus? (was: Rant - Emacs mail is not user friendly) 2014-12-19 17:22 ` application/x-patch MIME type used by Gnus? (was: Rant - Emacs mail is not user friendly) Reiner Steib @ 2014-12-19 20:01 ` Stephen J. Turnbull 0 siblings, 0 replies; 22+ messages in thread From: Stephen J. Turnbull @ 2014-12-19 20:01 UTC (permalink / raw) To: Reiner Steib; +Cc: rms, emacs-devel Reiner Steib writes: > I cannot reproduce this. > > emacs -Q / M-x message-mail RET / C-c C-a /tmp/foo.patch RET > results in type="text/x-diff" here. It might have been application/x-diff; it was a while back. > Maybe your /etc/mime.types specifies "application/x-patch"? Mine is irrelevant. These were patches received by Mailman at xemacs.org, which got stripped because we deny application/* MIME types. If Gnus has stopped doing that, I'm glad, but at the time people were trying to tell me that it's a good idea. ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2014-12-19 20:01 UTC | newest] Thread overview: 22+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <emacs-mail-is-unusable-0> 2014-11-15 11:46 ` Rant - Emacs mail is not user friendly Stephen J. Turnbull 2014-11-16 12:18 ` Kelly Dean 2014-11-16 17:49 ` David Caldwell 2014-11-16 22:52 ` Stephen Berman 2014-11-17 9:48 ` Kelly Dean 2014-11-16 23:22 ` Stephen J. Turnbull 2014-11-17 10:06 ` Kelly Dean 2014-11-17 13:59 ` Ted Zlatanov 2014-11-17 19:54 ` Richard Stallman 2014-11-18 5:30 ` Stephen J. Turnbull 2014-11-21 14:51 ` Richard Stallman 2014-11-21 16:07 ` Stefan Monnier 2014-11-22 5:41 ` Stephen J. Turnbull 2014-11-22 15:51 ` Stefan Monnier 2014-11-22 16:13 ` Stephen J. Turnbull 2014-11-22 11:08 ` Richard Stallman 2014-11-22 15:53 ` Stefan Monnier 2014-11-22 5:40 ` Stephen J. Turnbull 2014-11-22 11:09 ` Richard Stallman 2014-11-21 16:22 ` Emacs dependencies vs. security Ivan Shmakov 2014-12-19 17:22 ` application/x-patch MIME type used by Gnus? (was: Rant - Emacs mail is not user friendly) Reiner Steib 2014-12-19 20:01 ` Stephen J. Turnbull
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.