Closed ennerf closed 2 years ago
Thanks for the bug report.
I think the issue here is that GitHub is serving the .txt file as application/octet-stream
which isn't correct. Windows then hands us back a byte array instead of a string as expected. From reading around it seems that maybe there's no way to fix this via the GUI, but, you can specify a custom MIME type when uploading assets via the GitHub API. The .txt
extension is an attempt to persuade web servers to do the right thing here, but apparently, GitHub's CDN is not such a web server.
A workaround is to just put the launch.win.txt
next to your download.html
file on your own web server (ditto for the Mac script), and then edit it post-generate to replace the URL with the one that isn't on GitHub releases. Your web server should serve it as text/plain
as PowerShell will be happy.
In the product there are three possible fixes here:
Support for making GitHub releases is already tracked internally in CO-86. It won't make the next release. The docs can be fixed now, however.
fwiw, specfically setting the content type does not seem to work either
iex (iwr -ContentType "text/plain" "https://github.com/HebiRobotics/Scope/releases/latest/download/launch.win.txt").Content
Would downloads from compliant servers break when invoking .RawContent
?
Well, RawContent
will try and interpret the HTTP headers as PowerShell expressions as you saw above, so that seems a bit risky.
-ContentType
seems to set the MIME type for uploads, not downloads.
This does seem to work though:
iex (iwr "https://github.com/HebiRobotics/Scope/releases/latest/download/launch.win.txt").ToString()
We'll update the generated HTML to use that command instead.
Well, RawContent will try and interpret the HTTP headers as PowerShell expressions as you saw above, so that seems a bit risky.
wow, I glanced over the warnings and didn't realize that it includes headers 👍
This does seem to work though
That looks like a good option! If that works independent of the MIME type, maybe you can also get rid of the workaround .txt
extension?
Could do, though it seems safer to double up the protection. I guess you'd prefer it to end in a .ps1
extension?
Chocolatey and the other services where I've seen this before seem to to call it install.ps1
. It looks more professional than the .txt
and makes it clear that it's part of the files that need to be uploaded.
Fwiw, Chocolatey uses iex ((New-Object System.Net.WebClient).DownloadString('<url>')
, which does work as well. I don't know whether that is more robust, but the extra verbosity makes it immediately obvious that it's downloading a file and executing it.
That expression does look safer, yeah. Relying on a ToString()
method is not really ideal. I'll switch us to using what Chocolatey does and then we can rename the script file too.
By the way, do you plan to use the self-signing mode for real / in production, or are you using it now just for testing and dev purposes?
No, I just haven't gotten to the signing point yet.
I'm also deliberately testing some things so I can provide some feedback to you. Our app is fairly complex and should be good for testing various corner cases.
On a blank VM this fails due to scripts being disabled in the execution policies. Calling the full Chocolatey command makes it work
Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://github.com/HebiRobotics/Scope/releases/latest/download/launch.win.ps1'))
OK, that's what we'll go with then.
Sure thing.
The link on the generated page for self-signed windows apps generates a
.Content
link that fails.Website:
Executing the command:
Changing it to
.RawContent
produces lots of warnings, but it executes and installs correctly:Full output: