Ruby EOL in Cygwin 3.4.9?

[Adam Dinwoodie]

On Thu, 12 Oct 2023, 22:46 Eric Hendrickson wrote:
> 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.

To pick a fairly high-profile example, Debian Bullseye was released as
Debian Stable on 14 August 2021.  It included Python 2.7, which by that
time had been EOL for more than 18 months, with the EOL date having been
announced over seven years earlier.

https://www.debian.org/releases/bullseye/
https://packages.debian.org/bullseye/python2
https://peps.python.org/pep-0373/

More generally, lots of OSS projects don't provide support for anything
other than their most recent release, and Debian Stable includes lots of
that software at releases other than the most recent release.  If Debian
had the policy you're asserting it has, the concept of Debian Stable
would be impossible.

> 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.

Here, the comparison with Debian Stable *is* unhelpful.  The concept of
"versions of Cygwin" that you're using doesn't make sense: unlike
Debian, Cygwin doesn't have an overarching version scheme.  There's no
such thing as "a version of Cygwin" that we could stop releasing because
of problems with a particular package.

We could implement a block on releasing any packages while one package
has a problem.  That seems like a terrible idea to me; I'd be happy to
discuss it -- I might be wrong! -- but I'm much more interested in
having that discussion with people who have been actively contributing
to Cygwin for some time, as they're the folk who are most likely to
understand what the advantages and disadvantages might be, and who I
trust to be willing to provide practical contributions towards the
additional work they're proposing.  At the very least, I'd want that
discussion to be based on something more significant than a nebulous
concept of the project's reputation.

> 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)

What do you mean by "provisioned"? What do you mean by "the Cygwin
package"?

If you download the Cygwin installer from the Cygwin website, and ask it
to install Ruby, it will install 3.2.2. You *can* install 2.6.4, but
you'd have to deliberately select that version.

If you are seeing the Cygwin installer trying to install Ruby 2.6.4 by
default, that sounds like an installer bug.  If that's what's happening,
please give us a useful bug report so we can work out what's going
wrong.

However, if your concern is merely that it's *possible* to install EOL
software, I don't think that concern will be widely shared.  If someone
wants to install old software, or configure an SSH server with a root
password of "password1", or otherwise go out of their way to do
something that's not ideal from a security perspective, I don't think we
have a responsibility to stop them.

You might have better luck petitioning the Ruby project to remove the
download links for out-of-support software from their releases page,
which offers versions of Ruby that have been out of support for over a
decade.

https://www.ruby-lang.org/en/downloads/releases/

Thankfully, as you say, security scans are only increasing in frequency
and scrutiny, and they are evidently capable of catching scenarios where
someone has deliberately installed out-of-date software.

> 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.

I say this because I think your concern is genuine: you are coming
across as concern trolling.

Some of your logic is demonstrably false, as with your claims about
Debian project policies.  Some of your problems are unclear, as with
your explanation of "the Cygwin package" being "provisioned with an EOL
version of Ruby".  I understand that you've not found many of the
replies to you to be kind, but that's largely because you haven't shown
us the kindness of clearly explaining your issue or showing you've done
any research into the issue yourself.

If you are concerned about the reputation of Cygwin, I'd suggest you
follow Glenn's excellent advice from earlier in this thread: provide
specific offers to help improve Cygwin, rather than merely expressing
concerns and asserting we should eject people who have spent years
actively contributing to improve Cygwin's reputation.  There have been
several suggestions of ways you can support the project throughout this
email chain.