From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id C73D21F66F; Sun, 8 Nov 2020 07:49:17 +0000 (UTC) Date: Sun, 8 Nov 2020 07:49:17 +0000 From: Eric Wong To: Leah Neukirchen Cc: meta@public-inbox.org Subject: [PATCH] wwwattach: set "Content-Disposition: attachment" Message-ID: <20201108074917.GA29704@dcvr> References: <87mtztx9sr.fsf@vuxu.org> <20201107203913.GA8294@dcvr> <87imagyap9.fsf@vuxu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87imagyap9.fsf@vuxu.org> List-Id: Leah Neukirchen wrote: > Eric Wong writes: > > 1) Image rendering libraries and complex graphics stacks increase > > attack surface. IIRC libpng/libjpeg have both had problems with > > malicious data in the past, and could be in the future. > > > > From what I can tell, text-only stacks seem barely capable of > > displaying text without arbitrary code execution. I'm not > > optimistic about something as complex as image rendering from > > untrusted sources. > > Well, that's what probably literally every other website on the web does. ;) Yes, but this project has never been about doing what others do :> > > The current practice of linkifying URLs poses that problem, > > too, but the public-inbox admin isn't responsible for hosting > > the content in those URLs, bringing us to... > > Yes, I don't want to inline the data but just display it on click. > It's the same as any other Mailman or Google Groups archive. OK, it seems possible to support optionally. I don't think it's a good default for Mailman given the risk. Of course Google has vast legal resources which we can't expect our users to have. > > 3) (Probably) risk to admins hosting public-inbox instances if > > there's illegal content. Right now, the data is still there, > > but having it less obviously visible probably helps reduce > > exposure when combined with 2). > > Notice that deep-linking this attachment (e.g. with ) > will already display the image, as it triggers content autodetection. Yikes, I did not know that!(*) It doesn't happen with dillo, though Firefox seems affected. (*) Because I never use out of concern for folks with slow and/or metered Internet access. > > I am not a lawyer, and laws vary wildly by jurisdiction; > > so I think it's prudent to err on the side of paranoia when > > dealing in untrusted data sources. > > > > That said, a patch + options to allow passing through certain > > content types for the server to pass through could be accepted. > > It needs to also require a secondary option visible to the client > > (via opt-in cookie or POST), to avoid surprising differences > > between differently-configured server instances. > > I think it would be more correct to send the real MIME type > and "Content-Disposition: attachment" (or "inline" then, when asked for). I think passing MIME type is too risky by default even with "Content-Disposition: attachment". Browsers can still auto-launch external programs on attachments, right? But C-D:a definitely seems needed, and below is a patch for it. > (However this does not prevent hotlinking either...) Right. I'd be much more comfortable if the default behavior was consistently "Save As..." and then have the user process it as a separate step (perhaps on an air-gapped machine). Care to test the following patch? It's also right where you or someone else would need to make changes to optionally enable MIME type pass through. Thanks. --------8<------- Subject: [PATCH] wwwattach: set "Content-Disposition: attachment" This prevents `body; + + # prevent deep-linking via : + push @{$res->[1]}, 'Content-Disposition', 'attachment'; } push @{$res->[1]}, 'Content-Length', bytes::length($part); $res->[2]->[0] = $part;