Picking up a few threads that I think others might have missed, and which I think are worthy of acknowledgement…
On Thu, 12 Oct 2023 at 05:16, Eric D Hendrickson via Cygwin <cygwin@cygwin.com> wrote: > How does Cygwin being an all volunteer effort have any bearing on this > question, other than the time and interest of the volunteers? The fact that this is a volunteer effort doesn't have much direct bearing. But the fact that we're volunteers means that time and interest are very finite quantities. There are really not many folk involved in actually making Cygwin, and I think everyone actively involved in the project already has a wishlist of things they'd do if they had the time. > Perhaps the volunteer team should consider adopting a process of evaluating > the support status of every package it redistributes, even at the expense > of slowing down the rate of releases. Or dropping packages when no one has > the time or interest in creating a package from a supported version of the > tool in question. Packages do get dropped from the distribution occasionally when they're no longer being updated and no longer viable. I don't believe there's any comprehensive package-by-package review, because that's a lot of work, and it's not even very interesting work. But if someone provides a reason a specific package should be dropped, it can happen. The mere fact that a package no longer has upstream support is probably not enough, though; I expect we'd need no upstream support and either a genuine significant vulnerability in the package, or availability of a viable replacement. > Again for the benefit of Cygwin as a whole - distributing EOL packages > could put Cygwin as a whole at risk, which I'm sure you would agree is much > worse than dropping a package from the suite. I don't agree. If Cygwin mandated that packages be kept rapidly up-to-date or be dropped, I expect Cygwin would rapidly become unusable. A lot of our package maintainers – myself included – are only able to work on Cygwin as and when they have the time. If the project required maintainers to spend a regular amount of time on their packages, which a reliable update schedule would require, I expect a lot of us would just stop contributing. When there are vulnerabilities identified, we can and do move quickly to mitigate them. The fact that there's some EOL products available through Cygwin is at least in part because there aren't any significant security vulnerabilities that we're aware of. It would, of course, be nice if the cutting edge were available for everything, but that has its own disadvantages: rapid release cycles have more chance of introducing new bugs. There's a reason plenty of people use Debian Stable; there's lots of critical infrastructure still running on Python 2. (But, of course, the package in question here is actually reasonably up-to-date: as Yasuhiro Kimura noted, the Cygwin mirrors are distributing ruby 3.2.2-2, which has an advertised upstream EOL date of March 2026. So a possibly more useful question is why *you* are deploying an EOL version when more up-to-date versions are available! To investigate that, I think we'd need a useful bug report explaining what you're doing to get an install with such an old version.) I also think it's worth remembering the use case for Cygwin. Cygwin is designed to provide a *nix-like environment for Windows users, with relatively little effort required to port software that was originally written for *nix systems. The sorts of use cases where you really care about most zero-day vulnerabilities aren't ones where I'd expect Cygwin to be in use; if you have a public-facing web server, for example, using Cygwin is a bad idea, not just because of the security concerns, but also because Cygwin makes a lot of compromises around performance, and you're likely to have a vastly better experience using a Windows-native or Linux-native web server. > This goes back to my other question - > > Is there an Issues log or backlog a la GitHub where bugs / enhancement > requests / feature suggestions like this can be logged for future > consideration / evaluation, instead of one off discussions in this > ephemeral medium of email? Email isn't ephemeral: everything sent to this mailing list is archived indefinitely. You can browse and search the archives at https://cygwin.com/lists.html. That said, there is a reason folk use bug trackers. There's no central bug tracker for Cygwin; individual maintainers may have their own systems for tracking problems (I use GitHub), but there's no mandate about what to use or how to use it. Even if we had someone willing to set one up and maintain one, migrating to a central bug tracker is a very significant amount of work, and it's not work that many people would find fun or interesting. If you want to help, there's a list of packages that don't have maintainers at http://www.cygwin.com/packages/reports/unmaintained.html – if you'd be willing to adopt one of those and keep it a bit more up-to-date, that's likely to be very well received. If there are packages not on that list but which you think need updating, you could offer to help the maintainer with getting them up-to-date, or – if the maintainer is unresponsive for any reason – offer to produce an update to be packaged as a non-maintainer-upload. The general guidance on how to manage Cygwin packages as a maintainer is at https://cygwin.com/packages.html. More general advice on contributing to Cygwin is at https://cygwin.com/contrib.html. Conversely, asking people to do more work, for free, tends not to go down well. You did offer to help – thank you! – but asking for folk to tell you how to help is itself asking other people to do work for you. All the links in the previous paragraph are ones that can be found in one or two clicks from the Cygwin home page, and while http://www.cygwin.com/packages/summary/ruby.html is a little harder to find, it clearly shows that one of your key assumptions – that Cygwin is distributing a version of ruby with no upstream support – is only true if you include cases where someone is deliberately choosing to use an old version. This is a community that tends to be much more supportive when people show they've done at least some initial investigations themselves. We do want and need more people contributing to Cygwin; new volunteers are genuinely great. Hopefully all the above is useful for you and for the archives about how to usefully contribute. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
