From 4 trivial memory overflows reported 1 year ago, as of now with rsocket/rsocket-java 1.1.2 one ([1]) was accepted & fixed, 3 were ignored ([1], [2], [3]), and recent keep-alive related one (described in section #3 on Medium) was deleted without explanation.
There is some lack of consistency in handling these, so I am wondering what is the "official" stance of the spring team (whose members seem like maintain rsocket/rsocket-java, and recently integrated It with spring-graphql) regarding above issues, given that SpringBoot is major and only application framework having rsocket-java integrations.
Comment From: bclozel
I think the main problem here is that issues are not reported as they should. #27373 has been declined and re-opened against rsocket-java directly. If the problem can be reproduced without Spring Framework being involved, this should be fixed in rsocket-java.
Creating issues here are just likely to get declined and not reported properly to the rsocket team. Additionally, if you believe you've found a security issue this should be reported responsibly.
While some team members here are involved with rsocket-java, this issue tracker is understandably dedicated to Spring Framework issues only. I'll leave your other issues opened for now but if you think the problem lies in rsocket-java, you should close them and reopen them against the right project.
Thanks!
Comment From: mostroverkhov
If the problem can be reproduced without Spring Framework being involved, this should be fixed in rsocket-java.
@bclozel The purpose of issue was more for clarification why rsocket/rsocket-java - poorly maintained and arguably vulnerable library keeps being pushed through SpringBoot onto end users, less for genuine interest in rsocket/rsocket-java itself.
It also explains why this was originally opened onspring-boot issue tracker - spring-boot is the source from which I, as well as most of the java/spring users get rsocket-java as transitive dependency of several significant projects - and expect transitive dependencies are at least safe to use.
I think It is up to spring-boot team how latter gets achieved: upstream fix (conveniently, spring team has people with push access rights there) or phase out. Declaration as non-issue is not helpful because of how trivially outlined problems may be demonstrated in practice: https://github.com/mostroverkhov/springboot-repros.
reported properly to the rsocket team
Previous interactions were mostly not fruitful - seems like current maintainers are not interested accepting responsibility for delivered projects.
Comment From: bclozel
Raising bogus issues with both Spring Framework and Spring Boot is not making your case but just wasting our time.
The Spring Framework team trusts the rsocket-java team and the community to make the right decisions. We're pretty happy about the integrations so far and get positive feedback from developers.
Please understand that your comments here are not helping; I would suggest to start engaging with the rsocket-java community in a respectful manner, and trust the process.