I admit I get a bit heated up so I'm sorry if it all sounds a bit harshly worded, but my perspective is that every time I hop into my jenkins install to build some binaries there is another red or yellow popup about yet another thing that has gone away or is broken and I'm fairly convinced something in jenkins leaked my smtp credentials last year which was a fun two weeks to track down, so I am mildly cranky at the fact something that I keep up to date and try my best to maintain keeps throwing curveballs made of lead into my face.
It's rather fragmenting to not utilize the issue tracking github has built in. Jira only offers issue tracking, pull requests still have to happen on github and will likely incur comments there so that creates a huge mess. I would have loved to just open an issue on github, inquire as to what exactly is broken on the plugin as the security information doesn't list the actual vectors or parts the vulnerabilities were found in and from there work out if my java is sufficiently rust-free to try and resolve them or at least get some opinions on how to best to that.
I see open source as a community effort and not just a "request to take over doing all the work" on a plugin used by enough people that even just 1% of them ought to have enough collective graymatter to figure out a solution to the problems at hand if they are known and documented.
What irks me the most is there is a security team capable of finding these vulnerabilities in the first place, which means they must have enough experience to give the information necessary to find the parts of the code responsible, but I can't manage to find that. What's the deal here? I have to request permission first and then might get a detailed report from them? I get the idea that opening this up means a roadmap to destruction, but anyone capable of exploiting that or deriving merit from it probably doesn't even need that to know what to do given the name of the security vulnerability alone. It's two edged sword as well, knowing the way in means I can at least attempt other means of throwing stones in the way.
The problem is you exercise editorial control based on analysis that only publish the findings and neither the process nor more detailed information, so what's to say after I spend the time and money to update a plugin you don't reject it because something else doesn't meet standard. The entire setup then just creates a feeling to me that while the project has high standards for the software itself there aren't many willing to spend the effort to satisfy them, hence plugins get abandoned as the workload to fix them without information and just curveballs their direction certainly isn't fun. I mean how would you feel if the work you did was for nothing because the plugin just gets removed. It says to make an effort to contact the original author of the plugin, which should be something the project should do if it doesn't already. Getting a report as the author on what I have to do to avoid delisting of the plugin based on the findings I would assume is done? It just looks strange to me; The amount of abandoned plugins with high install numbers just looks strange from the outside. Not to mention then the promotion of other plugins developed by the jenkins team as alternative when they really might not be depending on pipeline configuration.
It gets even worse when there is security notifications and whatnot popping up more and more lately and I find jenkins leaking data left right and center yet cannot identify which plugin or part is causing it because any hints from the security advisories just show me vectors but not how to test or work around them if applicable at all. I'm no java dev and infosec is not my primary, but it seems that is the baseline for operating jenkins nowadays as I effectively have to pentest the thing now to see what's what. Certainly the documentation on how to properly secure jenkins only mentions what to do in setup, but not how to identify or test it for leaks. So I am left just having to poke around in the dark or setup jenkins without outside connections to anything it receives or sends data to in order to protect things. At that point I might just stop using it and integrate the pipelines through bash or python scripts. It just kills the flexibility of jenkins, which is the one thing it still has going for it over other options. Shouldn't the focus be on retaining that.
Reading some of the Jira I get a really strange sensation. There are so many good suggestions and even straight up full guidebooks on how to fix something up or change it for the better, but a lot of it just sits there. The other big issue that I participated, contributed and discussed on here is still unresolved open and even after the consensus that a lot of the suggestions would work at least better than the current setup nothing was done and that was entirely in your ballpark mind you.
I know it sounds demanding and condescending given the open source and volunteer nature of the project, but such is the nature of it all. The projects I release in the wild get the same responses of users complaints and issues, yet I still derive satisfaction from resolving them and seeing the continued use. I'll happily work on reported issues with detailed information that make resolving things a lot easier when I don't have to dig around in the dark. I don't even see any contribution outside of that nor any gracious donations to work on features, which should never be the sole reason to work on something anyways. Perhaps the approach of "pay for it and I'll do it" would result in funds I could now throw at this issue, but I still, naively perhaps, believe that sheer merit of something is enough to warrant work on something.
What's the stance then on the abandonment of plugins and the eventual ecosystem this creates around jenkins. Isn't the plugin ecosystem half of what makes jenkins useful in the first place given it otherwise just builds maven and nothing else really. Shouldn't the objective be ease of adoption or at least making it easy to contribute, if not code, brain matter to resolving issues that come up. Remember what makes development easy in the first place, information. Reproducing issues with detailed instructions, pointing to exact error messages with line numbers, researching potential fixes from other sources, all that is something that can be contributed to plugin development outside of code and it might make one consider adoption with the work ahead clearly laid out instead of being a total blackbox you have to pick apart yourself.
Long story short then, what's the workload to fix the plugin up as it is now? Cost estimate, reproduction steps from the security team, standard you want it to follow etc. I'll happily throw something into the pot, but if I don't even know if it'll account for 10% of what's needed for a fix then I'd much rather get a nice dinner from that and find other means of distributing build artifacts.