Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Subject: Re: Proposal: new fsfs.conf properties
To: dev@subversion.apache.org
References: <CA+298Uhy6TvBJ9hF=BCvViiyAQbgkj4Zwe-0DfCM3=zZL-r_6g@mail.gmail.com>
 <CAEyhmwYka2O6BaBbtmce-ELuPek5t3mcwjc0JsMfb7z5eR5+kw@mail.gmail.com>
 <727D8E16AE957149B447FE368139F2B5A9023507@SERVER10>
 <CA+298UhPVgFn9rAaj8zoh54_m3G4irVwPjXiGmHtVm0KPcaDaw@mail.gmail.com>
 <727D8E16AE957149B447FE368139F2B5A9023540@SERVER10>
 <8ea18364-3d34-4d99-2d5e-e4169ee31542@apache.org>
 <20170711205035.GG58742@jessup.stsp.name>
 <9c674b4e-8529-c34e-a351-824dc60c894c@apache.org>
From: =?UTF-8?Q?Branko_=c4=8cibej?= <brane@apache.org>
Organization: The Apache Software Foundation
Message-ID: <19f79f97-37df-a096-f6d5-fd3cce9ac01b@apache.org>
Date: Wed, 12 Jul 2017 12:17:06 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0)
 Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <9c674b4e-8529-c34e-a351-824dc60c894c@apache.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
archived-at: Wed, 12 Jul 2017 10:16:57 -0000

On 12.07.2017 12:09, Branko Čibej wrote:
> On 11.07.2017 22:50, Stefan Sperling wrote:
>> On Tue, Jul 11, 2017 at 09:11:58PM +0200, Branko Čibej wrote:
>>> Another issue I have with the proposal is the idea to use file suffixes.
>>> That's usually the wrong way to go about things (case in point: Windows
>>> does it, with didastrous results). It's much better to determine file
>>> format by inspection, such as, e.g., libmagic does. We already have
>>> optional support for libmagic in the client (to set svn:mime-type).
>> I would not feel comfortable having the server parse arbitrary data with
>> libmagic. The libmagic code is not very safe to run on untrusted input.
>> I have seen libmagic crash my svn client on several occasions even on
>> text files I wrote.
>>
>> At the client side it's a bit less dangerous because users have already
>> told svn to add the files in question to version control, and a libmagic
>> exploit running on the client machine can do less harm than a server-side one.
>>
>> Granted, commits are usually authenticated. If we did this we should at
>> least make really sure that no unauthenticated access can trigger this code.
>> Ideally, it would be sandboxed somehow if we started using it on the server.
> I wasn't really proposing to use libmagic on the server. My point is
> that instead of using file name suffixes (which the compression and
> deltification code don't know about), we'd do some sort of inspection
> instead. Detecting ZIP files, or gzip/bzip2/xz-compressed files, etc.,
> is fairly easy just from looking at a few bytes of headers. Same goes
> for most image and video formats.
>
> Of course, one could always concoct a file that would trick such
> inspection, but at least that's marginally harder to do than commit a
> large text file full of spaces and calling it 'spaceinvaders.jpg'. :)
>
> Random binary data is harder to detect, but we already deal with that
> after the fact by using the plain text if the delta is too large.

Oh and another thing: I'd prefer to _not_ make such a feature
configurable with yet another knob. We have too many knobs ... either
make it safe to use and always-on, or forget about it. IMO.

-- Brane