On Wed, 2018-11-14 at 21:38 +0100, Michael Osipov wrote: > Am 2018-11-13 um 15:50 schrieb Oleg Kalnichevski: > > On Mon, 2018-11-12 at 19:31 -0500, Karl Wright wrote: > > > Hi Michael, > > > > > > I did not contribute this work; I merely obliquely helped > > > integrating > > > it. > > > If I recall correctly, there was a reasonable case made for it, > > > but I > > > don't > > > remember what it wasy. > > > > > > Karl > > > > > > > > > > Hi Michael > > > > For full background: > > > > https://github.com/apache/httpcomponents-client/pull/66 > > > > CredSSP is marked experimental. We can still remove it. > > I just pinged the author on GitHub after reading the discussion. I > didn't not find any benefit mentioned in the discussion. > > What bugs me is that people push two distinct changes (NTLM > improvement > and CredSSP) in one change making harder to review, rollback, track. > > Proprietary stuff like this is hard to maintain because it is most a > one > time contribution. Microsoft has released new revisions of the spec. > > Curl suffers from the same issue. A lot of people contribute one > time, > is mentioned in 'curl --version', but no one really knows whether > the > stuff works actually. > > This is something we should avoid. If there is a feature none of the > committers can really test somehow, how are we supposed to support > that? >
CredSSP is no different that many other contributions that people drop on us, then lose interest and walk away. I intend to remove OSGi stuff in the next 5.0 releases. I will not hesitate to remove CredSSP as well. Oleg > > Michael > > > > On Mon, Nov 12, 2018 at 5:50 PM Michael Osipov < > > > [email protected]> > > > wrote: > > > > > > > Guys, > > > > > > > > I just have discovered that CredSSP has been added with (NTLM, > > > > yuck) > > > > some time ago. Can someone point me to a valid use case for > > > > this > > > > over > > > > HTTP? Karl? As far as I understand CredSSP [1] it is simply not > > > > compatible with/designed for HTTP and duplicates the transport > > > > encryption. The main purpose is to securely transport the > > > > Kerberos > > > > UPN > > > > and password of the user to the target server, e.g., for RDP to > > > > obtain a > > > > TGT on the remote machine as if someone is physically in front > > > > of > > > > the > > > > remote machine. > > > > > > > > This makes sense if you work on raw sockets, but on HTTP? > > > > The CredSspScheme also says that it should work with GSS, but I > > > > believe > > > > that this is impossible because as soon as yo have the > > > > GSSCredential, > > > > you don't have access to the UPN and password, you have the TGT > > > > only. > > > > Neither with JGSS, Heimdal, nor MIT Kerberos unless you acquire > > > > them > > > > again, like the RDP login dialog does. > > > > > > > > So again, what does it better than HTTPS + SPNEGO with > > > > credential > > > > delegation or contraint delegation also given that this works > > > > on > > > > the > > > > Windows backend only?! > > > > > > > > Michael > > > > > > > > [1] https://msdn.microsoft.com/en-us/library/cc226794.aspx > > > > > > > > ------------------------------------------------------------- > > > > ---- > > > > ---- > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > ----------------------------------------------------------------- > > ---- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
