Closed g-van-vreckem closed 10 years ago
Guys, please search for duplicates before opening new issues. And direct questions / support requests to the mailing list instead if the issue tracker. And if reporting issues, use the right project ...
@g-van-vreckem to clarify: you probably wanted to be helpful, I am sure. Relying on other people to search for duplicates, the same people who are also expected to fix the issue, sends an unfortunate, probably unintended message, though... I encourage you, as a matter of courtesy, to follow the rule of thumb in the future that you should spend as much time and effort on reporting bugs as you would like others to spend on fixing them.
Sorry, about this, forgot to check the closed bugs again. Wrong project, ok this is rather confusing I tough I was using msysgit/git and not the build environment. I did find the repository by following the link on the home page: http://msysgit.github.io/ is it the wrong link?
I did look for a dupe by looking at the code date (1 months old) which is too old to have solved the issue and the (open) issues between the 24 and now.
You have my sincere apologies for missing the complexity of your setup but why did you close all the issues? it's not in anyway solved, the download from the home still contains the vulnerable version.
Maybe you could explain the logic in closing every open bug referencing the issue while you seem to believe that in fact the issue is present and unsolved?
Closing a major security bug by as you did by off-loading upstream and waiting seems rather foolish, even if it is your standard policy to simplify your work due to the poor bug dependency management allowed by GitHub.
After a good look at the forum archives, unfortunately I have not found any assessment of remote execution risks. All I have seen in the archive is:
Well I've now worked for 8 hours to determine if in fact there is any exploit possible and I'm not much more advanced only a slight suspicion that maybe we may be safe.
That long after the disclosure, not having any reliable information out is frustrating.
Since it looks like you have a policy in place for everything, I would suggest that communication on security announcement cannot be addressed by being buried in a noisy support forum nobody want to subscribe to. At the minimum you need an announcement group for that.
Since the vulnerable bash is installed and distributed by this package, there should be a message on the home stating what the user should do, even if it is to say that you do not know yet and referencing a sticky googlegroups thread if you want to stick to that nightmarish platform.
Alternatively there should be one bug left open visibly since the bug was acknowledged as present. Voluntarily removing the only easy way for the user to find if they are at risk as you are actively doing is simply wrong.
I'm not more fond of the way GitHub handled communication on the very same issue for their Windows Clients using your library: Leaving everyone in the dark with no patch no communication and a visibly vulnerable bash on every installation is simply shameful. Was that the same upstream and no bug left open mentality at work?
https://github.com/msysgit/msysgit/issues/253 is the open and not yet handled issue concerning the bash security bugs. https://github.com/msysgit/msysgit/issues/254 is the PR by me fixing most of the bash bugs.
And I even started a discussion on the mailing list where nobody replies to, so sorry I can not see how we don't deal with it.
@t-b don't worry. Everybody sees that you are the only one who actually works on a remedy. You're doing great!
I was too hash sorry about that, please accept my apologies. A frustrated Gauthier
@g-van-vreckem it is understandable that you are frustrated. It is likewise understandable that @t-b is pretty frustrated by the way people thank him his enthusiasm and hard work...
@g-van-vreckem @dscho I'm not frustrated just complaining a bit about all the noise which distracts from real work ;)
cygwin updated bash for some critical vulnerability: https://cygwin.com/ml/cygwin/2014-09/msg00409.html Note that the patch leave much to be desired, and is likely to need further patching.
Questions: Is your bash emulation based on bash code and is similarly vulnerable ? Would it be remotely exploitable (openSSH) ?