Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #10066

Closed (moved)
Open
Opened Oct 31, 2013 by Mike Perry@mikeperry

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

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.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#10066