>On 2016/04/13 13:50, Frederic Cambus wrote: >> On Tue, Mar 29, 2016 at 04:32:40PM +0100, Stuart Henderson wrote: >> > I've run into a slight problem with the lynx pledging. If there's a >> > ~/.mailcap entry for a mimetype, lynx uses it to try and display the >> > file, for example I have >> > >> > application/pdf; mutt_bgrun mupdf '%s'; nametemplate=%s.pdf >> > >> > (mutt_bgrun is the old script from >> > http://www.spocom.com/users/gjohnson/mutt/mutt_bgrun) >> > so with this, following a link that ends up in a pdf results in lynx >> > being killed by pledge. >> > >> >> Indeed, I was able to reproduce the issue locally, and that's something >> I initially missed. It doesn't seem to be possible to disable this >> behavior using an hardcoded boolean like in the previous patches. >> >> What we could do is return early in the LYSystem function so that no >> external command is ever called. It's not perfect as in the case you >> mentioned, there is no error message reported and lynx doesn't offer >> to save the file on disk. > >I'd actually prefer the crash over this, because it shows clearly that >there is something we need to handle, and points to the area of code >that's needed. > >I didn't look at the code but might it be an option to just avoid >reading mailcap (pretend that the file doesn't exist) ..? > >> Here is a patch hardcoding 'no_editor = TRUE' before calling pledge >> so calling the editor is disabled with a proper error message > >That makes sense. > >In decreasing order of preference: > >- fallback behaviour (e.g. download for unhandled mime-types) >- nice error >- hard crash >- silently don't do what is supposed to happen
Let's start from the beginning. How do the lynx authors justify the risk of a coding error in the surrounding code? Keeping it simple, I bet it never even entered their thought process. How about a patch to REMOVE the behavior. Then submit it upstream, and simultaneously challenge the greater community to find a vuln related to this bizzare feature someone added eons ago? Eventually we must push back against software that does too-much, because too-much is very much related to unconsidered risk. A year ago when we were discussing removal of lynx from base we received comments from folk who considered it safe. Did they know about these mimetypes? Sorry, this "OpenBSD makes crap software safe" meme is so tiring.
