Return-Path: Delivered-To: apmail-incubator-general-archive@www.apache.org Received: (qmail 26697 invoked from network); 24 Sep 2008 06:04:13 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 24 Sep 2008 06:04:13 -0000 Received: (qmail 79440 invoked by uid 500); 24 Sep 2008 06:04:08 -0000 Delivered-To: apmail-incubator-general-archive@incubator.apache.org Received: (qmail 79325 invoked by uid 500); 24 Sep 2008 06:04:08 -0000 Mailing-List: contact general-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: general@incubator.apache.org Delivered-To: mailing list general@incubator.apache.org Received: (qmail 79314 invoked by uid 99); 24 Sep 2008 06:04:08 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 Sep 2008 23:04:08 -0700 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_HELO_PASS,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [213.95.11.81] (HELO mail.intermeta.de) (213.95.11.81) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 24 Sep 2008 06:03:09 +0000 Received: from [192.168.1.69] (adsl-76-200-189-175.dsl.pltn13.sbcglobal.net [76.200.189.175]) (authenticated bits=0) by mail.intermeta.de (8.13.8/8.13.8) with ESMTP id m8O62XgK006721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Sep 2008 08:02:35 +0200 Subject: Re: status of PGP support in Maven From: Henning Schmiedehausen Reply-To: henning@apache.org To: general@incubator.apache.org In-Reply-To: References: <9e3862d80809150702y7492812coa2f8f0f1deb42970@mail.gmail.com> <1221697970.25066.26.camel@forge.local> <14976D4F-CEEB-41D7-B1AE-1A703E14462B@SUN.com> <5c902b9e0809191011u72e8b83arfd6e49c5fc202214@mail.gmail.com> <1221930522.25066.161.camel@forge.local> <1222233612.24030.99.camel@forge.local> Content-Type: text/plain Date: Tue, 23 Sep 2008 23:02:32 -0700 Message-Id: <1222236152.24030.125.camel@forge.local> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (mail.intermeta.de [192.168.2.3]); Wed, 24 Sep 2008 08:02:36 +0200 (CEST) X-INTERMETA-Spam-Score: (babsi.intermeta.de) -103.365 () AWL,BAYES_00,RDNS_DYNAMIC,USER_IN_WHITELIST X-Scanned-By: MIMEDefang 2.64 on 192.168.2.3 X-Virus-Checked: Checked by ClamAV on apache.org There is a pretty nice proposal on http://people.apache.org/~henkp/trust/, however this will again take a piece of "freedom of doing software at Apache" away and introduce some administrative overhead that all projects must implement and manage. Formalizing the signing of our releases would be a huge step towards a reliable validation for the Apache software releases. It still does not help you with third-party releases, though. I don't know how many artifacts are on repo. I'd guess hundreds, probably thousands. They have all been uploaded automatically or semi-automatically. Because validating them by hand from the bazillion of different sources is very difficult. I spot a startup chance here for a company offering a trusted, validated repository where all uploaded artifacts have been verified by the uploaders. Any VCs around? I am bored and have time to write a business plan ;-) IMHO: Anyone who is using maven for commercial software development and does not run a controlled, in-house repository that is actively managed and maintained is IMHO in for big, ugly surprises in the long run. Ciao Henning On Wed, 2008-09-24 at 13:36 +0800, Niclas Hedhman wrote: > On Wed, Sep 24, 2008 at 1:20 PM, Henning Schmiedehausen > wrote: > I enjoy your scenarios... > > > > And again, there is no "high nineties" security. Your solution is either > > secure or it is not. > > > For accuracy; This is not true either. AFAIK, no security solution is > totally secure. You will be left with a number game. > > > But I agree that this is a complex and non-trivial problem. Right now, we > just say; "No Security, check manually." and to users who don't (like > myself) we just ask them to blame themselves for being sloppy. Fair Enough. > BUT, somehow I feel that a bit of "help" could be in order, and I think that > if it is not portrayed as a "secure" and that the manual check should still > be done by the security conscious, then why not try to provide that? How can > a step in the right direction be bad? > > > Cheers > Niclas --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org For additional commands, e-mail: general-help@incubator.apache.org