Hi Daniel, hi Nigel,

On Nov 16, 2010, at 5:04 AM, Nigel Kersten wrote:
> On Mon, Nov 15, 2010 at 4:14 PM, Daniel Pittman <[email protected]> wrote:
>> Matt Robinson <[email protected]> writes:
>> 
>>> On Mon, Nov 15, 2010 at 2:59 PM, Sandor Szuecs
>>> <[email protected]> wrote:
>>>>> 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 may also be missing something, but I thought that the provider could use
>>> any site that serves up dmg's over http, so in that case using puppet's CA
>>> doesn't make sense.
>> 
>> Yes, it does, by definition.  "Anything that Open::URI accepts" is the
>> promised implementation, and it would certainly break some of our use of the
>> provider to implement that.

I also saw the Open::URI download, but should it not be deprecated, because
of breaking the trust chain?

For example with the File provider puppet makes it sure a file contains the 
specified content, but an installation of a .pkg or an .app not. 

>>> Perhaps someone more familiar with how this provider is used could weigh in
>>> (Nigel?).
>> 
>> To my eye adding the ability to use a 'puppet' URL there, and fetch that 
>> using
>> the authenticated, internal file transfer mechanism (on demand) would make
>> sense...
> 
> Often the packages seem to be on dedicated web servers that aren't the
> puppetmaster.

Thats true, but maybe it is signed by the global puppet ca. I have no clue if
anyone is using it like that but it is an option.
Otherwise I think Jeff had the right answer for the problem you mentoned.
If the provider first tries a validation against trusted anchors and after that 
reuse puppet ca then it is good enough for a change, or?

> If we're going to re-use the puppet SSL chain for the https call, I'd
> like that to be a configurable parameter, but if you can get it to
> work with the puppet:// protocol, that seems a more reasonable
> approach for encrypted transport.

Yes that clearly makes sense. I added it to my feature list and will look into 
it in a couple of week. Thank you both for your inputs.

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.

Reply via email to