Re: Bearer auth scheme support (RFC 6750)
On Mon, Dec 5, 2022 at 3:25 PM Michael Osipov wrote: > Am 2022-12-05 um 17:41 schrieb larry mccay: > > Hi Oleg - > > > > Happy to see Bearer Tokens coming in as a first class auth scheme. > > > > Can you be a bit clearer on continued support for SPNEGO and KERBEROS > going > > forward for those still using them? > > Disabling them by default means that we will need to explicitly enable > them? > > Deprecating them means that you plan to remove them completely? > > I would not recommend using them at all. They are poorly written and > violate RFC 7546. To answer both of your questions: yes. > > Also, as I said before, I'd be willing to write a new integration as > soon as I have a business need, for the past years I didn't need it. One > of the reaons which held me off is that the Nexus developers didn't want > to fix issues with me which would require to integrate it and others are > that all SPNEGO-enabled services I provide are either accessed through > SSPI or MIT Kerberos. > > Michael > > - > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > >
Re: Bearer auth scheme support (RFC 6750)
+d...@knox.apache.org for visibility others in the hadoop ecosystem would likely be interested as well but we'll limit the spam. On Mon, Dec 5, 2022 at 11:41 AM larry mccay wrote: > Hi Oleg - > > Happy to see Bearer Tokens coming in as a first class auth scheme. > > Can you be a bit clearer on continued support for SPNEGO and KERBEROS > going forward for those still using them? > Disabling them by default means that we will need to explicitly enable > them? > Deprecating them means that you plan to remove them completely? > > thanks! > > --larry > > On Sat, Dec 3, 2022 at 6:48 AM Oleg Kalnichevski wrote: > >> Folks >> >> Feel free to review and comment. >> >> The change-set in this branch adds support for the Bearer auth scheme >> as defined in RFC 6750 >> >> >> https://github.com/apache/httpcomponents-client/compare/master...bearer_auth_support >> >> The Bearer scheme can be used with OAuth 2.0, JWT and presumably any >> other type of tokens. >> >> As the next step I would like to deprecate NTLM, SPNEGO and KERBEROS >> schemes in favor of standard Basic / Bearer over TLS and to disable >> them by default. >> >> Oleg >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org >> For additional commands, e-mail: dev-h...@hc.apache.org >> >>
Re: Bearer auth scheme support (RFC 6750)
Hi Oleg - Happy to see Bearer Tokens coming in as a first class auth scheme. Can you be a bit clearer on continued support for SPNEGO and KERBEROS going forward for those still using them? Disabling them by default means that we will need to explicitly enable them? Deprecating them means that you plan to remove them completely? thanks! --larry On Sat, Dec 3, 2022 at 6:48 AM Oleg Kalnichevski wrote: > Folks > > Feel free to review and comment. > > The change-set in this branch adds support for the Bearer auth scheme > as defined in RFC 6750 > > > https://github.com/apache/httpcomponents-client/compare/master...bearer_auth_support > > The Bearer scheme can be used with OAuth 2.0, JWT and presumably any > other type of tokens. > > As the next step I would like to deprecate NTLM, SPNEGO and KERBEROS > schemes in favor of standard Basic / Bearer over TLS and to disable > them by default. > > Oleg > > - > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > >
Re: Post-commit review policy
Personally, I find RTC much more appropriate for mature-ish projects where quality and awareness are a higher priority than fast innovation. I think the sub-topic here actually supports that notion. Faster innovation and iterative development can happen in feature branches with appropriate merge criteria in place. In Knox and other projects that I am involved with, trivial changes don't need review but with proper review, checkstyle integrations, etc, a lot of unnecessary thrashing can be avoided. While I don't have a binding vote here, I'd encourage you (from the sidelines) to codify your style preferences in automated precommit checks and switch to an RTC model. These can actually be healthy growing pains. (If you choose to see them that way) :) --larry On Thu, Nov 17, 2022 at 3:45 PM Gary D. Gregory wrote: > There's your answer Cater, it was intentional, unreviewed, and unilateral. > > On 2022/11/15 21:22:29 Oleg Kalnichevski wrote: > > On Tue, 2022-11-15 at 15:41 -0500, Gary Gregory wrote: > > > This is a distraction from the problem I brought up in another > > > thread: Oleg > > > erases other people's commits at he wishes, CTR or RTC won't matter. > > > This > > > is not the Apache way. > > > > > > > You have a long history of making really bad changes to the project > > code based on nothing more than your personal wishes and preferences. > > Moreover, you repeatedly ignored multiple requests to have a discussion > > before making such changes at the very least, a basic decency toward > > your fellow project members. > > > > THIS is not the Apache way. > > > > Oleg > > > > > > > Gary > > > > > > On Tue, Nov 15, 2022, 15:37 Michael Osipov > > > wrote: > > > > > > > Am 2022-11-15 um 14:32 schrieb Oleg Kalnichevski: > > > > > We have an implicit commit-them-review policy ever since the > > > > > inception > > > > > of the project in the year of 2005. We all are free to commit > > > > > what we > > > > > deem appropriate but no commit can be considered safe until it > > > > > has been > > > > > voted upon and tagged with a release tag. > > > > > > > > > > If an objection has been raised about any commit in the > > > > > development > > > > > branch it can be reverted and should be resubmitted through a PR > > > > > and put > > > > > to a review. This basically applies to all committers and any > > > > > commit. > > > > > Any committer can ask for a commit to be reverted and the change- > > > > > set put > > > > > to a review. > > > > > > > > > > If any commiter no longer feels comfortable with this approach I > > > > > personally will have no problem switching to the pre-commit > > > > > review > > > > > policy whereby every change must go through a PR first. Naturally > > > > > that > > > > > would call for a format vote. > > > > > > > > You guys might want to read dev@maven.a.o. We had this discussion > > > > recently. Coincedence. > > > > > > > > After the Maven 3.7.0 fiasco we have moved from CTR to RTC which -- > > > > yes, > > > > it slows down the process -- *but* drastically improved the quality > > > > of > > > > the code/new changes /before/ they land and reverts are basically > > > > down > > > > to zero. Additionally, people tend to do better self reviews. I did > > > > a > > > > lot of self reviews on recently Doxia changes and noticed myself > > > > that my > > > > PRs were incomplete. I would never go back to CTR, personally. > > > > (except > > > > for typo fixes or alike) > > > > > > > > Of course, CTR means that you have qualified people who can review > > > > in a > > > > decent timeframe (needs to be defined). It is never wrong to have > > > > another pair of eyes on a solution. > > > > > > > > Michael > > > > > > > > > > > > --- > > > > -- > > > > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > > > > For additional commands, e-mail: dev-h...@hc.apache.org > > > > > > > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > > For additional commands, e-mail: dev-h...@hc.apache.org > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > >
Re: [VOTE] Release HttpCore 4.4.15 based on RC1
Oops - that was due to me adding the artifacts for signature verification into the project. It runs fine when I remove that. [INFO] ---< org.apache.httpcomponents:httpcore-ab > [INFO] Building Apache HttpCore Benchmarking Tool 4.4.15 [5/5] [INFO] [ jar ]- [INFO] [INFO] --- apache-rat-plugin:0.12:check (default-cli) @ httpcore-ab --- [INFO] Enabled default license matchers. [INFO] Will parse SCM ignores for exclusions... [INFO] Finished adding exclusions from SCM ignore files. [INFO] 61 implicit excludes (use -debug for more details). [INFO] Exclude: .pmd [INFO] Exclude: **/.externalToolBuilders/** [INFO] Exclude: **/.pmd [INFO] Exclude: **/maven-eclipse.xml [INFO] Exclude: **/.checkstyle [INFO] Exclude: src/docbkx/resources/** [INFO] Exclude: src/test/resources/*.truststore [INFO] Exclude: src/test/resources/*.p12 [INFO] 15 resources included (use -debug for more details) [INFO] Rat check: Summary over all files. Unapproved: 0, unknown: 0, generated: 0, approved: 15 licenses. [INFO] [INFO] Reactor Summary for Apache HttpComponents Core 4.4.15: [INFO] [INFO] Apache HttpComponents Core . SUCCESS [ 0.427 s] [INFO] Apache HttpCore SUCCESS [ 0.125 s] [INFO] Apache HttpCore NIO SUCCESS [ 0.064 s] [INFO] Apache HttpCore OSGi bundle SUCCESS [ 0.114 s] [INFO] Apache HttpCore Benchmarking Tool .. SUCCESS [ 0.029 s] [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 1.454 s [INFO] Finished at: 2021-12-03T16:53:23-05:00 [INFO] lmccay@lmccay-5550:~/Projects/httpcore$ On Fri, Dec 3, 2021 at 4:52 PM larry mccay wrote: > [INFO] Enabled default license matchers. > [INFO] Will parse SCM ignores for exclusions... > [INFO] Finished adding exclusions from SCM ignore files. > [INFO] 65 implicit excludes (use -debug for more details). > [INFO] Exclude: .pmd > [INFO] Exclude: **/.externalToolBuilders/** > [INFO] Exclude: **/.pmd > [INFO] Exclude: **/maven-eclipse.xml > [INFO] Exclude: **/.checkstyle > [INFO] Exclude: src/docbkx/resources/** > [INFO] Exclude: src/test/resources/*.truststore > [INFO] Exclude: src/test/resources/*.p12 > [INFO] 54 resources included (use -debug for more details) > [INFO] Rat check: Summary over all files. Unapproved: 36, unknown: 36, > generated: 0, approved: 8 licenses. > [INFO] > > [INFO] Reactor Summary for Apache HttpComponents Core 4.4.15: > [INFO] > [INFO] Apache HttpComponents Core . FAILURE [ > 0.881 s] > [INFO] Apache HttpCore SKIPPED > [INFO] Apache HttpCore NIO SKIPPED > [INFO] Apache HttpCore OSGi bundle SKIPPED > [INFO] Apache HttpCore Benchmarking Tool .. SKIPPED > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 2.354 s > [INFO] Finished at: 2021-12-03T16:51:51-05:00 > [INFO] > > [ERROR] Failed to execute goal org.apache.rat:apache-rat-plugin:0.12:check > (default-cli) on project httpcomponents-core: Too many files with > unapproved license: 36 See RAT report in: > /home/lmccay/Projects/httpcore/target/rat.txt -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the > -e switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, > please read the following articles: > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > > On Fri, Dec 3, 2021 at 3:27 PM Gary Gregory > wrote: > >> Is anyone able to run 'mvn apache-rat:check' ? >> >> Gary >> >> >> On Fri, Dec 3, 2021, 15:07 Arturo Bernal > .invalid> >> wrote: >> >> > Hi All, >> > >> > [x] +1 Release these artifacts >> > >> > Building OK from tag, with `clean test install` targets. >> > >> > Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d) >> > Maven home: /opt/apache-maven-3.8.1 >>
Re: [VOTE] Release HttpCore 4.4.15 based on RC1
[INFO] Enabled default license matchers. [INFO] Will parse SCM ignores for exclusions... [INFO] Finished adding exclusions from SCM ignore files. [INFO] 65 implicit excludes (use -debug for more details). [INFO] Exclude: .pmd [INFO] Exclude: **/.externalToolBuilders/** [INFO] Exclude: **/.pmd [INFO] Exclude: **/maven-eclipse.xml [INFO] Exclude: **/.checkstyle [INFO] Exclude: src/docbkx/resources/** [INFO] Exclude: src/test/resources/*.truststore [INFO] Exclude: src/test/resources/*.p12 [INFO] 54 resources included (use -debug for more details) [INFO] Rat check: Summary over all files. Unapproved: 36, unknown: 36, generated: 0, approved: 8 licenses. [INFO] [INFO] Reactor Summary for Apache HttpComponents Core 4.4.15: [INFO] [INFO] Apache HttpComponents Core . FAILURE [ 0.881 s] [INFO] Apache HttpCore SKIPPED [INFO] Apache HttpCore NIO SKIPPED [INFO] Apache HttpCore OSGi bundle SKIPPED [INFO] Apache HttpCore Benchmarking Tool .. SKIPPED [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 2.354 s [INFO] Finished at: 2021-12-03T16:51:51-05:00 [INFO] [ERROR] Failed to execute goal org.apache.rat:apache-rat-plugin:0.12:check (default-cli) on project httpcomponents-core: Too many files with unapproved license: 36 See RAT report in: /home/lmccay/Projects/httpcore/target/rat.txt -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException On Fri, Dec 3, 2021 at 3:27 PM Gary Gregory wrote: > Is anyone able to run 'mvn apache-rat:check' ? > > Gary > > > On Fri, Dec 3, 2021, 15:07 Arturo Bernal > wrote: > > > Hi All, > > > > [x] +1 Release these artifacts > > > > Building OK from tag, with `clean test install` targets. > > > > Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d) > > Maven home: /opt/apache-maven-3.8.1 > > Java version: 1.8.0_275, vendor: AdoptOpenJDK, runtime: > > /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre > > Default locale: en_US, platform encoding: UTF-8 > > OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac" > > [INFO] Scanning for projects… > > > > > > > > > > Arturo Bernal > > arturobern...@yahoo.com > > > > > > > > > On 3 Dec 2021, at 19:56, larry mccay wrote: > > > > > > * built from src and ran unit tests > > > * Checked NOTICE, LICENSE, README, doap files > > > * verified signatures > > > * NOTICE.txt needs copyright date updated > > > * doap file is not up to date > > > > > > Depending on your release cadence, you may want to address the > copyright > > in > > > the NOTICE.txt file before release now. > > > > > > +1 (non-binding) > > > > > > On Fri, Dec 3, 2021 at 8:37 AM Gary Gregory > > wrote: > > > > > >> +1 > > >> > > >> ...but I can't verify licensing with 'mvn clean apache:rat-check' > > because > > >> some files in target and .gitignore are included as failures. > > >> > > >> OK building mvn clean package -V -P'!use-toolchains' works with Java > 8, > > 11 > > >> on macOS Darwin *** 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 > > >> 17:33:23 PDT 2021; root:xnu-8019.41.5~1/RELEASE_X86_64 x86_64. > > >> > > >> FTR, building on Java 17 fails since the Java 1.6 target is no longer > > >> supported. > > >> > > >> Gary > > >> > > >> On Fri, Dec 3, 2021 at 3:44 AM Oleg Kalnichevski > > wrote: > > >> > > >>> Please vote on releasing these packages as HttpCore 4.4.15. > > >>> The vote is open for the at least 72 hours, and only votes from > > >>> HttpComponents PMC members are binding. The vote passes if at least > > >>> three binding +1 votes are cast and there are
Re: [VOTE] Release HttpCore 4.4.15 based on RC1
* built from src and ran unit tests * Checked NOTICE, LICENSE, README, doap files * verified signatures * NOTICE.txt needs copyright date updated * doap file is not up to date Depending on your release cadence, you may want to address the copyright in the NOTICE.txt file before release now. +1 (non-binding) On Fri, Dec 3, 2021 at 8:37 AM Gary Gregory wrote: > +1 > > ...but I can't verify licensing with 'mvn clean apache:rat-check' because > some files in target and .gitignore are included as failures. > > OK building mvn clean package -V -P'!use-toolchains' works with Java 8, 11 > on macOS Darwin *** 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 > 17:33:23 PDT 2021; root:xnu-8019.41.5~1/RELEASE_X86_64 x86_64. > > FTR, building on Java 17 fails since the Java 1.6 target is no longer > supported. > > Gary > > On Fri, Dec 3, 2021 at 3:44 AM Oleg Kalnichevski wrote: > > > Please vote on releasing these packages as HttpCore 4.4.15. > > The vote is open for the at least 72 hours, and only votes from > > HttpComponents PMC members are binding. The vote passes if at least > > three binding +1 votes are cast and there are more +1 than -1 votes. > > > > Release notes: > > > > > https://dist.apache.org/repos/dist/dev/httpcomponents/httpcore-4.4.15-RC1/RELEASE_NOTES-4.4.x.txt > > > > Maven artefacts: > > > > > https://repository.apache.org/content/repositories/orgapachehttpcomponents-1141/org/apache/httpcomponents/ > > > > Git Tag: 4.4.15-RC1 > > https://github.com/apache/httpcomponents-core/tree/4.4.15-RC1 > > > > Packages: > > > https://dist.apache.org/repos/dist/dev/httpcomponents/httpcore-4.4.15-RC1 > > revision 51183 > > > > Hashes: > > > 287900faad866f74549a4b7c02ad930abdc86a78e4e07caf416c6cfe020552f1434b9f6d5e894eaa8656dd8ce7f742a0166df1ef3035c6ad139fa52b9c3c8931 > > httpcomponents-core-4.4.15-bin.zip > > > 36ed82ad7c7b63a3d3514274fe057a39b0a7b61fd09c7d0b08583ad6cb257a56ebd20fa244feadef5c880d709cb4e72529ac7c48c23784b6a2e4bf9d5a09 > > httpcomponents-core-4.4.15-src.zip > > > 396ba12308d82a34f31824d800e8b85cfa414eff7a9317df4dafd27ad6f05b2d41062228f23f72e51630803c462a5bcb2c660ffbd104ea1275b49c5bf1247171 > > httpcomponents-core-4.4.15-bin.tar.gz > > > 2c9831d9f13d46a69b6bc75f1a09ee0ad171777414c50bfde2394b0392665bc693e3be4ae6c056873548080a14191ec80993be322799f222912c20ce1875 > > httpcomponents-core-4.4.15-src.tar.gz > > > > Keys: > > https://www.apache.org/dist/httpcomponents/httpcore/KEYS > > > > > -- > > Vote: HttpCore 4.4.15 release > > [ ] +1 Release the packages as HttpCore 4.4.15. > > [ ] -1 I am against releasing the packages (must include a reason). > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > > For additional commands, e-mail: dev-h...@hc.apache.org > > > > >
Re: Gradual deprecation and removal of NTLM and SPNEGO support
It is still unclear to me whether there is a security issue with using the existing Kerberos/SPNEGO implementation. Sorry if I am missing a clear message here. On Sat, Nov 27, 2021 at 5:02 AM Oleg Kalnichevski wrote: > On Fri, 2021-11-26 at 18:39 +0100, Michael Osipov wrote: > > Am 2021-11-23 um 20:14 schrieb Oleg Kalnichevski: > > > Folks > > > > > > Here's my proposal > > > > > > HttpClient 5.2: > > > > > > * Announce the plan to deprecate and eventually remove NTLM support > > > and experimental SPNEGO / Kerberos support > > > > > > * Ask downstream projects to get in touch with us. Invite > > > interested > > > parties to participate in Kerberos support improvements > > > > OK for me. > > > > > HttpClient 5.3: > > > > > > * Make NTLM / SPNEGO / Kerberos disabled by default requiring an > > > explicit opt-in from the user. Mark respective implementations > > > deprecated. > > > > Also OK for me also. I have explicitly disabled SPNEGO for Wagon > > some > > time ago. It simply did not make any sense. > > > > > * Remove stateful connection support > > ^^ > > This contradicts the option still to explicitly enable to > > providers. > > Did you mistype? > > > > Hi Michael > > > What I propose is that the support for connection state tracking be > removed in 5.3. It is an extra security mechanism presently used by > NTLM only. It adds a lot of otherwise unnecessary complexity to the > connection pooling logic and the APIs. I would like to get rid of it > sooner. > > > > > > * Invite interested parties to participate in Kerberos support > > > improvements > > > > > > > > > HttpClient 6.0: > > > > > > * Remove NTLM support > > > > > > * Remove SPNEGO / Kerberos support if still broken > > > > Can you answer my previous request? > > > What is important to know for you when you want to remove code: The > > > security context loop is always client initiated and required to be > > > completed by a token sent from the server with the response unless > > > it > > > is 401/407. So the HttpClient needs to store the context somewhere > > > until it receives the response, completes security context and > > > frees > > > the security context. This is on a per-request basis. If the > > > context > > > is not completed with the response then the authentication should > > > not > > > be trusted, either an exception should be through or a > > > warning/error > > > must be logged. > > > > Will this still be possible for SPNEGO to be implemented properly > > after > > the remove of stateful connection support? > > Of course. There will be no changes to the Auth APIs. It will always be > possible to add NTLM and Kerberos as extra authentication schemes if > desired. > > Oleg > > > > - > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > >
Re: Gradual deprecation and removal of NTLM and SPNEGO support
This is a concerning statement and I need some additional information to determine what sort of risk is inherent in the current implementation. Perhaps we should take those details off list if this is a security issue. I'll need to determine whether there are any workarounds or usage patterns that we can use to ensure that we are safe. Currently we do not preemptively send tokens and we use our own delegation tokens after the first authentication. On Sat, Nov 20, 2021 at 2:58 PM Michael Osipov wrote: > Am 2021-11-20 um 20:46 schrieb larry mccay: > > Hi - > > > > I am the Apache Knox PMC chair and a committer on Hadoop and other > > ecosystem projects. > > > > FYI, Apache Knox is indeed dependent on SPNEGO in httpclient. > > Knox is a Hadoop ecosystem gateway and as part of the trusted proxy or > > proxyuser pattern within Hadoop it requires all proxies that dispatch > > requests on behalf of other users to authenticate via Kerberos/SPNEGO. > > Knox is not the only proxyuser in the ecosystem and likely not the only > one > > that is leveraging HttpClient this way. > > It is used within a huge number of Hadoop deployments both on-prem and in > > the cloud and SPNEGO is critical to the security of these deployments. > > If this would be critical for security then you would not rely on it. It > does not complete the security context for you. As sad as it sounds. > > I am currently in a project at work where I try to get rid of the Ping > Identity/OAuth/OIDC hype and move to to SPNEGO/Kerberos and HttpClient > is used, in Spring and JMeter. Maybe this well an opportunity to make it > right, but this will only land in 5.2.x, maybe 5.1.x if the API allows it. > > M > > - > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > >
Re: Gradual deprecation and removal of NTLM and SPNEGO support
Hi - I am the Apache Knox PMC chair and a committer on Hadoop and other ecosystem projects. FYI, Apache Knox is indeed dependent on SPNEGO in httpclient. Knox is a Hadoop ecosystem gateway and as part of the trusted proxy or proxyuser pattern within Hadoop it requires all proxies that dispatch requests on behalf of other users to authenticate via Kerberos/SPNEGO. Knox is not the only proxyuser in the ecosystem and likely not the only one that is leveraging HttpClient this way. It is used within a huge number of Hadoop deployments both on-prem and in the cloud and SPNEGO is critical to the security of these deployments. We are currently on 4.5.13 for HttpClient. A backward compatible path forward here is going to be needed and I'd be happy to help out however I can. thanks, --larry On Sat, Nov 20, 2021 at 2:08 PM Michael Osipov wrote: > Am 2021-11-20 um 19:35 schrieb Oleg Kalnichevski: > > On Sat, 2021-11-20 at 12:25 -0500, Karl Wright wrote: > >> These protocols are, unfortunately, still used. > >> > >> However, the projects I know that use them have not yet moved to 5.x > >> of > >> httpcomponents. Other projects I know of that used to use > >> httpcomponents > >> have since upgraded to different http libraries that supported http > >> 2.0 > >> early on. > >> > >> The hint that all it takes is a shove from below to convince other > >> projects > >> to drop NTLM support is, perhaps, not accurate. Projects that > >> maintain > >> NTLM support do so because they are tied to legacy systems that use > >> it. > >> Later improvements, e.g. Kerberos, have also only lightly been > >> supported by > >> HttpComponents, and only with external configuration, which really > >> limits > >> its utility. ManifoldCF, which does much integration with windows > >> systems, supports Kerberos but only in the most hacky way, because > >> there > >> wasn't anything more seamless available. > >> > >> I would therefore counter-propose that Kerberos become a first-class > >> replacement to NTLM before NTLM is discontinued. By first-class, I > >> mean > >> that it is possible to programmatically set up a kerberos connection > >> without an external config file. Maybe this is now possible; if so > >> please > >> correct me. > >> > >> I would love to be able to contribute to this effort, but I fear my > >> day > >> job's responsibilities are so vast and growing that this will be > >> impossible. At best I can maintain the projects I have; new > >> development is > >> out of the question at the moment. > >> > >> Karl > >> > > > > Hi Karl > > > > I am so happy that you are still keeping an eye on the mailing list and > > reacting on NTLM related matters. > > > > I do understand your position. The problem is there are no volunteers > > eager to do work on Kerberos support either. We cannot keep on > > pretending everything is all right. We need to make downstream projects > > aware of the situation and making NTLM, SPNEGO and Kerberos an opt-in > > features by default would be the right thing to do in my opinion. > > FWIW, I have explicitly configured auth schemes in Wagon to those known > to work (except NTLM): https://issues.apache.org/jira/browse/WAGON-539 > > - > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > >
[jira] [Commented] (HTTPCLIENT-1968) Encoded forward slashes are not preserved when rewriting URI
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757358#comment-16757358 ] Larry McCay commented on HTTPCLIENT-1968: - I am in the process of upgrading Hadoop to 4.5.6 and do not want to introduce this issue. Since this seems to be caused by HTTPCLIENT-1960 and [~coheigea]'s comment suggests it is so - I assume that 4.5.6 is okay still. I should also mention that since HttpClient is an extremely critical component in the Knox dispatch code, this issue is concerning to me. I believe that I also saw discussion about a new URI class in email somewhere - maybe another JIRA? Also concerning. > Encoded forward slashes are not preserved when rewriting URI > > > Key: HTTPCLIENT-1968 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1968 > Project: HttpComponents HttpClient > Issue Type: Bug >Affects Versions: 4.5.7 >Reporter: Jay Modi >Priority: Major > Attachments: rewrite_preserve_forward_slash.diff > > > URIs that contain an encoded forward slash (%2F) are no longer preserved when > the HTTP client executes. I came across this when upgrading from 4.5.2 to > 4.5.7 and my requests that contained an encoded forward slash suddenly > started failing. The appears to be due to decoding and re-encoding of the > path that takes place in the URIUtils#rewriteURI method. I've attached a > patch that restores the old behavior but if a URI contains two slashes in a > row in addition to an encoded slash the encoded forward slash will be decoded. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: Annotations Removed in 4.5.3?
Interesting point, Sebb. I wasn't clear why the annotations were being used in our codebase actually. That makes a lot of sense why they would be fair game to remove. Thanks! On Thu, Mar 9, 2017 at 3:52 PM, sebb <seb...@gmail.com> wrote: > As I recall, the annotations were intended as documentation for the > classes, and had class retention. > > So I'm not sure how this can affect 3rd party code at runtime. > > On 9 March 2017 at 16:07, larry mccay <larry.mc...@gmail.com> wrote: > > Hi HC devs - > > > > Do I understand correctly that the annotations were removed in 4.5.3 in > an > > incompatible way? > > Maybe I am missing something but breaking the code of existing consumers > in > > a dot release is bad practice. > > > > We needed to upgrade to 4.5.3 in order to get the SSL+SPNEGO fix that > broke > > us with 4.5.2 but now doing so breaks our annotation usage. > > > > Is there some strategy for existing code to migrate or to use a shim of > > sorts for this? > > > > In the meantime, it seems we will need to downgrade back to 4.5.1 again > to > > avoid the SSL+SPNEGO issue. > > > > If there are any critical security fixes/CVEs fixed between dot releases > > incompatible changes make it risky to upgrade. > > > > Hoping that you have some other answer for this. > > > > thanks, > > > > --larry > > - > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > >
Annotations Removed in 4.5.3?
Hi HC devs - Do I understand correctly that the annotations were removed in 4.5.3 in an incompatible way? Maybe I am missing something but breaking the code of existing consumers in a dot release is bad practice. We needed to upgrade to 4.5.3 in order to get the SSL+SPNEGO fix that broke us with 4.5.2 but now doing so breaks our annotation usage. Is there some strategy for existing code to migrate or to use a shim of sorts for this? In the meantime, it seems we will need to downgrade back to 4.5.1 again to avoid the SSL+SPNEGO issue. If there are any critical security fixes/CVEs fixed between dot releases incompatible changes make it risky to upgrade. Hoping that you have some other answer for this. thanks, --larry
[jira] [Commented] (HTTPCLIENT-1712) SPNego Authentication to HTTPS service
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15596130#comment-15596130 ] Larry McCay commented on HTTPCLIENT-1712: - Thank you for the pointer, [~fschumacher]! I was planning to downgrade to 4.5.1 rather than try to override. Is there any compelling reason to stay off of 4.5.1 until there is a 4.5.3? > SPNego Authentication to HTTPS service > -- > > Key: HTTPCLIENT-1712 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1712 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 4.5.1 >Reporter: Georg Romstorfer >Priority: Minor > Attachments: GGSSchemeBase.patch > > > When connecting with the HttpClient to a website through the HTTPS-Protocol, > SPNego Authentication does not work, because in the method > GGSSchemeBase#generateGSSToken is the service name hardcoded to HTTP. > A workaround is to extend the class SPNegoScheme and override this method. > To fix this, I think it would be best to get the protocol from the current > connection, but I don't how to get the connection in this class, so I can't > provide a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1712) SPNego Authentication to HTTPS service
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15594956#comment-15594956 ] Larry McCay commented on HTTPCLIENT-1712: - [~olegk], [~fschumacher] - I am encountering this in the field now as we shipped Apache Knox with a dependency on 4.5.2 and can no longer dispatch requests to Hadoop APIs in a secure cluster that have SSL enabled. In addition, the use of our SSO functionality will be hampered due to the fact that our cookie must be set to secure only. This we need a 4.5.3 to address as soon as possible. > SPNego Authentication to HTTPS service > -- > > Key: HTTPCLIENT-1712 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1712 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 4.5.1 >Reporter: Georg Romstorfer >Priority: Minor > Attachments: GGSSchemeBase.patch > > > When connecting with the HttpClient to a website through the HTTPS-Protocol, > SPNego Authentication does not work, because in the method > GGSSchemeBase#generateGSSToken is the service name hardcoded to HTTP. > A workaround is to extend the class SPNegoScheme and override this method. > To fix this, I think it would be best to get the protocol from the current > connection, but I don't how to get the connection in this class, so I can't > provide a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
