Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
T
tpo
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 54
    • Issues 54
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 0
    • Merge Requests 0
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar

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.

  • The Tor Project
  • Web
  • tpo
  • Issues
  • #136

Closed
Open
Opened Jun 27, 2018 by cypherpunks@cypherpunks

add checksums to download page; make checksum vs. sig file purpose much clearer

Gpg recently failed to verify a Tor Browser download - a first for me. Since data errors in downloads aren't as common as years ago, I assumed an error in the *.asc sig file itself, or other issues.

Such as my Linux GPG version not playing well with the version used to sign Tor Browser.

I wanted to verify checksum of the downloaded TBB, but after a few searches on TorProject didn't find the checksum, I re-download TBB. It was faster in the long run, but it's a big package to re-download for users with limited data plans, when a few byte checksum would suffice to see if there was a download data error.

I propose that checksum files - or a prominent link, be added to the download page - not make users hunt them. That's how many well run projects seem to do it - app packages, sig files & checksums are all easily found, or have links on the same page.

The statement, "See our instructions on how to verify package signatures, which allows you to make sure you've downloaded the file we intended you to get. Also, note that the Firefox ESR in our bundles is modified from the default Firefox ESR " should be placed above the packages & sig files, where users are far more likely to see it.

The wording could be stronger, clearer - why users would want to verify the TBB / other packages PGP signatures of downloads, EVEN from TorProject's site (not rely solely on checksums). A brief statement why verifying signed packages is important & how it's unrelated to using checksums. If users (of anything) don't understand a real purpose or need, they're more likely to skip steps.

I could write something to make changes, additions & submit for consideration, but only if there's interest in making changes to general security methods to educate users, that work for many products.

  • Verification instructions: They're generally good & someone did a lot of work, but many users unfamiliar w/ PGP / GPG's real purpose & the procedures may be clueless.

On the Windows verify instructions (maybe Linux, OS X), it's unclear which signature & which "package" they're verifying. If they're installing GPG or gpg4win, the instructions should include steps (or link to clear instructions) to first verify GPG itself (once), then a separate verification of downloaded Tor products - EVEN from TorProject's https site.

The statement, "make sure you've downloaded the file we intended you to get." means little to non-gpg users or slightly familiar. To many, they downloaded the correct platform package, therefore they "have the file intended for their OS." As far as they know, they did everything required.

Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: tpo/web/tpo#136