Giters

square / retrofit

A type-safe HTTP client for Android and the JVM

Home Page:https://square.github.io/retrofit/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Summary: New maintenance release | projects state | vulnerabilities in dependencies (CVE's)

Lonzak opened this issue · comments

commented

First I would like to express my gratitude to all of the project maintainers who kept and keep working on this project. It is heavily used so your work is appreciated.

Originally I just came here to confirm that this project is dead but then surprisingly I saw that this is not the case. After a bit of digging I found lots of requests / pleas for an update for different reasons. Over a year ago some has been summarized here and in countless other tickets. I will try to summarize and categorize some of them here.
It would be appreciated if this ticket would not be closed too quickly - then others don't need to open new tickets for their update request. This will thus hopefully save you some time which could be spent on more important things...

Reason for not updating (yet):
Some answers which were given:

"We will release when we release. This library has not been a priority recently, but is otherwise stable and working.
In general, both in the past over the history of the project and in the future, we will never do a release to solely address an issue bump for a transitive dependency. Those come along for the ride with new features and bug fixes within this library."

and

"Unfortunately the project isn't quite in a state that I'm comfortable releasing so it requires some time to get back to a releasable state."

and

"I'm on paternity leave. Perhaps when I get back."

Many maintainers contribute and maintain in their (private) spare time. This can not be stressed enough and deserves respect.

But I also see that three years of "bug fixes and maintenance" would and should be quite a reason to make a maintenance release.
Due to supply-chain attacks, transitive dependencies become more and more important and critical. Those third party dependencies belong to a project because they are distributed along with it. (Just look at all the projects which were updated due to the bug in log4j...)

Sure there are mechanisms to manually or automatically exclude them but it means always extra effort to do so. Our project for instance has way over 100 dependencies and each unmaintained lib means additional work (and discussion with the security guys etc.). And this is only the security side. There are bugs listed below which need manual intervention to circumvent those.
In the end we are all just trying to say that the community would appreciate a maintenance release from time to time :-) (where time < 3 years)

Now a list of tickets follows which (for different reasons) all have the same topic:

Vulnerabilities in (transitive) dependencies

Bugs (excerpt):

General Project state questions:

commented

Thank you for this write-up. I'd like to add another point in response to:

"Unfortunately the project isn't quite in a state that I'm comfortable releasing so it requires some time to get back to a releasable state."

Anyone who has required Retrofit changes from the past 3 years has probably been relying on version 2.10.0-SNAPSHOT. This is the case in my own projects.

No matter the current state of the project, surely it's better to provide stability through an official release than to have consumers increasingly rely on volatile Snapshot versions?

Thanks again to the maintainers for all their hard work on this.

commented

Anyone who has required Retrofit changes from the past 3 years has probably been relying on version 2.10.0-SNAPSHOT

For our organization, relying on a SNAPSHOT build in a production deploy is banned. So the only way we could access these changes is either by forking the repo and releasing periodically or by forcing up transitive dependencies. So far we've been pushing forward the transitive dependencies.

This is one of my favorite http clients and I love all the work that's gone into it. A release would be very appreciated.

commented

Today version 2.9.0 celebrates its 3 year and 6th month anniversary! 🥳🎉🥂
Hope that it'll have a short life ahead of it 😆

commented

Time to find a Retrofit alternative?

commented

For ones who need this support, you can try out my fork, use io.github.goooler.retrofit2:retrofit:2.10.0, check https://github.com/Goooler/retrofit/releases/tag/2.10.0

commented

I must say that this is the only library that I have been able to integrate with any kind of project whether very old or recent, I really hope it is not abandoned altogether.

commented

In the issue you have linked to two separate places where I discussed the status and yet still needed to file an additional issue? I don't like repeating myself.

I really hope it is not abandoned altogether.

It isn't!

commented

For an instant I thought when I saw the notification mail that there is a new release. Unfortunately that is not the case and even worse the ticket is closed as [not planned] 😞

In the issue you have linked to two separate places where I discussed the status and yet still needed to file an additional issue? I don't like repeating myself.

You can be certain - I won't open any ticket again. But did you read the ticket?

I will try to summarize and categorize some of them here. [...] then others don't need to open new tickets for their update request. This will thus hopefully save you some time which could be spent on more important things...

Since I opened that "summery" ticket there have been drastically less tickets asking for a new versions / updated deps / security vulnerabilities and the like. Most people usually don't search closed tickets... But you'll see: since this ticket is closed now such requests will start popping up again.

It isn't!

and

not planned

Doesn't fit together imho. Time for me to migrate.

commented

Update: Something happened: Two updates within one week?!

Update II:
I checked the version and some (vulnerable) dependencies have been upgraded, however some remain.
It still depends on okhttp 3.14.9 which in turn uses the old okio 1.17.2. The reason for not upgrading okhttp are described here and here.

Remaining issues:

okio

okio Okio GzipSource DOS (CVSS Base score: 7.5)
CVE-2023-3635
=> Fixed in okio 1.17.6

JUnit (doesn't matter since only for testing)
CVE-2020-15250

okhttp

CVE-2023-0833
=> Fixed in okhttp 4.9.2