Re: Ruby EOL in Cygwin 3.4.9?

[Eric Hendrickson <ericdavidhendrickson@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 8885 bytes --]

Thank you, Adam, for your constructive response.

So, I hear what you are saying of course. I’m not asking people to do more work, I was just asking if these factors (EOL software) are important to Cygwin. I realize that’s nuanced but nevertheless this is so.

The comparison to Debian Stable - I hear you but I don’t think that is a fair comparison. Debian Stable is not shipping EOL packages at the time it was released.

And your point about the effort involved and no known bugs is well taken of course but Cygwin is still distributing EOL software.  This is why I asked, would it make sense to just not release new non emergency versions of Cygwin with EOL packages, until that can be remedied.

But again I get the amount of work required. That’s helpful. I do think pausing releases or even targeting getting all packages updated in tranches perhaps, it would take a lot of work the first pass but then going forward keeping it current might not be so impactful to the normal release process.

I just worry about the reputational impact to Cygwin if releasing EOL software in this day and age were there a 0day or something and here this version of Cygwin was just released recently…

Security scans are only increasing in scrutiny and frequency - this came to my attention because in my environment we are running Cygwin 3.1.6 - which admittedly is 3+ years old - and the version of Ruby packaged in it got identified in a security scan as EOL.

My first thought was to update the internal Cygwin package to the latest but i checked and that too is provisioned with an EOL version of Ruby. (2.6.4)

Anyway, just wanted to bring this to your attention and ask if there is anything that can or should be done about this, again toward the reputation of Cygwin.

Appreciate your time and sharing.

Thank you,
Eric

Sent from Outlook<https://aka.ms/qtex0l> on my Tricorder
________________________________
From: Adam Dinwoodie <adam@dinwoodie.org>
Sent: Thursday, October 12, 2023 1:22 PM
To: Eric D Hendrickson <ericdavidhendrickson@gmail.com>
Cc: gs-cygwin.com@gluelogic.com <gs-cygwin.com@gluelogic.com>; Hendrickson, Eric D <edh@optum.com>; cygwin@cygwin.com <cygwin@cygwin.com>
Subject: Re: Ruby EOL in Cygwin 3.4.9?

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.