comment #10:

> It does not compile with complex numbers. Did something change with 3.2 autoconf?

Correct me if I'm wrong, but it looks like this comment doesn't belong to this bug.

Hehe ;-) I knew it used ed, but not that it went through patch.

Hanno, I can't see how people compiling patch on their own or not should matter. As a distribution package maintainer, if there was a configure option to disable ed support completely, I would gladly use it, because I very much doubt our users need that feature, and I'd rather limit the attack surface. Each distribution can make a different choice depending on their user base. People use distributions, instead of building everything themselves, exactly so that we make decisions for them and they don't have to bother.

So I am very favorable to adding such a configure option. Actually I was going to suggest it too.

Ed-style format not being auto-detected was also something I wanted to suggest. Andreas, because something used to work before isn't not a good enough reason to never change it. Being secure is more important than being compatible in this case, in my opinion. Ed-style patches are very specific, so specific that I still have to see any in the wild. I would expect people who use that (if they exist) to know what they are doing and be fine with adjusting their calls for the benefit of the majority.

If you really don't want to disable auto-detection of ed-style patches by default then this could also be a configure option, that is, it would be a tristate instead of a boolean: ed-style patches supported and auto-detected, supported but not auto-detected, or not supported at all.

I'm not keen on having a configure option here, as realistically very few people will compile patch on their own.

I think there are different questions to answer here:

• Should ed use to restricted mode? I'd say yes, unless this breaks something. I don't think so, and thus this should be done (unconditionally, not as a configure or otherwise option).

• Should ed patches be autodetected by default? I think no, because they're hardly used in practice. Even with the fix in place I'd recommend applying the first patch that was attached here.

The patch in [123eaff] looks solid.  If I may summarise, the change it makes is to put the ed script in a temporary file and invoke `ed tmpname.ed`, so that scripts with syntax errors will cause ed to abort rather than heroically trying to soldier on, which is what led to it running unvalidated commands previously.

do_ed_script() / ed_get_command_letter() are quite strict in the ed commands they will allow.  With this patch in place I can't see any opportunity to subvert their validation.

That said, some distributors may want to add a further layer of defence (against unforseen injection opportunities, or future changes in ed/patch command parsing) by having patch invoke "ed -r".  Could this be supported with a configure option?

This has been assigned CVE-2018-1000156.