I think when you are breaking SSL's verification aspect, that should be an optional setting and not the default.
- Kodiak On Wed, Feb 3, 2016 at 2:44 PM, Partha Aji <p...@redhat.com> wrote: > > > ----- Original Message ----- > | From: "Michael Hrivnak" <mhriv...@redhat.com> > | To: "Bryan Kearney" <bkear...@redhat.com> > | Cc: "pulp-list" <pulp-list@redhat.com> > | Sent: Wednesday, February 3, 2016 12:16:23 PM > | Subject: Re: [Pulp-list] Pulp 2.6 vs 2.8 event notifier question > | > | I'm glad we're clarifying use cases, but back to agreeing on a solution: > | Would > | it be sufficient for katello if we added an option to that notifier to > skip > | cert verification, but make the default behavior to do the validation? > | Would anyone object to that? > | > | That would be a simple fix to help avoid breaking compatibility for users > | on upgrade to 2.8. Regardless of what the ideal behavior should be, the > | current behavior in 2.8 is different and obviously incompatible with > | assumptions that users have made with previous versions. > | > | Michael > > The above proposal sounds reasonable. That will help people who upgrade > from 2.6 to 2.8. Question is whether the default option be to skip > verification and one has pass a separate flag to enable verification OR the > other way round (I am ok either way.) Former will mean no changes as far as > katello is concerned. Later will mean an update ... > > > > | > | On Wed, Feb 3, 2016 at 5:30 PM, Bryan Kearney <bkear...@redhat.com> > wrote: > | > | > On 02/03/2016 09:55 AM, Eric Helms wrote: > | > > | >> > | >> > | >> ----- Original Message ----- > | >> > | >>> From: "Randy Barlow" <rbar...@redhat.com> > | >>> To: "Eric Helms" <ehe...@redhat.com> > | >>> Cc: "Jeremy Cline" <jcl...@redhat.com>, pulp-list@redhat.com > | >>> Sent: Wednesday, February 3, 2016 9:46:20 AM > | >>> Subject: Re: [Pulp-list] Pulp 2.6 vs 2.8 event notifier question > | >>> > | >>> On Wed, Feb 03, 2016 at 09:40:09AM -0500, Eric Helms wrote: > | >>> > | >>>> Not to be argumentative, but that seems like a cop out. I would > think > | >>>> as a > | >>>> user I should be able to provide you with the CA certificate that > should > | >>>> be used for verification for a given event notification. I realize > this > | >>>> is > | >>>> a deprecated feature and my intent is not to incur more work. > However, I > | >>>> do find value in having the right solution in place. > | >>>> > | >>> > | >>> Isn't it the case that Katello is not in this situation? I.e., > Katello > | >>> has the power to install the ca trust for the call back? Also, it > | >>> doesn't make sense to use https:// if you don't want trust to > happen. > | >>> TLS is for two things: trust and privacy, and you can't have privacy > | >>> without trust. > | >>> > | >> > | >> Katello isn't - but I never said I was arguing for Katello's specific > | >> deployment scenario. I am looking at this from the general use case. > If > | >> there is a Pulp installed over on Server A, and I have access to use > it > | >> via > | >> the CLI or API and want to set up an event notifier to hit my box > running > | >> on Server B that is running via HTTPS I cannot, at present, do this > | >> because > | >> I have to implant my server CA certificate on Server A which I may not > | >> have > | >> control over. Unless I am missing something fundamental to this > workflow? > | >> > | >> > | > I tend to agree.. I htink it would be good to completely configure a > repo > | > from the API. However, I do realize that openssl makes things super > sucky > | > in order to increase security. > | > > | > -- bk > | > > | > > | > > | > _______________________________________________ > | > Pulp-list mailing list > | > Pulp-list@redhat.com > | > https://www.redhat.com/mailman/listinfo/pulp-list > | > > | > | _______________________________________________ > | Pulp-list mailing list > | Pulp-list@redhat.com > | https://www.redhat.com/mailman/listinfo/pulp-list > > _______________________________________________ > Pulp-list mailing list > Pulp-list@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-list >
_______________________________________________ Pulp-list mailing list Pulp-list@redhat.com https://www.redhat.com/mailman/listinfo/pulp-list
