Return-Path: Delivered-To: apmail-ant-ivy-user-archive@www.apache.org Received: (qmail 18416 invoked from network); 16 Jun 2010 19:06:41 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 16 Jun 2010 19:06:41 -0000 Received: (qmail 48805 invoked by uid 500); 16 Jun 2010 19:06:41 -0000 Delivered-To: apmail-ant-ivy-user-archive@ant.apache.org Received: (qmail 48701 invoked by uid 500); 16 Jun 2010 19:06:40 -0000 Mailing-List: contact ivy-user-help@ant.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: ivy-user@ant.apache.org Delivered-To: mailing list ivy-user@ant.apache.org Received: (qmail 48690 invoked by uid 99); 16 Jun 2010 19:06:40 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Jun 2010 19:06:40 +0000 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=AWL,HTML_MESSAGE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.85.160.173] (HELO mail-gy0-f173.google.com) (209.85.160.173) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Jun 2010 19:06:34 +0000 Received: by gyd5 with SMTP id 5so4453803gyd.4 for ; Wed, 16 Jun 2010 12:06:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.231.202 with SMTP id jr10mr4306845qcb.147.1276715172138; Wed, 16 Jun 2010 12:06:12 -0700 (PDT) Received: by 10.229.238.73 with HTTP; Wed, 16 Jun 2010 12:06:12 -0700 (PDT) Date: Wed, 16 Jun 2010 15:06:12 -0400 Message-ID: Subject: Suggestions for publishing to Ivy repo from Hudson using ssh From: "Steele, Richard" To: ivy-user@ant.apache.org Content-Type: multipart/alternative; boundary=0016e640d01050912204892a6a67 --0016e640d01050912204892a6a67 Content-Type: text/plain; charset=ISO-8859-1 I'm trying to figure out the best way to handle publishing artifacts to our Ivy repository using ssh. We can't prompt the user for the username and password since the publication is usually done by Hudson. We can't embed the username or password as a job configuration property because we can't have those in cleartext; similarly, we can't use a standard user with a well-known password in cleartext because of security concerns. I'm leaning towards using a keystore, but we'd need to use one without a password for the same reasons above (can't prompt, don't want to embed), but a keystore without a password makes the security group twitchy. I'm looking for any ideas or suggestions that might help; practical experience with real examples would be best, but I'll consider anything. Thanks, Rich --0016e640d01050912204892a6a67--