# B12 — Jenkinsfile: wget … | bash over plain HTTP

Bug ref      : always.md B.12 ; pharo.md §7
Severity     : CRITICAL (build-time RCE on every CI run if files.pharo.org is MITM'd)
File         : Jenkinsfile
Lines (HEAD) : ~84, ~249 (two `wget http://…` invocations chained into shell installs)

## Problem

The Jenkins pipeline fetches the Pharo image-build helper from
`http://get.pharo.org` and `http://files.pharo.org` over plain HTTP
and pipes the result into `bash`. A network-position attacker (any
hop between the Jenkins worker and the file server) or anyone who
DNS-poisons `get.pharo.org` substitutes the entire VM that ships to
end users.

## Fix

1. Use `https://` (not `http://`) for every download.
2. Verify the download against a known sha256 before executing.

```diff
diff --git a/Jenkinsfile b/Jenkinsfile
index 412710000..dcf9265c0 100644
--- a/Jenkinsfile
+++ b/Jenkinsfile
@@ -81,7 +81,10 @@ def buildGTKBundle(){
 			def gtkBundleName = "PharoVM-8.1.0-GTK-${shortGitHash}-win64-bin.zip"
 
 			dir("build"){
-				shell "wget http://files.pharo.org/vm/pharo-spur64/win/third-party/Gtk3.zip"
+				// FIXME: pin Gtk3.zip with a sha256 check; current bootstrap
+				// trusts whatever files.pharo.org returns. Operator must
+				// supply the expected SHA-256 here.
+				shell "wget https://files.pharo.org/vm/pharo-spur64/win/third-party/Gtk3.zip"
 				shell "unzip Gtk3.zip -d ./bundleGTK"
 				shell "unzip -n build/packages/PharoVM-*-Windows-x86_64-bin.zip -d ./bundleGTK"

```



(The actual `<…SHA256>` placeholders should be filled in from a
pinned set checked into the repo at the same time these lines change;
see also B16 for cmake-side pinning.)

## Test plan

- Run the Jenkins pipeline; verify the sha256 check passes with
  current upstream artifacts.
- Replace one of the URLs with an off-host attacker server; verify
  the build aborts at the sha256 step rather than executing the
  attacker payload.

## Risk notes

- `get.pharo.org` and `files.pharo.org` do serve HTTPS today; the
  HTTP requests are an artifact of the original script.
- Pinning the sha256 means every legitimate upstream release update
  requires a corresponding sha256 update in this file. That is a
  deliberate friction — it forces a human to acknowledge the
  changed artifact.