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
  • Activity
  • Create a new issue
  • 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.

  • Legacy
  • TracTrac
  • Issues
  • #5096

Closed
Open
Opened Feb 12, 2012 by Robert Ransom@rransom

Support transferring bridge addresses in QR codes

At some point (maybe in days, maybe in weeks), we will start distributing bridge addresses which contain multiple 80-bit-or-longer base32-encoded ‘cryptovariables’ (I don't know any other appropriate general term for them). Orbot users will want to not retype them into their puny phone keyboards.

See the ‘libzbar’ package for a QR-code decoder under the LGPL. See ‘libqrencode’ for a QR-code encoder under the LGPL. Neither of these can currently handle binary strings containing NULs (you don't want to be parsing/repacking bridge lines anyway, but you need to know about that bug before you use the QR-code hammer to pound e.g. OTR/GPG fingerprints, BitTorrent info hashes, or Curve25519/Ed25519 public keys).

Also, if you interact with a QR-code decoder through e.g. XML, don't get bobbytabled. (P.S. ‘zbarimg --xml’ sucks.)

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#5096