Re: Ruby EOL in Cygwin 3.4.9?
On 12/10/2023 14:42, Brian Inglis via Cygwin wrote: On 2023-10-11 16:47, Yasuhiro Kimura via Cygwin wrote: From: "Hendrickson, Eric D via Cygwin" Subject: Ruby EOL in Cygwin 3.4.9? Date: Wed, 11 Oct 2023 16:37:29 + 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. [...] 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. I suspect this is the cause here. Fujimura-san has done a lot of hard work recently to bring our ruby packages up to date, but there remain a handful of packages remaining (see [1]) which still need attention (either updating, or possibly removing). If you're installing one of those (or simply installing everything), then setup will decide that you need an older ruby runtime to allow those to be installed. [1] https://cygwin.com/packages/reports/ruby_rebuilds.html 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.
Re: Ruby EOL in Cygwin 3.4.9?
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.
Re: Ruby EOL in Cygwin 3.4.9?
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 daver...@acm.org -- 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
Re: Ruby EOL in Cygwin 3.4.9?
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 Sent: Thursday, October 12, 2023 1:22 PM To: Eric D Hendrickson Cc: gs-cygwin@gluelogic.com ; Hendrickson, Eric D ; 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 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 he
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 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
Re: Ruby EOL in Cygwin 3.4.9?
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 OpenPGP_0x27AE2304B4974851.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- 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
Re: Ruby EOL in Cygwin 3.4.9?
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
Re: Ruby EOL in Cygwin 3.4.9?
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@gluelogic.com Sent: Wednesday, October 11, 2023 11:46:53 PM To: Eric D Hendrickson Cc: Hendrickson, Eric D ; 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 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 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, > >
Re: Ruby EOL in Cygwin 3.4.9?
On 2023-10-11 16:47, Yasuhiro Kimura via Cygwin wrote: From: "Hendrickson, Eric D via Cygwin" Subject: Ruby EOL in Cygwin 3.4.9? Date: Wed, 11 Oct 2023 16:37:29 + 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 -- 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
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 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 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 > > > > > Sent: Wednesday, October 11, 2023 5:03 PM > > > > > To: Hendrickson, Eric D ; cygwin@cygwin.com > > > > > Cc: Eric @ Gmail > > > > > 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. > > > > >> > > >
Re: Ruby EOL in Cygwin 3.4.9?
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 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 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 > > > > Sent: Wednesday, October 11, 2023 5:03 PM > > > > To: Hendrickson, Eric D ; cygwin@cygwin.com > > > > Cc: Eric @ Gmail > > > > 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 lo
Re: Ruby EOL in Cygwin 3.4.9?
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 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 > > > Sent: Wednesday, October 11, 2023 5:03 PM > > > To: Hendrickson, Eric D ; cygwin@cygwin.com > > > Cc: Eric @ Gmail > > > 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 -- 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
Re: Ruby EOL in Cygwin 3.4.9?
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: > > 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 > > Sent: Wednesday, October 11, 2023 5:03 PM > > To: Hendrickson, Eric D ; cygwin@cygwin.com > > Cc: Eric @ Gmail > > 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 -- 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
Re: Ruby EOL in Cygwin 3.4.9?
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 Sent: Wednesday, October 11, 2023 5:03 PM To: Hendrickson, Eric D ; cygwin@cygwin.com Cc: Eric @ Gmail 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. -- 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
Re: Ruby EOL in Cygwin 3.4.9?
From: "Hendrickson, Eric D via Cygwin" Subject: Ruby EOL in Cygwin 3.4.9? Date: Wed, 11 Oct 2023 16:37:29 + > 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 -- 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
RE: Ruby EOL in Cygwin 3.4.9?
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 Sent: Wednesday, October 11, 2023 5:03 PM To: Hendrickson, Eric D ; cygwin@cygwin.com Cc: Eric @ Gmail 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. -- 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
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. -- 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
Ruby EOL in Cygwin 3.4.9?
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. -- 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
