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
  • #32823

Closed (moved)
Open
Opened Dec 20, 2019 by eighthave@eighthave

support Android SharedPreferences xml as a torrc format

With Tor Browser, Orbot, and other apps on Android, some Tor settings are managed via the SharedPreferences/PreferenceFragment Android classes. When used in their standard setup, these handle the whole lifecycle of preferences. Right now, we have to do a lot of tricks to get the settings from the Android classes, convert them to torrc format, then handle reloading Tor at the right time.

Android's SharedPreferences writes out to a standard xml file, e.g /data/data/org.torproject.android/shared_prefs/org.torproject.android_preferences.xml. This XML file has a simple format that has been the same since the beginning. If Tor can read this format as an optional torrc format, and also potentially automatically reload the config when that file changes, then the Android code will be drastically simpler. This will greatly improve the interaction around any kind of user-facing setting, like bridges, exit countries, pluggable transports, etc.

Here's an example of what the XML would look like:

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
    <boolean name="RunAsDaemon" value="true" />
    <boolean name="AvoidDiskWrites" value="true" />
    <string name="TransPort">auto</string>
    <int name="DNSPort" value="5400" />
    <string name="TransPort" value="auto" />
    <string name="Bridges">obfs4 77.81.104.251:443 115C90EBD0EB631C177560A872535772215478D9 cert=UsuF7oN4KNKviZP54JOyTCoCphrdM5gwZK4vT8GnCAcmqLUJEJxyw1dpko9a/ii6He4iZg iat-mode=0,obfs4 5.249.146.133:80 FAF3A0073330D6AD92F3B4874B0D945562A633EF cert=TRe8bAODtjcGij7EPQaUayWEOqR99wDh2l3B4hFtCsn1JTJCph03pRZ9tx8wynpLYKWMQg iat-mode=0,meek_lite 0.0.2.0:2 97700DFE9F483596DDA6264C4D7DF7641E1E39CE url=https://meek.azureedge.net/ front=ajax.aspnetcdn.com</string>
</map>

We might want an alternate format for bridge lines, where would be a dedicated XML file for only bridge lines with the name specifying the line number:

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
    <string name="0">obfs4 77.81.104.251:443 115C90EBD0EB631C177560A872535772215478D9 cert=UsuF7oN4KNKviZP54JOyTCoCphrdM5gwZK4vT8GnCAcmqLUJEJxyw1dpko9a/ii6He4iZg iat-mode=0</string>
    <string name="1">obfs4 5.249.146.133:80 FAF3A0073330D6AD92F3B4874B0D945562A633EF cert=TRe8bAODtjcGij7EPQaUayWEOqR99wDh2l3B4hFtCsn1JTJCph03pRZ9tx8wynpLYKWMQg iat-mode=0</string>
    <string name="2">meek_lite 0.0.2.0:2 97700DFE9F483596DDA6264C4D7DF7641E1E39CE url=https://meek.azureedge.net/ front=ajax.aspnetcdn.com</string>
</map>

Yxml is a 6k C XML parser in a single file under an MIT license. It has been maintained since 2013. It would fit the bill quite nicely. https://dev.yorhel.nl/yxml

Yes, XML is not an ideal format. We don't need the most problematic parts of XML for this, e.g. namespaces, custom entities, etc. and Yxml does not support them anyway.

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