Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 87735 invoked from network); 10 Nov 2004 18:09:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 10 Nov 2004 18:09:54 -0000 Received: (qmail 60411 invoked by uid 500); 10 Nov 2004 18:09:26 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 60243 invoked by uid 500); 10 Nov 2004 18:09:24 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 60174 invoked by uid 99); 10 Nov 2004 18:09:22 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=NO_REAL_NAME X-Spam-Check-By: apache.org Received: from [192.18.33.10] (HELO exchange.sun.com) (192.18.33.10) by apache.org (qpsmtpd/0.28) with SMTP; Wed, 10 Nov 2004 10:09:22 -0800 Received: (qmail 24962 invoked by uid 50); 10 Nov 2004 18:09:19 -0000 Date: 10 Nov 2004 18:09:19 -0000 Message-ID: <20041110180919.24961.qmail@nagoya.betaversion.org> From: bugzilla@apache.org To: commons-dev@jakarta.apache.org Cc: Subject: DO NOT REPLY [Bug 32145] - use a secure delete if the file is written to the disk X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32145 use a secure delete if the file is written to the disk ------- Additional Comments From martinc@apache.org 2004-11-10 18:09 ------- People who care about security as you describe would be much better off not writing to the file system in the first place, or encrypting the files as they are written to disk. Either of these can be accomplished by implementing a custom FileItemFactory. Using a secure deletion mechanism still leaves the file wide open on the disk for the duration of its processing. That would be a half-hearted approach to security at best. Wouldn't implementing such a mechanism be more likely to lull people into a false sense of security? --------------------------------------------------------------------- To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-dev-help@jakarta.apache.org