Return-Path: X-Original-To: apmail-chemistry-dev-archive@www.apache.org Delivered-To: apmail-chemistry-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E946BD159 for ; Fri, 17 May 2013 13:43:31 +0000 (UTC) Received: (qmail 76734 invoked by uid 500); 17 May 2013 13:43:32 -0000 Delivered-To: apmail-chemistry-dev-archive@chemistry.apache.org Received: (qmail 76196 invoked by uid 500); 17 May 2013 13:43:25 -0000 Mailing-List: contact dev-help@chemistry.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@chemistry.apache.org Delivered-To: mailing list dev@chemistry.apache.org Received: (qmail 75912 invoked by uid 99); 17 May 2013 13:43:24 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 May 2013 13:43:24 +0000 X-ASF-Spam-Status: No, hits=-0.1 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of peter.schmidt@alfresco.com designates 207.126.144.153 as permitted sender) Received: from [207.126.144.153] (HELO eu1sys200aog122.obsmtp.com) (207.126.144.153) by apache.org (qpsmtpd/0.29) with SMTP; Fri, 17 May 2013 13:43:17 +0000 Received: from mail-vb0-f52.google.com ([209.85.212.52]) (using TLSv1) by eu1sys200aob122.postini.com ([207.126.147.11]) with SMTP ID DSNKUZYz4CN0XVg2BLMfeZr2qJ0IIQG5nC3i@postini.com; Fri, 17 May 2013 13:42:57 UTC Received: by mail-vb0-f52.google.com with SMTP id p13so2277844vbe.11 for ; Fri, 17 May 2013 06:42:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=ewHfEkzzFpcXq9lPD7so/PLEKBsi2xhCnzA9R4k3JWA=; b=NGo4vusSM6TPqPHCHv1EARAW9q4U3cS4H25ME02gV09g6lnJ6pTqjOc8mm/Q0kMBsE PiK22Qt46Lw52hXKrSDMgqpZ7heWvSfz9oZjJHrdTSGzDTxqxGyJS20N4JTPZbk4b/Bj VpZcNAtxJkf69c2mJChogKD077IX/2Q4JrhJafg/eC3RtdEyBx7ImP5TmAI8tZRxPsmP 7SZvXjRM5U5JS2ymhnMSR+9lImdCTlwWXtNswK7U5W7CGWunz94h3ZFwLLz0VGHBaJqp UCfLC78kBrCEDCVgcbY6zkJPlEH/BM/CYlPczd3Wx44oPxt541EVcwgt8yANOGLGT9AG Aq9w== X-Received: by 10.220.46.197 with SMTP id k5mr30261989vcf.40.1368798175318; Fri, 17 May 2013 06:42:55 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.220.46.197 with SMTP id k5mr30261982vcf.40.1368798175244; Fri, 17 May 2013 06:42:55 -0700 (PDT) Received: by 10.52.90.137 with HTTP; Fri, 17 May 2013 06:42:55 -0700 (PDT) In-Reply-To: <9FAC356C8627E0429B4A37F6E3D39B802F508E88@DEWDFEMB10B.global.corp.sap> References: <9FAC356C8627E0429B4A37F6E3D39B802F508E88@DEWDFEMB10B.global.corp.sap> Date: Fri, 17 May 2013 14:42:55 +0100 Message-ID: Subject: Re: kCMISSessionAllowUntrustedSSLCertificate From: Peter Schmidt To: "Eberlein, Peter" , Mike Hatfield Cc: Apache Chemistry , "objective-cmis@googlegroups.com" Content-Type: multipart/alternative; boundary=001a11c2ca40014ef904dcea29eb X-Gm-Message-State: ALoCoQnsZArWYTmtJoaLPYFHuZLT3vTr7VbpcSeQnoON/0ErcUo78oIIy9I6HuHG3AATI2/jKe85fFPNREoVauhIeBqKI4W5U5KJ9te6m8p8Fj/PhtX2xmYsuAHwBBP5llHy1Nf9GlumRmBf9W7a8IhfVkd4blJJ1Ob8DiSgHrslgal7Yoj2sZM= X-Virus-Checked: Checked by ClamAV on apache.org --001a11c2ca40014ef904dcea29eb Content-Type: text/plain; charset=ISO-8859-1 Hi Peter many thanks for your comments. As I am about to leave Alfresco in less than a week I would like to pass this question on to Mike Hatfield (cc'd) Kind regards Peter On 17 May 2013 13:54, Eberlein, Peter wrote: > Hi Peter, > > I noticed the new session parameter, > kCMISSessionAllowUntrustedSSLCertificate, that you introduced. If set, > server certificate validation is skipped so SSL connections to untrusted > servers can be established. > > I don't think that we should have such a parameter. The world is already > insecure enough without encouraging people to deactivate essential security > settings. If there is a need to accept untrusted server certificates * > temporarily*, like during development, than this can easily be done by > providing a custom authentication provider. This was already possible > before this change, without extending the standard implementation with > insecure code. Or did I miss something? I would feel a lot better if this > whole "feature" was removed again and whoever needs to do such messy things > does them in own code in a custom authentication provider. > > Or is it just me who is overly sensitive here? What does everyone else > think? > > Peter > > > -- Kind regards Peter ----------- *Peter Schmidt* *Alfresco Software Ltd.* *UK: 07748 185496* *Int.: +44 7748 185496* *Skype: pweschmidt* --001a11c2ca40014ef904dcea29eb--