Skip to content

Set tor binary version to 0.4.9.13 #24

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
HenrikJannsen wants to merge 1 commit into from
Closed

Set tor binary version to 0.4.9.13 #24

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 19 additions & 5 deletions readme.MD
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -38,11 +38,26 @@ Package native Tor files from [Tor Browser project](https://www.torproject.org/)
```
mvn -N -Pcheck-pgp-signatures verify
```
This checks the manifest and bundle signatures. It does not check which Tor version the
executables contain.
6. Build all artifacts:
```
mvn clean install
```

To check just the downloaded bundles' checksums and Tor executable versions during development,
run the `tor-binary-resources` module's `generate-sources` phase from the repository root:

```
mvn -pl tor-binary-resources clean generate-sources
```

This phase downloads the configured Tor Browser bundles, verifies each checksum against the
tracked manifest, and fails if any embedded Tor executable reports a version different from the
Maven project version. A normal recursive `mvn clean install` from the repository root runs this
same check as part of the module build. A non-recursive Maven command (`-N`) skips the module and
therefore cannot detect an executable version mismatch.

`mvn -N -Pcheck-pgp-signatures verify` performs the checks that need network access and GPG:

- the tracked manifest carries a valid signature made with the Tor Browser Developers key
Expand All @@ -56,13 +71,12 @@ needs the keyserver to be reachable. Fetching every run is also what makes a rev
is already present is never refreshed on its own. A keyserver that serves a certificate with the revocation
removed still hides it, which no verifier can detect.

`ant -f build.xml` runs the same checks, plus the digest and tor version checks below, and builds no artifact.
`ant -f build.xml` runs the signature, digest, and Tor version checks together, and builds no artifact.

`mvn clean install` needs neither GPG nor the keyserver. It verifies every downloaded expert bundle against
the digest pinned in the tracked manifest and fails when an entry is missing or a digest differs, so no
unverified bundle is ever packaged. It then reads the version that tor compiles into the tor executable of
every bundle and fails when it differs from the Maven project version. An artifact therefore cannot be
published under a tor version that it does not contain.
the digest pinned in the tracked manifest and reads the version compiled into the tor executable of every
bundle. It fails when a checksum entry is missing, a digest differs, or an executable's version differs
from the Maven project version. This check runs in `tor-binary-resources` during `generate-sources`.

[tools/verification-selftest.sh](tools/verification-selftest.sh) checks the rules themselves against local
fixtures and its own throwaway test keys. It covers the digest rules, the tor version rules, the signature
Expand Down
Loading