From users-return-28107-archive-asf-public=cust-asf.ponee.io@subversion.apache.org Fri Jul 19 18:44:54 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id BA093180665 for ; Fri, 19 Jul 2019 20:44:53 +0200 (CEST) Received: (qmail 57868 invoked by uid 500); 19 Jul 2019 18:44:52 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 57839 invoked by uid 99); 19 Jul 2019 18:44:51 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Jul 2019 18:44:51 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id A87E5182B0C for ; Fri, 19 Jul 2019 18:44:47 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.003 X-Spam-Level: * X-Spam-Status: No, score=1.003 tagged_above=-999 required=6.31 tests=[KAM_LAZY_DOMAIN_SECURITY=1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=disabled Received: from mx1-he-de.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id z5z3J4cPo8SF for ; Fri, 19 Jul 2019 18:44:46 +0000 (UTC) Received-SPF: None (mailfrom) identity=mailfrom; client-ip=78.47.87.163; helo=mx0.elegosoft.com; envelope-from=stsp@elego.de; receiver= Received: from mx0.elegosoft.com (mx0.elegosoft.com [78.47.87.163]) by mx1-he-de.apache.org (ASF Mail Server at mx1-he-de.apache.org) with ESMTP id 32C3D7E221 for ; Fri, 19 Jul 2019 18:44:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mx0.elegosoft.com (Postfix) with ESMTP id 232A61E8461; Fri, 19 Jul 2019 20:44:40 +0200 (CEST) Received: from mx0.elegosoft.com ([127.0.0.1]) by localhost (mx0.elegosoft.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vb3Nrd1gTz-F; Fri, 19 Jul 2019 20:44:34 +0200 (CEST) Received: from ted.stsp.name (ted.stsp.name [217.197.84.34]) by mx0.elegosoft.com (Postfix) with ESMTPSA id 0A80F1E840D; Fri, 19 Jul 2019 20:44:34 +0200 (CEST) Received: from localhost (ted.stsp.name [local]) by ted.stsp.name (OpenSMTPD) with ESMTPA id 6689c650; Fri, 19 Jul 2019 20:44:33 +0200 (CEST) Date: Fri, 19 Jul 2019 20:44:33 +0200 From: Stefan Sperling To: Pierre =?iso-8859-1?Q?Four=E8s?= , users@subversion.apache.org Subject: Re: Is Permanently Accept SSL Certificate gone in 1.10.4 ? Message-ID: <20190719184433.GJ94250@ted.stsp.name> Mail-Followup-To: Pierre =?iso-8859-1?Q?Four=E8s?= , users@subversion.apache.org References: <20190719183857.GI94250@ted.stsp.name> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190719183857.GI94250@ted.stsp.name> User-Agent: Mutt/1.11.4 (2019-03-13) On Fri, Jul 19, 2019 at 08:38:57PM +0200, Stefan Sperling wrote: > On Fri, Jul 19, 2019 at 01:40:52PM +0200, Pierre Four�s wrote: > > Hi all, > > > > I have a script accessing an old svn server whom SSL certificate have > > expired a long time ago. Up to now, I was permanently accepting the > > certificate on the first run of the script and then everything was > > sailling smooth. I reinstalled a couple of months ago a new box where > > this script was intented to run and the (p)ermanently option seems not > > provided anymore. > > If you're scripting 'svn' you should be using the --non-interactive option. > > In which case your script can use the --trust-server-cert-failures > option to accept a cert in pre-determined failure cases. > > 'svn help update', for example, displays the following information > section about the --trust-server-cert-failures option: > > --trust-server-cert-failures ARG : with --non-interactive, accept SSL server > certificates with failures; ARG is comma-separated > list of 'unknown-ca' (Unknown Authority), > 'cn-mismatch' (Hostname mismatch), 'expired' > (Expired certificate), 'not-yet-valid' (Not yet > valid certificate) and 'other' (all other not > separately classified certificate errors). > > Once your script uses this option it should work out of the box against > your problematic server and there should be no need to save the cert. Follow-up regarding your actual question: It looks like the interactive prompt omits an option to save the cert if it sees a certificate failure of class 'other' from the above list. I am not sure why this decision was made but that's what the current code seems to do. So I suspect your SSL cert is failing for some reason other than unknown-ca, cn-mismatch, expired, not-yet-valid. Additionally, the ability to save a cert is also disabled if the --no-auth-cache option is used.