-
-
Notifications
You must be signed in to change notification settings - Fork 140
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Please add gsudo.exe to the release #88
Comments
Hi rfay. A few ways to workaround this: |
We're building our installer using nsis, and don't have a good way to unzip in nsis. We're starting to download gsudo during install instead of bundling it, because it now triggers virus checkers (especially in chocolatey). You'll have trouble with this on your next release, see https://community.chocolatey.org/packages/gsudo and https://www.virustotal.com/gui/file/136ac9437a248786a997b7a563e17383ec6779d58e01ccb9ca07fc9e2ebc70b5/detection/f-136ac9437a248786a997b7a563e17383ec6779d58e01ccb9ca07fc9e2ebc70b5-1608504533 There seems to be no appeal or anything; if anything triggers any of the gazillion virus checkers in virustotal, they leave the release embargoed. The reason your 0.7.3 release still works is they grandfathered in old releases, since they hadn't started the virus checking when it was created. But when you create a new one, people won't find it by default. Working on this in ddev/ddev#3066 - Our short-term solution is forking gsudo into drud/gsudo and making a release there, but it would be much better to be able to get the exe from gerardog/gsudo. |
So your problem is rooted on #87 (virus detection). Let's fix that one first. If you fork gsudo you 1) loose the code-signing 2) AI based antivirus will flag it as a virus again so you would have to submit that custom build by hand to each AV. Another option would be to upload |
Yeah, we don't lose the code signing because we uploaded your binary :) Just unzipped your released zipball. Essentially we are just uploading gsudo.exe "somewhere else" |
For the virustotal scan, if there are one to four positives, then they are assumed to be false positives, and it passes the scan, and gets automatically approved if it is a trusted package, or otherwise goes for a moderator review. If there are five to nine positives, then it fails with a warning, and goes for moderator review, even if it is trusted. If there are ten or more positives, then it fails, and waits for the maintainer to fix it. Even if the package has more than ten positives, the package maintainer can still make a review comment, which will put it in the queue for a moderator to look at. |
Yes, one to four is accepted there, I didn't understand that. Since we stopped bundling gsudo and nssm, ddev is down to one, so we got out of trouble. I never was successful getting any moderator review, so our strategy of not bundling gsudo and nssm got us down to an acceptable number of false positives. |
Hmm, that is not good. Do you still have a link to the version where you tried to get a review and no one responded? |
IIRC https://community.chocolatey.org/packages/ddev/1.17.2#virus was one of them. Seems to show 6, also seems to show approved now, but Windows users didn't get new versions during a couple of months of releases. It would be nice if virustotal could actually validate some of those virus checkers, or if the virus checkers were slightly transparent about their "detections", or responded to reports of false positives. |
Looking at the that one, it was approved and made available the same day that it was uploaded. |
It looks like was the first one rejected I think, https://community.chocolatey.org/packages/ddev/1.17.3 - and they were rejected until we stopped bundling gsudo and nssm. Caught me by surprise. (Now ddev downloads those at install time to work around this.) Basically they started the virustotal policy right then apparently, without any notice AFAICT. But we should be having this conversation in another venue :) |
@rfay you are now delivering gsudo via a Chocolatey dependency, right? |
No, the ddev installer also will install gsudo if it's not already available. Not everybody uses chocolatey. |
What if you install gsudo via the installation script provided in the readme?
|
Yeah, there are several easy ways to install it. The reason for this request is I'm no expert at nsis, and nsis is happy to pull an executable and doesn't seem to be as happy at doing other things. https://github.com/drud/ddev/blob/master/winpkg/ddev.nsi I understand it seems a little arbitrary. OTOH, it's not unusual for a raw binary to be available for download. (And please don't forget to add a file with sha hashes for all the artifacts. We're all worried about supply-chain exploits, and I'm trying to start checking all the upstream components of ddev) Thanks for all your work on gsudo! |
Hi rfay. After long considering this, I am sorry to tell you that it doesn't make sense to me to alter the current distribution flow. The proper way to install gsudo is thru it´s .MSI, or choco, or winget, or scoop. Just putting the EXE in the path would make bash/wsl/powershell user flows not behave as documented. I would suggest your installer run the following command: PowerShell -Command "Set-ExecutionPolicy RemoteSigned -scope Process; [Net.ServicePointManager]::SecurityProtocol = 'Tls12'; iwr -useb https://raw.githubusercontent.com/gerardog/gsudo/master/installgsudo.ps1 | iex" Or, download https://github.com/gerardog/gsudo/releases/download/v1.3.0/gsudo.v1.3.0.zip then unzip. Unzipping should be doable on custom installers. |
Thanks for considering! |
Issue Description
We'd like to be able to directly download gsudo.exe instead of getting the zipball. Could the release include gsudo.exe (and a hash file)?
Thanks!
The text was updated successfully, but these errors were encountered: