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=-2.5 required=3.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, UNPARSEABLE_RELAY shortcircuit=no autolearn=no autolearn_force=no version=3.4.2 Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 7C7E81F670 for ; Sun, 8 Nov 2020 00:05:45 +0000 (UTC) Received: by mail-wm1-f46.google.com with SMTP id s13so4677080wmh.4 for ; Sat, 07 Nov 2020 16:05:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=DB659e/y1/9rsyUIISEA19UVdTOUn+fmpQUlT1SpnAw=; b=KUke/wMP9kH2hMOqfKhYaI2kHp/+7pdpndKhZNAfaHa1NPYeeHuAUlQZz6Z9ldbBFF h9GrncPqzOwazDFiEnCiGW/80amcIsEgyqa6paRK0jsS/f98P/IXEs8hOgTeZneZM5r8 PoN3nNDuwphR3levm9KMbe53rHxS/FrrWbzoKaRF5kzyRMroW1rdrWdRbU5tEuFqzz/j m/A1q6RZMY+lyzpvGnoBRnPkrJOggIoY2esCV9sbrgsNMKbugjd6pnDXnUEwMvVGUehH aUXJizt050Sx7cCM29yMlimp4Tk9qxSAOUtXgtYMGO91u4qRZCbLfZ6p5O0ndR3Y+9BP ijjg== X-Gm-Message-State: AOAM530mYqo9NxSQStrV51r6UUgq9vUVEisq5+QvVhDMi9Bt8XUfJv4L JyWw74+P5sx1Ucpvo8xLzbs= X-Google-Smtp-Source: ABdhPJyCYG/OsYISdgZVUqRuecl/Obc7XSwmlfuNs632zdmnZuCPZxh9oTfcLfxnxbHUf9Mg9Mqj3A== X-Received: by 2002:a1c:7301:: with SMTP id d1mr6783511wmb.141.1604793943497; Sat, 07 Nov 2020 16:05:43 -0800 (PST) Received: from rhea.home.vuxu.org (dslb-188-104-100-194.188.104.pools.vodafone-ip.de. [188.104.100.194]) by smtp.gmail.com with ESMTPSA id f19sm7417125wml.21.2020.11.07.16.05.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 07 Nov 2020 16:05:42 -0800 (PST) Received: from localhost (rhea.home.vuxu.org [local]) by rhea.home.vuxu.org (OpenSMTPD) with ESMTPA id 6c9441d4; Sun, 8 Nov 2020 00:05:38 +0000 (UTC) From: Leah Neukirchen To: Eric Wong Cc: meta@public-inbox.org Subject: Re: MIME types for image attachments References: <87mtztx9sr.fsf@vuxu.org> <20201107203913.GA8294@dcvr> Date: Sun, 08 Nov 2020 01:05:38 +0100 In-Reply-To: <20201107203913.GA8294@dcvr> (Eric Wong's message of "Sat, 7 Nov 2020 20:39:14 +0000") Message-ID: <87imagyap9.fsf@vuxu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain List-Id: Eric Wong writes: > Leah Neukirchen wrote: >> Hi, >> >> I just noticed this on a plain public-inbox 1.6.0 installation: >> >> https://inbox.vuxu.org/9fans/8F5F1B4BCF0E2F1DA17BDFBF06430DC7@abbatoir.fios-router.home/T/#u >> > [-- Attachment #2: Type: image/png, Size: 56860 bytes --] >> >> However, when I click on it: >> >> % curl -I >> https://inbox.vuxu.org/9fans/8F5F1B4BCF0E2F1DA17BDFBF06430DC7@abbatoir.fios-router.home/2-a.bin >> HTTP/1.1 200 OK >> Server: nginx/1.18.0 >> Date: Sat, 07 Nov 2020 19:08:48 GMT >> Content-Type: application/octet-stream >> Content-Length: 56860 >> Connection: keep-alive >> >> Any reason this is not served as image/png? I don't think serving >> image/* types is particularily dangerous, and it easily allows looking >> at attached images from the browser. > > Several reasons off the top of my head (there may be more): > > 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. ;) > 2) Risk of illegal or objectionable content being viewed by > readers and bystanders, especially when in public (libraries, > coffee shops, planes, etc). The risk of accidental clicks > seems higher in public due to spills/bumps, too, especially > in unfamiliar environments. > > 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. > 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. > 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). (However this does not prevent hotlinking either...) > Risks will need to be documented for the admin, and the current > behavior needs to remain the default. -- Leah Neukirchen https://leahneukirchen.org