Opened 6 years ago

Last modified 4 years ago

#10066 reopened defect

Incorrect git hash used by makexpi.sh and merge-rulesets.py

Reported by: mikeperry Owned by: zyan
Priority: High Milestone:
Component: HTTPS Everywhere/EFF-HTTPS Everywhere Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

In makexpi.sh, https-everywhere does:

# Used for figuring out which branch to pull from when viewing source for rules
GIT_OBJECT_FILE=".git/refs/heads/master"
export GIT_COMMIT_ID="HEAD"
if [ -e "$GIT_OBJECT_FILE" ]; then
    export GIT_COMMIT_ID=$(cat "$GIT_OBJECT_FILE")
fi

Unfortunately, this process extracts whatever master is pointing at, regarless of the release you are building.

merge-rulesets.py then reads in the env var $GIT_COMMIT_ID to shove it into the resulting default.rulesets file.

This makes reproducible builds difficult, because that random 'master' commit hash ends up in the ruleset file in the resulting xpi, which has obviously no relation to whatever release tag you're building.

Child Tickets

Change History (5)

comment:1 Changed 6 years ago by zyan

Owner: changed from pde to zyan
Priority: normalmajor
Status: newassigned

comment:2 Changed 5 years ago by jsha

Resolution: wontfix
Status: assignedclosed

I think this is working as intended. If you want to build a given tag, e.g. 4.0.2, you run:

./makexpi.sh 4.0.2

The script creates a temporary checkout directory, cds into it, checks out the tag, and re-runs makexpi. In that context the master commit id is correct. I tried running ./makexpi.sh 4.0.2 starting from two different head commit ids, and got identical output.

comment:3 Changed 5 years ago by jsha

Resolution: wontfix
Status: closedreopened

comment:4 Changed 5 years ago by jsha

Resolution: worksforme
Status: reopenedclosed

comment:5 in reply to:  2 Changed 4 years ago by gk

Resolution: worksforme
Severity: Normal
Status: closedreopened

Replying to jsha:

I think this is working as intended. If you want to build a given tag, e.g. 4.0.2, you run:

./makexpi.sh 4.0.2

The script creates a temporary checkout directory, cds into it, checks out the tag, and re-runs makexpi. In that context the master commit id is correct. I tried running ./makexpi.sh 4.0.2 starting from two different head commit ids, and got identical output.

With the new submodules this is not working anymore for us in our Gitian environment as

1) the submodules are cloned again which we don't want during the build step itself (all inputs should be fetched beforehand).

2) cloning actually breaks in our Linux VM due to a certificate error (thus, even if 1) were not a problem this would still be a show-stopper for us).

Therefore, reopening.

Note: See TracTickets for help on using tickets.