Hi Matt,
On Nov 15, 2010, at 10:56 PM, Matt Robinson wrote:
> Why is it reasonable to use the Puppet certificates to make this
> connection?
I think we should not break the cert chain. If you rollout a package
and puppet make sure that a package is installed I want to make sure
it is the package which I chose, not that one an attacker could choose.
> Wouldn't this be using Puppet's CA cert to try to
> validate connections to wherever you're getting the dmg?
I think the use case of the pkgdmg provider is to use a local site, so
it is ok to use puppet's CA, or am I missing something?
I download dmgs to our nginx host which should be able to distribute
these. For now I have to serve it with another webserver, which will
not be validated.
Here my earlier tested usage suggestion:
package { "Foo.dmg":
ensure => installed,
provider => pkgdmg,
source =>"https://puppethost:8140/dmgs/Foo.dmg";,
}
Do you think it should be more configurable?
> And even if this was valid, why set both capath and cacert?
I see cacert is enough. I wanted to use capath I guess, but I got errors.
[/tmp]$ curl -o test.dmg -C - --cacert /etc/puppet/ssl/certs/ca.pem -s -S --url
https://puppethost:8140/dmgs/puppet-0.25.4.dmg
[/tmp]$ ll
total 2048
-rw-r--r-- 1 root wheel 1.0M Nov 15 23:36 test.dmg
[/tmp]$ curl -o test.dmg -C - --capath /etc/puppet/ssl/certs -s -S --url
https://puppethost:8140/dmgs/puppet-0.25.4.dmg
curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
failed
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). The default
bundle is named curl-ca-bundle.crt; you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
> Why bother with the fallback to insecure if the secure connection
> fails?
> I know in the ticket Nigel suggested this so that we don't
> break backward compatibility, but the change doesn't seem worth making
> if we do that. This undermines the whole purpose of using the secure
> connection.
I think the same way as you, but as Nigel suggested there are poeple that
use it in another way so there should be an upgrade path which is smooth.
First drop a warning to users that use it without verification and after
that drop the fallback. Otherwise your users will not like the product
that always break after an upgrade to a new version without telling them
before.
All the best, Sandor Szücs
--
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
