chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Hatfield <>
Subject Re: kCMISSessionAllowUntrustedSSLCertificate
Date Fri, 17 May 2013 14:34:09 GMT
Hi Peter,

The primary driver for this flag is to support app deployments for development environments
where the developers are building server-side applications (rather than mobile clients) and
using self-signed SSL certificates. The vast majority of these engineers just aren't skilled
in, nor tooled-up to implement *any* sort of iOS development, let alone to code and deploy
a new authentication provider in a library wrapped in a library wrapped in an app.

At Alfresco, we received many requests for our "Alfresco Mobile" app to support this scenario.
Whilst our app exposes this setting via user preferences, we were mindful that this is far
from ideal from a security standpoint - but had to weigh that against strong commercial drivers.
That's why this behaviour has been designed to be off by default and must very explicitly
be switched on during session creation; something app developers can choose to not expose
at all should they wish.

I believe not having this feature available at all would severely limit the usefulness of
any app built upon Objective-CMIS and, I fear, therefore similarly limit interest in the platform.

Mike Hatfield
Lead Engineer, Mobile Apps
Alfresco Software, Inc.

On 17 May 2013, at 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message