Re: [ftpext] draft-peterson-streamlined-ftp-command-extensions
" Ángel González " <keisial@gmail.com> Wed, 24 November 2010 20:35 UTC
Return-Path: <keisial@gmail.com>
X-Original-To: ftpext@core3.amsl.com
Delivered-To: ftpext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 539E728C13A for <ftpext@core3.amsl.com>; Wed, 24 Nov 2010 12:35:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_54=0.6, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaJ71zm5MRnl for <ftpext@core3.amsl.com>; Wed, 24 Nov 2010 12:35:45 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 7A17E28C149 for <ftpext@ietf.org>; Wed, 24 Nov 2010 12:35:44 -0800 (PST)
Received: by wwa36 with SMTP id 36so135308wwa.13 for <ftpext@ietf.org>; Wed, 24 Nov 2010 12:36:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=+f2qLN2C2USbUxMVnpK+qsR+S/rDF3eAYO9XcPci5H8=; b=bjb23/kS9xShY4PO8Tw/nBKi1Mmi0KFqrpkuCnNoGGEKyAhN83I90AhvzjuPmfnXge +oBsHAxtRAc80hja//O7cpTnYPNSUeN1uzqT2M6p3nmkIyI4EhO9OsL9B+zkpTWR22aU f3dmHh7B1KfZNDZaULJrXf8T5ck4TCN5EELVM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=FZwnGKp3MUgQY9pVo9sncoIM16+k8n2wVPQiUuRR9aE1/fdxCD4ReuyXw9j5b1U44u KqtPyL5THodzqLUd0/IzC2+uEv/Ci+W4NxCBmTx3FqYFLNhs5NAoNoWiy2V/xKkA/6Kz 2rem2W2CIwfye7KrtAcgcOOk4eugtXedk7jpg=
Received: by 10.216.161.147 with SMTP id w19mr8438765wek.88.1290631003383; Wed, 24 Nov 2010 12:36:43 -0800 (PST)
Received: from [192.168.1.26] (225.red-80-28-70.adsl.dynamic.ccgg.telefonica.net [80.28.70.225]) by mx.google.com with ESMTPS id x59sm3676029weq.14.2010.11.24.12.36.40 (version=SSLv3 cipher=RC4-MD5); Wed, 24 Nov 2010 12:36:41 -0800 (PST)
Message-ID: <4CED776A.5020609@gmail.com>
Date: Wed, 24 Nov 2010 21:36:58 +0100
From: Ángel González <keisial@gmail.com>
User-Agent: Thunderbird
MIME-Version: 1.0
To: "Mark P. Peterson" <mpp@rhinosoft.com>
References: <A5FC996C3C37DC4DA5076F1046B5674C442CE618@TK5EX14MBXC125.redmond.corp.microsoft.com> <4CEC5427.1070605@gmail.com> <24FEC9729BA54CC7B08C13D51785BB1F@rhinooffice.net>
In-Reply-To: <24FEC9729BA54CC7B08C13D51785BB1F@rhinooffice.net>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
Cc: ftpext@ietf.org
Subject: Re: [ftpext] draft-peterson-streamlined-ftp-command-extensions
X-BeenThere: ftpext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ftpext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ftpext>, <mailto:ftpext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ftpext>
List-Post: <mailto:ftpext@ietf.org>
List-Help: <mailto:ftpext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ftpext>, <mailto:ftpext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Nov 2010 20:35:46 -0000
Mark P. Peterson wrote: > Hi Ángel, > > RMDA > ------- >> If the folder being RMDAed is not deletable by the logged in user, the > server MAY -based both on its configuration and user credentials- > directly reject the command. On the other hand, if it deletes one file > (and can not rollback the operation), it must continue the whole subtree. > > I will add this to the document. > > THMB > ------- >> It should allow full MIME types, so an application/x-better-image-format could be used. > I cannot find a reason to disagree, so I agree that following a standard for > identifying the thumbnail type should be used. I could use your help here > clarifying my document. > >> I also prefer the OPTS syntax, since that would allow larger options and > extensions, such as:... > > I prefer specifying the parameters in the command for two primary reasons. > > 1) By requiring a client to use OPTS to specify output type and resolution > the client and server must exchange this information in a separate command. > Commands require a handshake and consequently some latency between the > server and client for the exchange. Depending on many different factors this > latency, even on a fast connection, can be noticeable. If the client wants different > sized images frequently, let's say for every thumbnail image, it would be > even more noticeable. The bandwidth required to specify 10 bytes or less as a > parameter to the command is trivial by comparison even on the slowest > connections. Sure, but why would the client want differently sized images frequently? I think the client would only need to state it once, perhaps with a change on window resize. The number of thumbnails on a typical case would be much larger. > 2) By requiring a client to use OPTS to identify the parameters, both the client > and the server must maintain the parameters for this command, more-or-less > as a state. I'm a big fan of keeping things very simple. There is a trade off here. Although it is tempting to not store anything at the server for this, I still consider that using OPTS is a better route. > 3) End-user support is easier when parameters are specified with the command. > When end-users or customers have problems they'll often provide a portion of a > log to identify what is going on with the communication between the server and > client. Technicians analyzing the log may not have all of the required information > regarding the THMB command. With the parameters being issued with the > command analysis is far simpler and accurate. The server could repeat the options in the 150 response if it is deemed needed for user support. >> There should be a note about the potential security issues of the THMB > command. Vulnerabilities processing images are common. > > Could you give me some examples or how you would like to see this worded > and where you would like to see this placed in the document? Doing a bit of googling for image vulnerabilities: http://en.wikipedia.org/wiki/Windows_Metafile_vulnerability http://blogs.techrepublic.com.com/itdojo/?p=892 http://www.sophos.com/pressoffice/news/articles/2004/09/va_critical16sep04.html http://www.kb.cert.org/vuls/id/680620 http://www.kb.cert.org/vuls/id/238678 http://www.libpng.org/pub/png/libpng.html http://secunia.com/advisories/27213/ http://hypersecurity.blogspot.com/2010/03/cve-2010-0188-adobe-reader-tiff.html Vulnerabilities in image processing are quite bad, because it is easy to make a client render an image.THMB adds image rendering to ftp servers, which have a great exposure to the public. These vulnerabilities often allow arbitrary code execution, but even a DoS would be bad for a ftp server. Most importantly, an attacker must not be able to get LocalSystem/root access on a server by just uploading a malicious image. Not even if the fault lies on some OS-provided library used for the thumbnailing. I suppose the appropiate section is the security one, with a note to it from THMB. I don't know if it should be introduced by noting how thumbnailing adds a significant amount of code and how image vulnerabilities appear from time to time. The main piece could be similar to this: > Server implementations should be prepared in advance to mitigate > vulnerabilities in > the libraries used for thumbnailing. Servers are encouraged to perform > all thumbnailing > operations in a low-privilege process isolated from the server one. Best regards
- [ftpext] draft-peterson-streamlined-ftp-command-e… Mark P. Peterson
- Re: [ftpext] draft-peterson-streamlined-ftp-comma… Anthony Bryan
- [ftpext] draft-peterson-streamlined-ftp-command-e… Robert McMurray
- Re: [ftpext] draft-peterson-streamlined-ftp-comma… Mark P. Peterson
- Re: [ftpext] draft-peterson-streamlined-ftp-comma… Damin
- Re: [ftpext] draft-peterson-streamlined-ftp-comma… Mark P. Peterson
- Re: [ftpext] draft-peterson-streamlined-ftp-comma… William F. Maton
- Re: [ftpext] draft-peterson-streamlined-ftp-comma… Mat Berchtold
- Re: [ftpext] draft-peterson-streamlined-ftp-comma… Mark P. Peterson
- Re: [ftpext] draft-peterson-streamlined-ftp-comma… Mark P. Peterson
- Re: [ftpext] draft-peterson-streamlined-ftp-comma… Paul Ford-Hutchinson
- Re: [ftpext] draft-peterson-streamlined-ftp-comma… Mark P. Peterson
- Re: [ftpext] draft-peterson-streamlined-ftp-comma… Paul Ford-Hutchinson
- Re: [ftpext] draft-peterson-streamlined-ftp-comma… Ángel González
- Re: [ftpext] draft-peterson-streamlined-ftp-comma… Robert McMurray
- Re: [ftpext] draft-peterson-streamlined-ftp-comma… Damin
- Re: [ftpext] draft-peterson-streamlined-ftp-comma… Mark P. Peterson
- Re: [ftpext] draft-peterson-streamlined-ftp-comma… Mark P. Peterson
- Re: [ftpext] draft-peterson-streamlined-ftp-comma… Mark P. Peterson
- Re: [ftpext] draft-peterson-streamlined-ftp-comma… Ángel González
- Re: [ftpext] draft-peterson-streamlined-ftp-comma… Ángel González
- [ftpext] draft-peterson-streamlined-ftp-command-e… Tatsuhiro Tsujikawa
- Re: [ftpext] draft-peterson-streamlined-ftp-comma… Mark P. Peterson
- Re: [ftpext] draft-peterson-streamlined-ftp-comma… Daniel Stenberg
- Re: [ftpext] draft-peterson-streamlined-ftp-comma… Mark P. Peterson