[email protected] wrote:
On Thu, Jun 11, 2009 at 12:13:43PM -0500, Shawn Walker wrote:
[email protected] wrote:
On Wed, Jun 10, 2009 at 05:36:50PM -0700, Dan Price wrote:
Utilities like curl, wget, etc. tend to support a --insecure option,
which basically says, yeah, I know that I can't validate that a server
is what it claims to be, but go ahead anyway.
Do you anticipate having such an option exposed? Would you envision
that being command line? Or stored per-repository?
I'd prefer not to have that option exposed. Right now, I have a
workaround in place that disables CA verification if the directory that
contains the CA certs isn't present. If we'd like to continue to have
this behavior, it should probably be an image property or a
per-repository config option.
I'm not certain that I'm comfortable with a behaviour that automatically
stops verifying the identity of a server because a directory isn't
present.
As opposed to the current behavior today, where we don't ever verify the
CA certificate? This is a workaround until we're consistently
delivering a set of CA certificates in a well-known location. Once that
has been accomplished, we could set this as a per-repository property if
we really want to allow the customer to disable peer verification,
although I'd prefer to have it always enabled.
I feel like peer verification has to be under customer control because
the repository requiring the certificate may be their own and so a CA
Cert may not be available for whatever reason.
The primary reason I'm uncomfortable with the directory being the
arbiter of the behaviour is because peer verification is often defined
by the security policy of the user. While I'm aware that we may not
have a standard location yet for the certificates, it feels wrong to
decide security policy based on the presence of a directory.
Now whether this happens in a later implementation phase or doesn't
matter to me. I'm quite aware that the scope of transport changes has
already ballooned rather fearfully :)
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
