[fetcher] Should use HTTPClient 4: HTTPClient 3.1 has a vulnerability(CVE 2012-5783)

[eboregelna]

Migrating to HTTPClient 4 would help users of the rome library get more vulnerability fixes more easily.

Thanks for your consideration.

-Rob Ryan

[PatrickGotthard]

I moved this issue to the next version because upgrading the HttpClient requires updating plenty lines of code. In addition this change will break backwards compatibility. Actually we should concentrate on version 1.6.0 without performing such massive changes

[mschipperheyn]

First of all, httpclient 3.1 is obsolete and EOL (they say so themselves). So the massive changes (I think it's an exaggeration) should be made as soon as possible. Furthermore, httpclient 3.1 has known vulnerabilities that are no longer addressed because its EOL. I think its high time this library finally gets some love in the EOL dependencies department. Totally frustrating to see this not being addressed.

[mishako]

@mschipperheyn Feel free to submit a pull request!

@PatrickGotthard Regarding backwards compatibility, they switched to a new package (org.apache.commons.httpclient → org.apache.http) so we could keep old fetcher and add a new one (something like HttpClient4FeedFetcher) thus preserving backwards compatibility. Right?

[PatrickGotthard]

@mschipperheyn I just wanted to ask you to submit a pull request too. This is an opensource project and we spend our rare free time for it ;)

@mishako good proposal. When the package has changed, we are able to provide HttpClient 4 support without breaking backwards compatibility. We should also mark the old HttpClient dependency as optional so that it wouldn't pollute the users classpath.

[mschipperheyn]

Well, I would love to work on this and put my money where my mouth is, however, I'm swamped and there are some other open source projects where I help out. I'd be happy to test it against our production platform when it becomes available. I do understand the open source aspect, but in all honesty, this issue has been open for years now and I feel exposed with a platform with known security vulnerabilities and an apparent non interest in addressing these issues.

[mishako]

@mschipperheyn
I don't want to start an argument. Especially since I think we will be able to fix this quite soon, not least thanks to your comment. You facilitated the discussion and we are grateful that you drew our attention to the importance of the old vulnerable HTTP client being EOL.

I can’t help but wonder though, why do you expect others to prioritize the issue when you’re not prioritizing it yourself? I mean, you’re clearly stating that there are other things that you spend your time on, i.e. things that are more important for you. Why do you think that other people are different and, unlike you, are supposed to address the issue?

I guess what I’m looking for is ”Hey guys, I think this issue is very important, could you please prioritize it?” instead of ”Totally frustrating to see this not being addressed. This issue has been open for years now”.

[mschipperheyn]

I understand your criticism although i dont agree with all of it.

Yes, this is open source so if u dont like something do something about it.

Well, i doncontribute to a number of projects.sometimes in code and also often by testing, reporting issues and suggesting features

I cant contribute to everything in code for lack of time or expertise. And i use and am thankfulnfor many projects includi g yours

I also think that hosting a project brings w it responsibilitie. One of those in my mind is fixing security issues. If those cant be addressed for a very long time for whatever reason i feel this exposes users to unknown risks and perhaps should lead to the conclusion I dont have time for this.sorry this projectis dead.

My frustration and snarky remarks come from this wait. I dont mean to be a d*** , im just trying to provoke a change. All the best

[mishako]

I see where our disagreement lies. You think that some people (those who are hosting the project) have more responsibility than others, whereas I think that all the people in the world bear equal responsibility. Can you elaborate on what you mean with "hosting a project"? Who are those hosting the project? At what point do they become responsible for fixing security issues?

[PatrickGotthard]

Hi @ALL,

independent from this issue we have discussed about the future of rome-fetcher. We decided to drop rome-fetcher in the next major (2.0) release. Until that we will only fix security bugs that doesn't break backwards compatiblity. Implementing support for HttpClient v4 makes no sense in this case because the user would have to migrate his application. I have added an additional security warning to the HttpClientFeedFetcher that uses the vulnerable HttpClient v3. For more information have a look at #276

Regards,
Patrick

[puntogil]

Hi
this means which also rome-certiorem rome-propono should be removed?

[mishako]

@PatrickGotthard
I agree with @puntogil. Also rome-certiorem-webapp.

[mishako]

@PatrickGotthard What are your thoughts on deprecating rome-certiorem, rome-certiorem-webapp and rome-propono?

[PatrickGotthard]

@mishako Yes, we should mark them as deprecated and concentrate on rome-core, rome-modules and rome-opml.