Powershell: AppImage publishing relies on script hosted on another web site

[SteveL-MSFT]

Merged https://github.com/PowerShell/PowerShell/pull/2082 prematurely. @lzybkr brought to my attention that his concern wasn't addressed.

https://github.com/PowerShell/PowerShell/blob/master/tools/appimage.sh#L41

Relies on

https://github.com/probonopd/AppImages/raw/e05cbebc62c86f8c602d74d9050bbfbf10df1c69/functions.sh 

which internally gets and executes other scripts.

If any of these scripts are compromised, we'll run arbitrary code as part of our publishing pipeline.
We need to resolve this vulnerability before we start publishing appimages.

CC @raghushantha @andschwa @probonopd

[andschwa]

This can't get compromised, it's pinned to a commit hash. The only way to compromise it would be to create a hash collision, and overwrite that on the repo, or compromise GitHub. But if GitHub is compromised, or a hash collision is made, then the game's up anyway.

[probonopd]

I think @SteveL-MSFT is concerned with the files that the script mentioned above downloads (search for "wget"). The (only?) solution is to mirror the script and the files it downloads, and change the links in the script to your mirror.

This is like using a toolchain -- you have to download it from somewhere (and trust that location), or mirror it and build it yourself from the mirrored sources.

[lzybkr]

That's exactly what @SteveL-MSFT and I are concerned about.

Another concern is brittleness and being able to reproduce issues. There is no coherent package or set of packages, pieces are pulled from releases, master, and latest successful build in CI.

If AppImage were accepted into a trusted repository - then I think we could happily use these tools.

[SteveL-MSFT]

A trusted repository would be ideal. Caching local copies may be a viable short term solution.

[andschwa]

Hm... I mean we currently download wget and lots of other packages from each distro's repository already (outside of this script). What exactly are we concerned about here?

Edit: Oooh, I see the concern now, it's over the binaries used by AppImage, .e.g AppRun being downloaded from GitHub.

[joeyaiello]

I think the key phrase there is "each distro's repository" which I would equivocate with "trusted repository".

[probonopd]

If your definition of a "trusted repository" only covers distribution repositories, then it it unlikely to happen soon. Even though someone has filed an intent to package for debian, it will be quite some time until it lands in mature distributions that are suitable for building on.

So I see two ways:

1. You mirror appimagetool, and we rewrite the script that generates the AppImage to use it (no other things downloaded via wget)
2. You build at least runtime.c as part of your builds, and we rewrite the script that generates the AppImage to use it, mksquashfs (from the distribution repository) and a even more bash scripting (no other things downloaded via wget)

2 is significantly more work than 1. Which route do you want to go?

[SteveL-MSFT]

The first option seems acceptable to me. Thanks!

[probonopd]

@SteveL-MSFT implemented here. Travis CI build running.

[joeyaiello]

This can't get compromised, it's pinned to a commit hash. The only way to compromise it would be to create a hash collision, and overwrite that on the repo, or compromise GitHub. But if GitHub is compromised, or a hash collision is made, then the game's up anyway.

@andschwa the timing of this statement is pretty hilarious given the SHA-1 news. Linus wrote an interesting piece on why it's not a big deal for Git given that hashes aren't being used for security, but I guess he wasn't thinking of our particular scenario. ;)

[andschwa]

@joeyaiello I like to think that I jinxed that!