Ruby EOL in Cygwin 3.4.9?

Ruby EOL in Cygwin 3.4.9?

[Hendrickson, Eric D]

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

Hello all,

As a ~25 year user and sometime contributor to Cygwin, I support Cygwin here at my place of work.  Does anyone know why we are deploying Ruby 2.6 which EOL about 18 months ago?

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

I'm concerned about proliferation of EOL versions of Ruby in case some security risk / 0Day is identified.

Please advise.
Eric Hendrickson

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or intended recipient’s authorized agent, the reader is hereby
notified that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.

Re: Ruby EOL in Cygwin 3.4.9?

[Eliot Moss]

On 10/11/2023 12:37 PM, Hendrickson, Eric D via Cygwin wrote:
> Hello all,
> 
> As a ~25 year user and sometime contributor to Cygwin, I support Cygwin here at my place of work.  Does anyone know why we are deploying Ruby 2.6 which EOL about 18 months ago?
> 
> https://www.ruby-lang.org/en/downloads/branches/
> 
> I'm concerned about proliferation of EOL versions of Ruby in case some security risk / 0Day is identified.
> 
> Please advise.
> Eric Hendrickson

If nobody has responded I can give a generic response:
"Because cygwin is all volunteer and someone has not volunteered,
or did volunteer and is behind, or fell off the radar."

Someone else will know how to look up if there is a currently
registered volunteer for Ruby ...

Eliot Moss

> This e-mail, including attachments, may include confidential and/or
> proprietary information, and may be used only by the person or entity
> to which it is addressed. If the reader of this e-mail is not the intended
> recipient or intended recipient’s authorized agent, the reader is hereby
> notified that any dissemination, distribution or copying of this e-mail is
> prohibited. If you have received this e-mail in error, please notify the
> sender by replying to this message and delete this e-mail immediately.
> 

RE: Ruby EOL in Cygwin 3.4.9?

[Hendrickson, Eric D]

Hi Eliot,

Thanks for responding.  That makes total sense.  

Totally taking into account the all volunteer nature of Cygwin, would it make sense to defer on further non-emergency releases of Cygwin until all packages that are EOL have been updated?  Since this is the case with ruby, I am guessing it's likely the case with other packages in Cygwin too.

Is there a backlog for Cygwin somewhere, so that I can investigate this myself if I have time this winter?

Thank you and all the best,
Eric

-----Original Message-----
From: Eliot Moss <moss@cs.umass.edu> 
Sent: Wednesday, October 11, 2023 5:03 PM
To: Hendrickson, Eric D <edh@optum.com>; cygwin@cygwin.com
Cc: Eric @ Gmail <ericdavidhendrickson@gmail.com>
Subject: Re: Ruby EOL in Cygwin 3.4.9?

On 10/11/2023 12:37 PM, Hendrickson, Eric D via Cygwin wrote:
> Hello all,
> 
> As a ~25 year user and sometime contributor to Cygwin, I support Cygwin here at my place of work.  Does anyone know why we are deploying Ruby 2.6 which EOL about 18 months ago?
> 
> https://www.ruby-lang.org/en/downloads/branches/
> 
> I'm concerned about proliferation of EOL versions of Ruby in case some security risk / 0Day is identified.
> 
> Please advise.
> Eric Hendrickson

If nobody has responded I can give a generic response:
"Because cygwin is all volunteer and someone has not volunteered, or did volunteer and is behind, or fell off the radar."

Someone else will know how to look up if there is a currently registered volunteer for Ruby ...

Eliot Moss

> This e-mail, including attachments, may include confidential and/or 
> proprietary information, and may be used only by the person or entity 
> to which it is addressed. If the reader of this e-mail is not the 
> intended recipient or intended recipient’s authorized agent, the 
> reader is hereby notified that any dissemination, distribution or 
> copying of this e-mail is prohibited. If you have received this e-mail 
> in error, please notify the sender by replying to this message and delete this e-mail immediately.
> 

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or intended recipient’s authorized agent, the reader is hereby
notified that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.

Re: Ruby EOL in Cygwin 3.4.9?

[Yasuhiro Kimura]

From: "Hendrickson, Eric D via Cygwin" <cygwin@cygwin.com>
Subject: Ruby EOL in Cygwin 3.4.9?
Date: Wed, 11 Oct 2023 16:37:29 +0000

> Hello all,
> 
> As a ~25 year user and sometime contributor to Cygwin, I support Cygwin here at my place of work.  Does anyone know why we are deploying Ruby 2.6 which EOL about 18 months ago?
> 
> https://www.ruby-lang.org/en/downloads/branches/
> 
> I'm concerned about proliferation of EOL versions of Ruby in case some security risk / 0Day is identified.
> 
> Please advise.
> Eric Hendrickson

On my environment version of Ruby is 3.2.2.

(Cygwin64)yasu@rolling[1005]% uname -a                                                                                      ~
CYGWIN_NT-10.0-22621 rolling 3.4.9-1.x86_64 2023-09-06 11:19 UTC x86_64 Cygwin
(Cygwin64)yasu@rolling[1006]% type ruby                                                                                     ~
ruby is /usr/bin/ruby
(Cygwin64)yasu@rolling[1007]% ruby --version                                                                                ~
ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-cygwin]
(Cygwin64)yasu@rolling[1008]%

I use https://ftp.iij.ad.jp/pub/cygwin as download site and there are
surely ruby-3.2.2-2.hint, ruby-3.2.2-2.tar.xz, ruby-3.2.2-2-src.hint
and ruby-3.2.2-2-src.tar.xz under
https://ftp.iij.ad.jp/pub/cygwin/x86_64/release/ruby/.

So I guess download site you use is out of sync.

---
Yasuhiro Kimura

Re: Ruby EOL in Cygwin 3.4.9?

[Eliot Moss]

On 10/11/2023 6:36 PM, Hendrickson, Eric D wrote:
> Hi Eliot,
> 
> Thanks for responding.  That makes total sense.
> 
> Totally taking into account the all volunteer nature of Cygwin, would it make sense to defer on further non-emergency releases of Cygwin until all packages that are EOL have been updated?  Since this is the case with ruby, I am guessing it's likely the case with other packages in Cygwin too.
> 
> Is there a backlog for Cygwin somewhere, so that I can investigate this myself if I have time this winter?
> 
> Thank you and all the best,
> Eric
> 
> -----Original Message-----
> From: Eliot Moss <moss@cs.umass.edu>
> Sent: Wednesday, October 11, 2023 5:03 PM
> To: Hendrickson, Eric D <edh@optum.com>; cygwin@cygwin.com
> Cc: Eric @ Gmail <ericdavidhendrickson@gmail.com>
> Subject: Re: Ruby EOL in Cygwin 3.4.9?
> 
> On 10/11/2023 12:37 PM, Hendrickson, Eric D via Cygwin wrote:
>> Hello all,
>>
>> As a ~25 year user and sometime contributor to Cygwin, I support Cygwin here at my place of work.  Does anyone know why we are deploying Ruby 2.6 which EOL about 18 months ago?
>>
>> https://www.ruby-lang.org/en/downloads/branches/
>>
>> I'm concerned about proliferation of EOL versions of Ruby in case some security risk / 0Day is identified.
>>
>> Please advise.
>> Eric Hendrickson

You should send such things to the list, not me.  I'm just
a user who has only made occasional small contributions ...

Eliot

> If nobody has responded I can give a generic response:
> "Because cygwin is all volunteer and someone has not volunteered, or did volunteer and is behind, or fell off the radar."
> 
> Someone else will know how to look up if there is a currently registered volunteer for Ruby ...
> 
> Eliot Moss
> 
>> This e-mail, including attachments, may include confidential and/or
>> proprietary information, and may be used only by the person or entity
>> to which it is addressed. If the reader of this e-mail is not the
>> intended recipient or intended recipient’s authorized agent, the
>> reader is hereby notified that any dissemination, distribution or
>> copying of this e-mail is prohibited. If you have received this e-mail
>> in error, please notify the sender by replying to this message and delete this e-mail immediately.
>>
> 
> This e-mail, including attachments, may include confidential and/or
> proprietary information, and may be used only by the person or entity
> to which it is addressed. If the reader of this e-mail is not the intended
> recipient or intended recipient’s authorized agent, the reader is hereby
> notified that any dissemination, distribution or copying of this e-mail is
> prohibited. If you have received this e-mail in error, please notify the
> sender by replying to this message and delete this e-mail immediately.

Re: Ruby EOL in Cygwin 3.4.9?

[Eric D Hendrickson]

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

Sorry for the unclarity - I meant this for the whole list - not just you.

Thank you so much for taking the time to respond.  Like you said, this
really is all volunteers.

For the whole list:

Totally taking into account the all volunteer nature of Cygwin, would it
make sense to defer on further non-emergency releases of Cygwin until all
packages that are EOL have been updated?  Since this is the case with ruby,
I am guessing it's likely the case with other packages in Cygwin too.

Is there a Issues log of some sort (ala github) for Cygwin somewhere, so
that I can document this in the backlog and come back later to investigate
this myself if I have time this winter?


On Wed, Oct 11, 2023 at 8:11 PM Eliot Moss <moss@cs.umass.edu> wrote:

> On 10/11/2023 6:36 PM, Hendrickson, Eric D wrote:
> > Hi Eliot,
> >
> > Thanks for responding.  That makes total sense.
> >
> > Totally taking into account the all volunteer nature of Cygwin, would it
> make sense to defer on further non-emergency releases of Cygwin until all
> packages that are EOL have been updated?  Since this is the case with ruby,
> I am guessing it's likely the case with other packages in Cygwin too.
> >
> > Is there a backlog for Cygwin somewhere, so that I can investigate this
> myself if I have time this winter?
> >
> > Thank you and all the best,
> > Eric
> >
> > -----Original Message-----
> > From: Eliot Moss <moss@cs.umass.edu>
> > Sent: Wednesday, October 11, 2023 5:03 PM
> > To: Hendrickson, Eric D <edh@optum.com>; cygwin@cygwin.com
> > Cc: Eric @ Gmail <ericdavidhendrickson@gmail.com>
> > Subject: Re: Ruby EOL in Cygwin 3.4.9?
> >
> > On 10/11/2023 12:37 PM, Hendrickson, Eric D via Cygwin wrote:
> >> Hello all,
> >>
> >> As a ~25 year user and sometime contributor to Cygwin, I support Cygwin
> here at my place of work.  Does anyone know why we are deploying Ruby 2.6
> which EOL about 18 months ago?
> >>
> >> https://www.ruby-lang.org/en/downloads/branches/
> >>
> >> I'm concerned about proliferation of EOL versions of Ruby in case some
> security risk / 0Day is identified.
> >>
> >> Please advise.
> >> Eric Hendrickson
>
> You should send such things to the list, not me.  I'm just
> a user who has only made occasional small contributions ...
>
> Eliot
>
> > If nobody has responded I can give a generic response:
> > "Because cygwin is all volunteer and someone has not volunteered, or did
> volunteer and is behind, or fell off the radar."
> >
> > Someone else will know how to look up if there is a currently registered
> volunteer for Ruby ...
> >
> > Eliot Moss
> >
> >> This e-mail, including attachments, may include confidential and/or
> >> proprietary information, and may be used only by the person or entity
> >> to which it is addressed. If the reader of this e-mail is not the
> >> intended recipient or intended recipient’s authorized agent, the
> >> reader is hereby notified that any dissemination, distribution or
> >> copying of this e-mail is prohibited. If you have received this e-mail
> >> in error, please notify the sender by replying to this message and
> delete this e-mail immediately.
> >>
> >
> > This e-mail, including attachments, may include confidential and/or
> > proprietary information, and may be used only by the person or entity
> > to which it is addressed. If the reader of this e-mail is not the
> intended
> > recipient or intended recipient’s authorized agent, the reader is hereby
> > notified that any dissemination, distribution or copying of this e-mail
> is
> > prohibited. If you have received this e-mail in error, please notify the
> > sender by replying to this message and delete this e-mail immediately.
>
>

-- 
Good government never depends upon laws, but upon the personal qualities of
those who govern. The machinery of government is always subordinate to the
will of those who administer that machinery. The most important element of
government, therefore, is the method of choosing leaders.
 -- Law and Governance, The Spacing Guild Manual, Children of Dune

Re: Ruby EOL in Cygwin 3.4.9?

[gs-cygwin.com]

On Wed, Oct 11, 2023 at 09:55:04PM -0500, Eric D Hendrickson via Cygwin wrote:
> Sorry for the unclarity - I meant this for the whole list - not just you.
> 
> Thank you so much for taking the time to respond.  Like you said, this
> really is all volunteers.
> 
> For the whole list:
> 
> Totally taking into account the all volunteer nature of Cygwin, would it
> make sense to defer on further non-emergency releases of Cygwin until all
> packages that are EOL have been updated?  Since this is the case with ruby,
> I am guessing it's likely the case with other packages in Cygwin too.
> 
> Is there a Issues log of some sort (ala github) for Cygwin somewhere, so
> that I can document this in the backlog and come back later to investigate
> this myself if I have time this winter?
> 
> 
> On Wed, Oct 11, 2023 at 8:11 PM Eliot Moss <moss@cs.umass.edu> wrote:
> 
> > On 10/11/2023 6:36 PM, Hendrickson, Eric D wrote:
> > > Hi Eliot,
> > >
> > > Thanks for responding.  That makes total sense.
> > >
> > > Totally taking into account the all volunteer nature of Cygwin, would it
> > make sense to defer on further non-emergency releases of Cygwin until all
> > packages that are EOL have been updated?  Since this is the case with ruby,
> > I am guessing it's likely the case with other packages in Cygwin too.
> > >
> > > Is there a backlog for Cygwin somewhere, so that I can investigate this
> > myself if I have time this winter?
> > >
> > > Thank you and all the best,
> > > Eric
> > >
> > > -----Original Message-----
> > > From: Eliot Moss <moss@cs.umass.edu>
> > > Sent: Wednesday, October 11, 2023 5:03 PM
> > > To: Hendrickson, Eric D <edh@optum.com>; cygwin@cygwin.com
> > > Cc: Eric @ Gmail <ericdavidhendrickson@gmail.com>
> > > Subject: Re: Ruby EOL in Cygwin 3.4.9?
> > >
> > > On 10/11/2023 12:37 PM, Hendrickson, Eric D via Cygwin wrote:
> > >> Hello all,
> > >>
> > >> As a ~25 year user and sometime contributor to Cygwin, I support Cygwin
> > here at my place of work.  Does anyone know why we are deploying Ruby 2.6
> > which EOL about 18 months ago?
> > >>
> > >> https://www.ruby-lang.org/en/downloads/branches/
> > >>
> > >> I'm concerned about proliferation of EOL versions of Ruby in case some
> > security risk / 0Day is identified.
> > >>
> > >> Please advise.
> > >> Eric Hendrickson
> >
> > You should send such things to the list, not me.  I'm just
> > a user who has only made occasional small contributions ...
> >
> > Eliot
> >
> > > If nobody has responded I can give a generic response:
> > > "Because cygwin is all volunteer and someone has not volunteered, or did
> > volunteer and is behind, or fell off the radar."
> > >
> > > Someone else will know how to look up if there is a currently registered
> > volunteer for Ruby ...
> > >
> > > Eliot Moss
> > >
> > >> This e-mail, including attachments, may include confidential and/or
> > >> proprietary information, and may be used only by the person or entity
> > >> to which it is addressed. If the reader of this e-mail is not the
> > >> intended recipient or intended recipient’s authorized agent, the
> > >> reader is hereby notified that any dissemination, distribution or
> > >> copying of this e-mail is prohibited. If you have received this e-mail
> > >> in error, please notify the sender by replying to this message and
> > delete this e-mail immediately.
> > >>
> > >
> > > This e-mail, including attachments, may include confidential and/or
> > > proprietary information, and may be used only by the person or entity
> > > to which it is addressed. If the reader of this e-mail is not the
> > intended
> > > recipient or intended recipient’s authorized agent, the reader is hereby
> > > notified that any dissemination, distribution or copying of this e-mail
> > is
> > > prohibited. If you have received this e-mail in error, please notify the
> > > sender by replying to this message and delete this e-mail immediately.
> >
> >


On Wed, Oct 11, 2023 at 09:55:04PM -0500, Eric D Hendrickson via Cygwin wrote:
> For the whole list:
> 
> Totally taking into account the all volunteer nature of Cygwin, would it
> make sense to defer on further non-emergency releases of Cygwin until all
> packages that are EOL have been updated?

Absolutely not.  That makes *zero* sense for an all volunteer group.

Not every single package is important to everyone.
(I am speaking personally, as maintainer of a single package on Cygwin.)

You care about Ruby?  Good.
I do not use Ruby, so that is not important *to me*.

If some specific packages are important to you, please consider finding
the maintainers of those packages and offering to help maintain those
packages.

https://cygwin.com/cygwin-pkg-maint

There are many ruby-* packages that have been orphaned.  Have at it. :)

Cheers, Glenn

Re: Ruby EOL in Cygwin 3.4.9?

[Eric D Hendrickson]

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

Hello,

Thanks for your reply.  Again, to the point that this is an all volunteer
effort.

And not taking away from any of what you said.

However, sorry I was not more clear.  The issue here is as follows.

Is Cygwin as a whole not more important than any one package?

Cygwin is distributing a suite of packages.  Are you really saying that if
there were a 0day vulnerability discovered in an EOL package still being
distributed by Cygwin, that this would do no damage to the reputation of
Cygwin?

How does Cygwin being an all volunteer effort have any bearing on this
question, other than the time and interest of the volunteers?

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.

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.

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?

thank you and Cheers to you as well,
Eric

On Wed, Oct 11, 2023 at 10:59 PM <gs-cygwin.com@gluelogic.com> wrote:

> On Wed, Oct 11, 2023 at 09:55:04PM -0500, Eric D Hendrickson via Cygwin
> wrote:
> > Sorry for the unclarity - I meant this for the whole list - not just you.
> >
> > Thank you so much for taking the time to respond.  Like you said, this
> > really is all volunteers.
> >
> > For the whole list:
> >
> > Totally taking into account the all volunteer nature of Cygwin, would it
> > make sense to defer on further non-emergency releases of Cygwin until all
> > packages that are EOL have been updated?  Since this is the case with
> ruby,
> > I am guessing it's likely the case with other packages in Cygwin too.
> >
> > Is there a Issues log of some sort (ala github) for Cygwin somewhere, so
> > that I can document this in the backlog and come back later to
> investigate
> > this myself if I have time this winter?
> >
> >
> > On Wed, Oct 11, 2023 at 8:11 PM Eliot Moss <moss@cs.umass.edu> wrote:
> >
> > > On 10/11/2023 6:36 PM, Hendrickson, Eric D wrote:
> > > > Hi Eliot,
> > > >
> > > > Thanks for responding.  That makes total sense.
> > > >
> > > > Totally taking into account the all volunteer nature of Cygwin,
> would it
> > > make sense to defer on further non-emergency releases of Cygwin until
> all
> > > packages that are EOL have been updated?  Since this is the case with
> ruby,
> > > I am guessing it's likely the case with other packages in Cygwin too.
> > > >
> > > > Is there a backlog for Cygwin somewhere, so that I can investigate
> this
> > > myself if I have time this winter?
> > > >
> > > > Thank you and all the best,
> > > > Eric
> > > >
> > > > -----Original Message-----
> > > > From: Eliot Moss <moss@cs.umass.edu>
> > > > Sent: Wednesday, October 11, 2023 5:03 PM
> > > > To: Hendrickson, Eric D <edh@optum.com>; cygwin@cygwin.com
> > > > Cc: Eric @ Gmail <ericdavidhendrickson@gmail.com>
> > > > Subject: Re: Ruby EOL in Cygwin 3.4.9?
> > > >
> > > > On 10/11/2023 12:37 PM, Hendrickson, Eric D via Cygwin wrote:
> > > >> Hello all,
> > > >>
> > > >> As a ~25 year user and sometime contributor to Cygwin, I support
> Cygwin
> > > here at my place of work.  Does anyone know why we are deploying Ruby
> 2.6
> > > which EOL about 18 months ago?
> > > >>
> > > >> https://www.ruby-lang.org/en/downloads/branches/
> > > >>
> > > >> I'm concerned about proliferation of EOL versions of Ruby in case
> some
> > > security risk / 0Day is identified.
> > > >>
> > > >> Please advise.
> > > >> Eric Hendrickson
> > >
> > > You should send such things to the list, not me.  I'm just
> > > a user who has only made occasional small contributions ...
> > >
> > > Eliot
> > >
> > > > If nobody has responded I can give a generic response:
> > > > "Because cygwin is all volunteer and someone has not volunteered, or
> did
> > > volunteer and is behind, or fell off the radar."
> > > >
> > > > Someone else will know how to look up if there is a currently
> registered
> > > volunteer for Ruby ...
> > > >
> > > > Eliot Moss
> > > >
> > > >> This e-mail, including attachments, may include confidential and/or
> > > >> proprietary information, and may be used only by the person or
> entity
> > > >> to which it is addressed. If the reader of this e-mail is not the
> > > >> intended recipient or intended recipient’s authorized agent, the
> > > >> reader is hereby notified that any dissemination, distribution or
> > > >> copying of this e-mail is prohibited. If you have received this
> e-mail
> > > >> in error, please notify the sender by replying to this message and
> > > delete this e-mail immediately.
> > > >>
> > > >
> > > > This e-mail, including attachments, may include confidential and/or
> > > > proprietary information, and may be used only by the person or entity
> > > > to which it is addressed. If the reader of this e-mail is not the
> > > intended
> > > > recipient or intended recipient’s authorized agent, the reader is
> hereby
> > > > notified that any dissemination, distribution or copying of this
> e-mail
> > > is
> > > > prohibited. If you have received this e-mail in error, please notify
> the
> > > > sender by replying to this message and delete this e-mail
> immediately.
> > >
> > >
>
>
> On Wed, Oct 11, 2023 at 09:55:04PM -0500, Eric D Hendrickson via Cygwin
> wrote:
> > For the whole list:
> >
> > Totally taking into account the all volunteer nature of Cygwin, would it
> > make sense to defer on further non-emergency releases of Cygwin until all
> > packages that are EOL have been updated?
>
> Absolutely not.  That makes *zero* sense for an all volunteer group.
>
> Not every single package is important to everyone.
> (I am speaking personally, as maintainer of a single package on Cygwin.)
>
> You care about Ruby?  Good.
> I do not use Ruby, so that is not important *to me*.
>
> If some specific packages are important to you, please consider finding
> the maintainers of those packages and offering to help maintain those
> packages.
>
> https://cygwin.com/cygwin-pkg-maint
>
> There are many ruby-* packages that have been orphaned.  Have at it. :)
>
> Cheers, Glenn
>


-- 
Good government never depends upon laws, but upon the personal qualities of
those who govern. The machinery of government is always subordinate to the
will of those who administer that machinery. The most important element of
government, therefore, is the method of choosing leaders.
 -- Law and Governance, The Spacing Guild Manual, Children of Dune

Re: Ruby EOL in Cygwin 3.4.9?

[gs-cygwin.com]

On Wed, Oct 11, 2023 at 11:15:40PM -0500, Eric D Hendrickson wrote:
> Hello,
> 
> Thanks for your reply.  Again, to the point that this is an all volunteer
> effort.
> 
> And not taking away from any of what you said.
> 
> However, sorry I was not more clear.  The issue here is as follows.
> 
> Is Cygwin as a whole not more important than any one package?
> 
> Cygwin is distributing a suite of packages.  Are you really saying that if
> there were a 0day vulnerability discovered in an EOL package still being
> distributed by Cygwin, that this would do no damage to the reputation of
> Cygwin?
> 
> How does Cygwin being an all volunteer effort have any bearing on this
> question, other than the time and interest of the volunteers?
> 
> 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.
> 
> 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.
> 
> 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?
> 
> thank you and Cheers to you as well,
> Eric
> 
> On Wed, Oct 11, 2023 at 10:59 PM <gs-cygwin.com@gluelogic.com> wrote:
> 
> > On Wed, Oct 11, 2023 at 09:55:04PM -0500, Eric D Hendrickson via Cygwin
> > wrote:
> > > Sorry for the unclarity - I meant this for the whole list - not just you.
> > >
> > > Thank you so much for taking the time to respond.  Like you said, this
> > > really is all volunteers.
> > >
> > > For the whole list:
> > >
> > > Totally taking into account the all volunteer nature of Cygwin, would it
> > > make sense to defer on further non-emergency releases of Cygwin until all
> > > packages that are EOL have been updated?  Since this is the case with
> > ruby,
> > > I am guessing it's likely the case with other packages in Cygwin too.
> > >
> > > Is there a Issues log of some sort (ala github) for Cygwin somewhere, so
> > > that I can document this in the backlog and come back later to
> > investigate
> > > this myself if I have time this winter?
> > >
> > >
> > > On Wed, Oct 11, 2023 at 8:11 PM Eliot Moss <moss@cs.umass.edu> wrote:
> > >
> > > > On 10/11/2023 6:36 PM, Hendrickson, Eric D wrote:
> > > > > Hi Eliot,
> > > > >
> > > > > Thanks for responding.  That makes total sense.
> > > > >
> > > > > Totally taking into account the all volunteer nature of Cygwin,
> > would it
> > > > make sense to defer on further non-emergency releases of Cygwin until
> > all
> > > > packages that are EOL have been updated?  Since this is the case with
> > ruby,
> > > > I am guessing it's likely the case with other packages in Cygwin too.
> > > > >
> > > > > Is there a backlog for Cygwin somewhere, so that I can investigate
> > this
> > > > myself if I have time this winter?
> > > > >
> > > > > Thank you and all the best,
> > > > > Eric
> > > > >
> > > > > -----Original Message-----
> > > > > From: Eliot Moss <moss@cs.umass.edu>
> > > > > Sent: Wednesday, October 11, 2023 5:03 PM
> > > > > To: Hendrickson, Eric D <edh@optum.com>; cygwin@cygwin.com
> > > > > Cc: Eric @ Gmail <ericdavidhendrickson@gmail.com>
> > > > > Subject: Re: Ruby EOL in Cygwin 3.4.9?
> > > > >
> > > > > On 10/11/2023 12:37 PM, Hendrickson, Eric D via Cygwin wrote:
> > > > >> Hello all,
> > > > >>
> > > > >> As a ~25 year user and sometime contributor to Cygwin, I support
> > Cygwin
> > > > here at my place of work.  Does anyone know why we are deploying Ruby
> > 2.6
> > > > which EOL about 18 months ago?
> > > > >>
> > > > >> https://www.ruby-lang.org/en/downloads/branches/
> > > > >>
> > > > >> I'm concerned about proliferation of EOL versions of Ruby in case
> > some
> > > > security risk / 0Day is identified.
> > > > >>
> > > > >> Please advise.
> > > > >> Eric Hendrickson
> > > >
> > > > You should send such things to the list, not me.  I'm just
> > > > a user who has only made occasional small contributions ...
> > > >
> > > > Eliot
> > > >
> > > > > If nobody has responded I can give a generic response:
> > > > > "Because cygwin is all volunteer and someone has not volunteered, or
> > did
> > > > volunteer and is behind, or fell off the radar."
> > > > >
> > > > > Someone else will know how to look up if there is a currently
> > registered
> > > > volunteer for Ruby ...
> > > > >
> > > > > Eliot Moss
> > > > >
> > > > >> This e-mail, including attachments, may include confidential and/or
> > > > >> proprietary information, and may be used only by the person or
> > entity
> > > > >> to which it is addressed. If the reader of this e-mail is not the
> > > > >> intended recipient or intended recipient’s authorized agent, the
> > > > >> reader is hereby notified that any dissemination, distribution or
> > > > >> copying of this e-mail is prohibited. If you have received this
> > e-mail
> > > > >> in error, please notify the sender by replying to this message and
> > > > delete this e-mail immediately.
> > > > >>
> > > > >
> > > > > This e-mail, including attachments, may include confidential and/or
> > > > > proprietary information, and may be used only by the person or entity
> > > > > to which it is addressed. If the reader of this e-mail is not the
> > > > intended
> > > > > recipient or intended recipient’s authorized agent, the reader is
> > hereby
> > > > > notified that any dissemination, distribution or copying of this
> > e-mail
> > > > is
> > > > > prohibited. If you have received this e-mail in error, please notify
> > the
> > > > > sender by replying to this message and delete this e-mail
> > immediately.
> > > >
> > > >
> >
> >
> > On Wed, Oct 11, 2023 at 09:55:04PM -0500, Eric D Hendrickson via Cygwin
> > wrote:
> > > For the whole list:
> > >
> > > Totally taking into account the all volunteer nature of Cygwin, would it
> > > make sense to defer on further non-emergency releases of Cygwin until all
> > > packages that are EOL have been updated?
> >
> > Absolutely not.  That makes *zero* sense for an all volunteer group.
> >
> > Not every single package is important to everyone.
> > (I am speaking personally, as maintainer of a single package on Cygwin.)
> >
> > You care about Ruby?  Good.
> > I do not use Ruby, so that is not important *to me*.
> >
> > If some specific packages are important to you, please consider finding
> > the maintainers of those packages and offering to help maintain those
> > packages.
> >
> > https://cygwin.com/cygwin-pkg-maint
> >
> > There are many ruby-* packages that have been orphaned.  Have at it. :)
> >
> > Cheers, Glenn

Your suggestions might be given slightly more weight if you made *any*
substantive contribution besides sharing your questionable assumptions,
and opinions on work that your think *other* people (who are volunteers)
should do.

Aside: The preference on this list is to bottom-post.

Re: Ruby EOL in Cygwin 3.4.9?

[Brian Inglis]

On 2023-10-11 16:47, Yasuhiro Kimura via Cygwin wrote:
> From: "Hendrickson, Eric D via Cygwin" <cygwin@cygwin.com>
> Subject: Ruby EOL in Cygwin 3.4.9?
> Date: Wed, 11 Oct 2023 16:37:29 +0000
> 
>> Hello all,
>>
>> As a ~25 year user and sometime contributor to Cygwin, I support Cygwin here at my place of work.  Does anyone know why we are deploying Ruby 2.6 which EOL about 18 months ago?
>>
>> https://www.ruby-lang.org/en/downloads/branches/
>>
>> I'm concerned about proliferation of EOL versions of Ruby in case some security risk / 0Day is identified.
>>
>> Please advise.
>> Eric Hendrickson
> 
> On my environment version of Ruby is 3.2.2.
> 
> (Cygwin64)yasu@rolling[1005]% uname -a                                                                                      ~
> CYGWIN_NT-10.0-22621 rolling 3.4.9-1.x86_64 2023-09-06 11:19 UTC x86_64 Cygwin
> (Cygwin64)yasu@rolling[1006]% type ruby                                                                                     ~
> ruby is /usr/bin/ruby
> (Cygwin64)yasu@rolling[1007]% ruby --version                                                                                ~
> ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-cygwin]
> (Cygwin64)yasu@rolling[1008]%
> 
> I use https://ftp.iij.ad.jp/pub/cygwin as download site and there are
> surely ruby-3.2.2-2.hint, ruby-3.2.2-2.tar.xz, ruby-3.2.2-2-src.hint
> and ruby-3.2.2-2-src.tar.xz under
> https://ftp.iij.ad.jp/pub/cygwin/x86_64/release/ruby/.
> 
> So I guess download site you use is out of sync.

Current Cygwin ruby was updated to current upstream 3.2.2 six months ago; see:

	https://cygwin.com/packages/summary/ruby-src.html

Checking the upstream link, preview RCs of 3.3 are available but no final 
release yet.

So it is up to you to update to the latest stable releases available on Cygwin, 
and whether any package gets updated may be influenced by what other packages 
you use which depend on earlier versions of basic language or runtime packages, 
although I am not seeing any such holdbacks.

If you are seeing such behaviour, you can check /var/log/setup.log.full to see 
the decisions made by the solver to upgrade packages.

You can also check your selected mirror(s) in /etc/setup/setup.rc e.g.

	$ grep -xA3 'last-mirror' /etc/setup/setup.rc

and for the state of your mirror(s) see:

	https://cygwin.com/mirrors-report.html

and only statuses after the first two are normally significant IMO.

One of my preferred local mirrors went stale and I (unusually) got no response 
from the local university mirror support webpage or email, so had to add another 
with a better record. Eventually someone did something and it is back to normal.

As Cygwin is a rolling release distribution, each package and language is 
updated as upstream makes them available, and whether and when the maintainer 
has time and confidence to release each update depends on many factors, which 
may include updates to upstream packages needed to build or run a package, and 
whether tests work successfully on Cygwin, to be confident the release provides 
stable functionality.

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

Re: Ruby EOL in Cygwin 3.4.9?

[Eric Hendrickson]

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

I don’t know who all is on this distribution but I’m going to be very clear.

I asked a few very reasonable questions in regard to security and best practices for a mature and widely known product like Cygwin. In this context, it doesn’t matter much that it’s all volunteers except in terms of resourcing - the answers should be basically the same. Either it’s important to Cygwin or it’s not.

I’m even offering to contribute back to Cygwin.

I got no answers to my questions except “you’re stupid”.

I don’t care how many stupid questions this volunteer team gets, or random emails. This is unacceptable for the open source community. Or for any community.

The Cygwin team needs to internally examine its maturity and professionalism.  Decisions clearly need to be made about how to communicate with the community. Anyone who treats people the way Glenn does should be ejected from the community.

Sent from Outlook<https://aka.ms/qtex0l> on my Tricorder
________________________________
From: gs-cygwin.com@gluelogic.com <gs-cygwin.com@gluelogic.com>
Sent: Wednesday, October 11, 2023 11:46:53 PM
To: Eric D Hendrickson <ericdavidhendrickson@gmail.com>
Cc: Hendrickson, Eric D <edh@optum.com>; cygwin@cygwin.com <cygwin@cygwin.com>
Subject: Re: Ruby EOL in Cygwin 3.4.9?

On Wed, Oct 11, 2023 at 11:15:40PM -0500, Eric D Hendrickson wrote:
> Hello,
>
> Thanks for your reply.  Again, to the point that this is an all volunteer
> effort.
>
> And not taking away from any of what you said.
>
> However, sorry I was not more clear.  The issue here is as follows.
>
> Is Cygwin as a whole not more important than any one package?
>
> Cygwin is distributing a suite of packages.  Are you really saying that if
> there were a 0day vulnerability discovered in an EOL package still being
> distributed by Cygwin, that this would do no damage to the reputation of
> Cygwin?
>
> How does Cygwin being an all volunteer effort have any bearing on this
> question, other than the time and interest of the volunteers?
>
> 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.
>
> 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.
>
> 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?
>
> thank you and Cheers to you as well,
> Eric
>
> On Wed, Oct 11, 2023 at 10:59 PM <gs-cygwin.com@gluelogic.com> wrote:
>
> > On Wed, Oct 11, 2023 at 09:55:04PM -0500, Eric D Hendrickson via Cygwin
> > wrote:
> > > Sorry for the unclarity - I meant this for the whole list - not just you.
> > >
> > > Thank you so much for taking the time to respond.  Like you said, this
> > > really is all volunteers.
> > >
> > > For the whole list:
> > >
> > > Totally taking into account the all volunteer nature of Cygwin, would it
> > > make sense to defer on further non-emergency releases of Cygwin until all
> > > packages that are EOL have been updated?  Since this is the case with
> > ruby,
> > > I am guessing it's likely the case with other packages in Cygwin too.
> > >
> > > Is there a Issues log of some sort (ala github) for Cygwin somewhere, so
> > > that I can document this in the backlog and come back later to
> > investigate
> > > this myself if I have time this winter?
> > >
> > >
> > > On Wed, Oct 11, 2023 at 8:11 PM Eliot Moss <moss@cs.umass.edu> wrote:
> > >
> > > > On 10/11/2023 6:36 PM, Hendrickson, Eric D wrote:
> > > > > Hi Eliot,
> > > > >
> > > > > Thanks for responding.  That makes total sense.
> > > > >
> > > > > Totally taking into account the all volunteer nature of Cygwin,
> > would it
> > > > make sense to defer on further non-emergency releases of Cygwin until
> > all
> > > > packages that are EOL have been updated?  Since this is the case with
> > ruby,
> > > > I am guessing it's likely the case with other packages in Cygwin too.
> > > > >
> > > > > Is there a backlog for Cygwin somewhere, so that I can investigate
> > this
> > > > myself if I have time this winter?
> > > > >
> > > > > Thank you and all the best,
> > > > > Eric
> > > > >
> > > > > -----Original Message-----
> > > > > From: Eliot Moss <moss@cs.umass.edu>
> > > > > Sent: Wednesday, October 11, 2023 5:03 PM
> > > > > To: Hendrickson, Eric D <edh@optum.com>; cygwin@cygwin.com
> > > > > Cc: Eric @ Gmail <ericdavidhendrickson@gmail.com>
> > > > > Subject: Re: Ruby EOL in Cygwin 3.4.9?
> > > > >
> > > > > On 10/11/2023 12:37 PM, Hendrickson, Eric D via Cygwin wrote:
> > > > >> Hello all,
> > > > >>
> > > > >> As a ~25 year user and sometime contributor to Cygwin, I support
> > Cygwin
> > > > here at my place of work.  Does anyone know why we are deploying Ruby
> > 2.6
> > > > which EOL about 18 months ago?
> > > > >>
> > > > >> https://www.ruby-lang.org/en/downloads/branches/
> > > > >>
> > > > >> I'm concerned about proliferation of EOL versions of Ruby in case
> > some
> > > > security risk / 0Day is identified.
> > > > >>
> > > > >> Please advise.
> > > > >> Eric Hendrickson
> > > >
> > > > You should send such things to the list, not me.  I'm just
> > > > a user who has only made occasional small contributions ...
> > > >
> > > > Eliot
> > > >
> > > > > If nobody has responded I can give a generic response:
> > > > > "Because cygwin is all volunteer and someone has not volunteered, or
> > did
> > > > volunteer and is behind, or fell off the radar."
> > > > >
> > > > > Someone else will know how to look up if there is a currently
> > registered
> > > > volunteer for Ruby ...
> > > > >
> > > > > Eliot Moss
> > > > >
> > > > >> This e-mail, including attachments, may include confidential and/or
> > > > >> proprietary information, and may be used only by the person or
> > entity
> > > > >> to which it is addressed. If the reader of this e-mail is not the
> > > > >> intended recipient or intended recipient’s authorized agent, the
> > > > >> reader is hereby notified that any dissemination, distribution or
> > > > >> copying of this e-mail is prohibited. If you have received this
> > e-mail
> > > > >> in error, please notify the sender by replying to this message and
> > > > delete this e-mail immediately.
> > > > >>
> > > > >
> > > > > This e-mail, including attachments, may include confidential and/or
> > > > > proprietary information, and may be used only by the person or entity
> > > > > to which it is addressed. If the reader of this e-mail is not the
> > > > intended
> > > > > recipient or intended recipient’s authorized agent, the reader is
> > hereby
> > > > > notified that any dissemination, distribution or copying of this
> > e-mail
> > > > is
> > > > > prohibited. If you have received this e-mail in error, please notify
> > the
> > > > > sender by replying to this message and delete this e-mail
> > immediately.
> > > >
> > > >
> >
> >
> > On Wed, Oct 11, 2023 at 09:55:04PM -0500, Eric D Hendrickson via Cygwin
> > wrote:
> > > For the whole list:
> > >
> > > Totally taking into account the all volunteer nature of Cygwin, would it
> > > make sense to defer on further non-emergency releases of Cygwin until all
> > > packages that are EOL have been updated?
> >
> > Absolutely not.  That makes *zero* sense for an all volunteer group.
> >
> > Not every single package is important to everyone.
> > (I am speaking personally, as maintainer of a single package on Cygwin.)
> >
> > You care about Ruby?  Good.
> > I do not use Ruby, so that is not important *to me*.
> >
> > If some specific packages are important to you, please consider finding
> > the maintainers of those packages and offering to help maintain those
> > packages.
> >
> > https://cygwin.com/cygwin-pkg-maint
> >
> > There are many ruby-* packages that have been orphaned.  Have at it. :)
> >
> > Cheers, Glenn

Your suggestions might be given slightly more weight if you made *any*
substantive contribution besides sharing your questionable assumptions,
and opinions on work that your think *other* people (who are volunteers)
should do.

Aside: The preference on this list is to bottom-post.

Re: Ruby EOL in Cygwin 3.4.9?

[Brian Inglis]

>> On Wed, Oct 11, 2023 at 10:59 PM wrote:
>>> On Wed, Oct 11, 2023 at 09:55:04PM -0500, Eric D Hendrickson wrote:
>>>> Sorry for the unclarity - I meant this for the whole list - not just you.
>>>> Thank you so much for taking the time to respond.  Like you said, this
>>>> really is all volunteers.
>>>> For the whole list:
>>>> Totally taking into account the all volunteer nature of Cygwin, would it
>>>> make sense to defer on further non-emergency releases of Cygwin until all
>>>> packages that are EOL have been updated?  Since this is the case with
>>> ruby,
>>>> I am guessing it's likely the case with other packages in Cygwin too.
>>>> Is there a Issues log of some sort (ala github) for Cygwin somewhere, so
>>>> that I can document this in the backlog and come back later to
>>> investigate
>>>> this myself if I have time this winter?
>>>> On Wed, Oct 11, 2023 at 8:11 PM Eliot Moss wrote:
>>>>> On 10/11/2023 6:36 PM, Hendrickson, Eric D wrote:
>>>>>> Thanks for responding.  That makes total sense.
>>>>>> Totally taking into account the all volunteer nature of Cygwin,
>>> would it
>>>>> make sense to defer on further non-emergency releases of Cygwin until
>>> all
>>>>> packages that are EOL have been updated?  Since this is the case with
>>> ruby,
>>>>> I am guessing it's likely the case with other packages in Cygwin too.
>>>>>>
>>>>>> Is there a backlog for Cygwin somewhere, so that I can investigate
>>> this
>>>>> myself if I have time this winter?
>>>>>> On Wednesday, October 11, 2023 5:03 PM, Eliot Moss wrote:
>>>>>> On 10/11/2023 12:37 PM, Hendrickson, Eric D via Cygwin wrote:
>>>>>>> As a ~25 year user and sometime contributor to Cygwin, I support
>>> Cygwin
>>>>> here at my place of work.  Does anyone know why we are deploying Ruby
>>> 2.6
>>>>> which EOL about 18 months ago?
>>>>>>>
>>>>>>> https://www.ruby-lang.org/en/downloads/branches/
>>>>>>>
>>>>>>> I'm concerned about proliferation of EOL versions of Ruby in case
>>> some
>>>>> security risk / 0Day is identified.
>>>>>>>
>>>>>>> Please advise.
>>>>> You should send such things to the list, not me.  I'm just
>>>>> a user who has only made occasional small contributions ...
>>>>>> If nobody has responded I can give a generic response:
>>>>>> "Because cygwin is all volunteer and someone has not volunteered, or
>>> did
>>>>> volunteer and is behind, or fell off the radar."
>>>>>>
>>>>>> Someone else will know how to look up if there is a currently
>>> registered
>>>>> volunteer for Ruby ...
>>> On Wed, Oct 11, 2023 at 09:55:04PM -0500, Eric D Hendrickson via Cygwin
>>> wrote:
>>>> Totally taking into account the all volunteer nature of Cygwin, would it
>>>> make sense to defer on further non-emergency releases of Cygwin until all
>>>> packages that are EOL have been updated?
>>>
>>> Absolutely not.  That makes *zero* sense for an all volunteer group.
>>>
>>> Not every single package is important to everyone.
>>> (I am speaking personally, as maintainer of a single package on Cygwin.)
>>>
>>> You care about Ruby?  Good.
>>> I do not use Ruby, so that is not important *to me*.
>>>
>>> If some specific packages are important to you, please consider finding
>>> the maintainers of those packages and offering to help maintain those
>>> packages.
>>>
>>> https://cygwin.com/cygwin-pkg-maint
>>>
>>> There are many ruby-* packages that have been orphaned.  Have at it. :)
>>>
>>> Cheers, Glenn
> 
> Your suggestions might be given slightly more weight if you made *any*
> substantive contribution besides sharing your questionable assumptions,
> and opinions on work that your think *other* people (who are volunteers)
> should do.
> 
> Aside: The preference on this list is to bottom-post.

 > On Wed, Oct 11, 2023 at 11:15:40PM -0500, Eric D Hendrickson wrote:
 >> Thanks for your reply.  Again, to the point that this is an all volunteer
 >> effort.
 >> And not taking away from any of what you said.
 >> However, sorry I was not more clear.  The issue here is as follows.
 >> Is Cygwin as a whole not more important than any one package?
 >> Cygwin is distributing a suite of packages.  Are you really saying that if
 >> there were a 0day vulnerability discovered in an EOL package still being
 >> distributed by Cygwin, that this would do no damage to the reputation of
 >> Cygwin?
 >> How does Cygwin being an all volunteer effort have any bearing on this
 >> question, other than the time and interest of the volunteers?
 >> 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.
 >> 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.
 >> 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?

On 2023-10-12 09:18, Eric Hendrickson via Cygwin wrote:
 > I don’t know who all is on this distribution but I’m going to be very clear.

Thousands of users

> I asked a few very reasonable questions in regard to security and best
practices for a mature and widely known product like Cygwin. In this context, it
doesn’t matter much that it’s all volunteers except in terms of resourcing - the
answers should be basically the same. Either it’s important to Cygwin or it’s not.

Only if it's expressed by sufficient users and supported by sufficient 
contributors who have free time and are interested in doing the work, otherwise 
no, it dies on the mailing list

 > I’m even offering to contribute back to Cygwin.

In what way, other than offering opinions?

 > I got no answers to my questions except “you’re stupid”.

I saw no such comment or statement.

 > I don’t care how many stupid questions this volunteer team gets, or random 
emails. This is unacceptable for the open source community. Or for any community.

You are being unnecessarily contentious and your opinions are unwarranted.

 > The Cygwin team needs to internally examine its maturity and professionalism.

You are now being rude to every contributor to this project.

 > Decisions clearly need to be made about how to communicate with the community.

Decisions are made by each contributor according to their knowledge, ability, 
capability, interests, and availability within their own scope; anything else is 
merely an opinion or belief, which may be ignored.

 > Anyone who treats people the way Glenn does should be ejected from the community.

Glenn made no such implications towards anyone IMO!

He did question your assumptions, and posting methods, which are incorrect:

- Cygwin is a project, not a product, consisting of a bunch of components, 
including over 12k packages, with many dependencies;

- there are no Cygwin releases, each component and package is independently 
upgraded, except if there are dependencies, which need to be upgraded and 
released first;

- there is no "team", only volunteers, some of which work on the emulator and 
related packages, others on libraries and application packages, doing their own 
thing, when they have time, if they are interested, if there are no blockers;

- there is no internal, only public mailing lists on which all discussion takes 
place;

- importance is decided by each volunteer for each component and package they 
maintain or contribute to;

- best practices are decided by discussion and consensus, on the public mailing 
lists, or at least implicit agreement to go along or not bother;

- communication is what each person can manage in English, bearing in mind that 
this is an international project with international contributors, many of whom 
may not speak English as their primary language, so we try to keep things as 
simple as possible;

- comments about maturity, professionalism, and opinions about treatment, and 
ejection need to be considered based on the content and track record of the poster;

- these appear to be your first posts to this list since its inception;

- you do not appear to have read up about the project from its web site, looked 
at its FAQs, searched or previewed prior posts;

- your initial statements about Cygwin ruby were incorrect and others tried to 
correct your impressions and opinions;

- you appear to be attempting to push a series of uninformed opinions about 
unworkable approaches onto a longstanding project with its own approaches which 
are based on openness and cooperation by volunteers in whatever they can spare 
of their free time;

- the answers to all your questions (which you would know if you had read the 
FAQ or had any familiarity with the project at all, which contrary to the claims 
made in your initial post, appear unlikely to be true, as you seem totally 
ignorant and uncognizant of anything about the project) is everything goes on 
the mailing list, and if anyone can be bothered, they may post a reply, or not;

- you have been advised of your issues, possible causes and remedies: try 
reading and trying them, before posting further, or being more contentious;

- if you dislike the responses and approaches of this community, there are 
alternatives to Cygwin, such as WSL distros, containers, VMs, etc. offering 
communities which you may prefer;

- you appear to be indulging in troll-like behaviour, so I suggest others cease 
replying to you, if such behaviour continues; in which case, you got us: please 
move on to another forum or list!

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

Re: Ruby EOL in Cygwin 3.4.9?

[Thomas Schweikle]

[-- Attachment #1.1.1: Type: text/plain, Size: 577 bytes --]



Am Mi., 11.Okt..2023 um 18:37:29 schrieb Hendrickson, Eric D via Cygwin:
> Hello all,
> 
> As a ~25 year user and sometime contributor to Cygwin, I support Cygwin here at my place of work.  Does anyone know why we are deploying Ruby 2.6 which EOL about 18 months ago?
> 
> https://www.ruby-lang.org/en/downloads/branches/
> 
> I'm concerned about proliferation of EOL versions of Ruby in case some security risk / 0Day is identified.

Did you set version 2.6* to install? It is still there and may be 
installed. Version 3.2.2 is available too.

-- 
Thomas


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 2521 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 321 bytes --]

Re: Ruby EOL in Cygwin 3.4.9?

[Adam Dinwoodie]

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.

Re: Ruby EOL in Cygwin 3.4.9?

[Eric Hendrickson]

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

Re: Ruby EOL in Cygwin 3.4.9?

[David Rothenberger]

On 10/12/2023 2:46 PM, Eric Hendrickson via Cygwin wrote:
> 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.

Cygwin "releases" are just releases of the compatibility library, 
similar to the kernel in a Linux distribution. Cygwin doesn't have the 
equivalent of Debian releases, where all packages are tested for 
compatibility and released as a unit.

For that reason, it doesn't make sense to pause Cygwin "releases" just 
because some of the packages are out-of-date, since Cygwin is itself 
just another one of these packages.

-- 
David Rothenberger  ----  daveroth@acm.org

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