Report from alan cox: When it scans the mailcap file to look for a helper mozilla seems to pull the app name but not any arguments from the mailcap file. Demo touch fred.smil echo "application/smil; gedit wombat %s" mozilla file:/wherever/fred.smil Run with - says gedit Up pops a gedit window - but wombat wansn't in the arguments. Unfortunately the same applies for "gv" and "gv -safer". For some setups plugger will save peoples backsides, but not for all.

reassign

helper apps aren't plugins (but we don't really have a good component for them), and this is probably bz's bug

cvs blame shows most of the mailcap code in exthandler/unix/nsOSHelperAppService.cpp is owned by bz, --->punting

Yep. This has been filed for a while now -- the api design prevents the Unix back end code from passing out command-line args and the 'gv -safer' example is precisely the one that's been raised in the relevant bug... Too bad the API problem got ignored by the owners of the relevant apis until very recently. I kept meaning to add a bunch of code to work around the broken apis, but recently I've been putting most of the time I have for this stuff into fixing the API instead... Oh, and see bug 57420 for the api issue... *** This bug has been marked as a duplicate of 83305 ***

bz, What's the security risk here? If there's a risk, bug 83305 should be marked confidential. If not, this one should be public.

The security issue is basically that we will run a helper app in a less secure mode than the user desired. In other words, not any more of a security risk than any helper app, imo.

No, it's a pretty major problem since some helper applications can be run in safer modes than the default. (gv is a good example.)

Yes, I agree it's a major problem because we're giving the user a false sense of security. I fail how that would be corrected by marking anything confidential.

can't we just release note that people should write wrapper scripts which handle this for the time being?

Dupe of public bug, clearing confidential flag