tor-dev

tor-dev@lists.torproject.org

5 participants
3594 discussions

Rethinking Bad Exit Defences: Highlighting insecure and sensitive content in Tor Browser
by Donncha O'Cearbhaill 06 Apr '17

06 Apr '17

Hi all, The Tor bad-relay team regularly detects malicious exit relays which are actively manipulating Tor traffic. These attackers appear financial motivated and have primarily been observed modifying Bitcoin and onion address which are displayed on non-HTTPS web pages. Increasingly these attackers are becoming more selective in their targeting. Some attackers are only targeting a handful of pre-configured pages. As a result, we often rely on Tor users to report bad exits and the URLs which are being targeted. In Firefox 51, Mozilla started to highlight HTTP pages containing password form fields as insecure [1]. This UI clearly and directly highlights the risk involved in communicating sensitive data over HTTP. I'd like to investigate ways that we can extend a similar UI to Tor Browser which highlight Bitcoin and onion addressed served over HTTP. I understand that implementing this type of Bitcoin and onion address detection would be less reliable than Firefox's password field detection. However even if unreliable it could increase safety and increase user awareness about the risks of non-secure transports. There is certainly significant design work that needs to be done to implement this feature. For example, .onion origins need be treated as secure, but only if they don't included resources from non-secure origins. We would also need to make the onion/bitcoin address detection reliable against active obfuscation attempts by malicious exits. I'd like to hear any and all feedback, suggestions or criticism of this proposal. Kind Regards, Donncha [1] https://blog.mozilla.org/security/2017/01/20/communicating-the-dangers-of-n…

7 8

Counter-RAPTOR Paper
by Yixin Sun 06 Apr '17

06 Apr '17

Hi all, Our proposed defenses (Counter-RAPTOR) against active routing attacks on Tor will soon appear at IEEE S&P in May. It's also available here: https://arxiv.org/abs/1704.00843 In short, we have two lines of defenses: (1) Entry Guard Selection (proactive defense, https://github.com/inspire-group/Counter-Raptor-Tor-Client) (2) BGP Monitoring on Tor relays (reactive defense, in progress of making it public) Please let us know if you have any questions/comments. Thanks! Yixin

2 1

"Anomalous keys in Tor relays" technical report now available
by Laura M. Roberts 05 Apr '17

05 Apr '17

Hello, Tor devs! We have just published a (not yet peer-reviewed) technical report entitled "Anomalous keys in Tor relays." https://nymity.ch/anomalous-tor-keys/ The project was inspired by the "Mining Your P's and Q's" paper from Heninger et. al., and in it, we take a closer look at the RSA keys used in Tor since 2005. We found that entities had purposely created anomalous keys in order to attack Tor's onion services and that researchers had inadvertently created weak keys while conducting experiments on Tor. (None of the weak keys we found are affecting the current Tor network.) We welcome your questions and feedback! Regards, George, Claudia, Laura, & Philipp

1 0

Re: [tor-dev] Comments on proposal 279 (Name API)
by str4d 04 Apr '17

04 Apr '17

On 04/04/2017 12:50 AM, Nick Mathewson wrote: > On Mon, Apr 3, 2017 at 8:20 AM, George Kadianakis <desnacked(a)riseup.net> wrote: >> Nick Mathewson <nickm(a)torproject.org> writes: >>> Section 2.1 and elsewhere: >>> >>> I suggest that we require all address suffixes to end with .onion; >>> other TLDs are not reserved like .onion is, and maybe we shouldn't >>> squat any we haven't squatted already. I think we might also want to >>> have all output addresses end with .onion too. >>> >>> I suggest also that we might want to reserve part of the namespace >>> for standardized namespaces and some for experimental or local ones. >>> Like, if we standardize on namecoin that could be .bit.onion, but if >>> we don't, it could be .bit.x.onion. I2P has been doing this for years with *.b32.i2p for unique identifiers vs *.i2p for hosts.txt-style naming, and I'm planning on writing an I2P proposal to create a formal registry of 2LDs that implementations need to know about, so we have the ability to expand in future under the .i2p TLD. So I don't think it's a stretch for users to understand (although I have other concerns, see below), and I'd be keen to have a common standard for specifying subdomains that we can use for interoperability :) >>> >> >> I have mixed feelings about keeping the .onion suffix. >> >> One one hand it seems like The Right Thing to do, since we managed to >> get .onion standarized in the IETF which comes with various >> benefits. Also, starting to squat other tlds arbitrarily seems like a >> silly thing to do. This is the safest space for Tor to work in from a technical perspective. More specifically, I've been following discussion in DNSOP ever since the original special-use names draft (containing .onion, .i2p etc) was posted, and there is no way that the IETF is going to standardise any new TLD for non-DNS (see below). It's increasingly unlikely that the non-.onion TLDs in the draft will either (without industry support like .onion had), so no CA-supported SSL certs for I2P :( >> >> However, I also dislike asking users to visit something.bit.onion >> instead of something.bit, since people are not used to the second tld >> having a semantic meaning, and I can imagine people getting very >> confused about what it means. There's also the problem of transport-agnosticism. Assume there's some FOOnet that is created for naming that we all decide we want to use. Users would probably expect that FOOnet names all exist in the same space, which would not be the case if we had *.foo.onion, *.foo.i2p, etc. I'm thinking along the lines of IPv4 vs IPv6, where you can have a DNS name delegate to both via A and AAAA records; you wouldn't want the name changing just because the underlying transport changed. > > Indeed. And I'm not only concerned about people becoming confused: I > am also worried about confused programs. > > Right now, it is easy to answer the question "will Tor handle this > address specially" -- the only special addresses are the ones ending > with ".onion", and the legacy suffices ".exit" and ".noconnect" as > documented as address-spec.txt. But if we allowed arbitrary TLDs in > this proposal, then _any_ hostname would potentially be an address > that Tor would handle specially. > There is a draft currently in working-group last call that will specify a .alt TLD (or possibly .alt.arpa, it's still being debated [1]), that future non-DNS names will have to be under. Part of the proposed benefit is that with a standard TLD, DNS resolvers can just stub out that entire namespace, ie. if fqdn.endswith('.alt'): do_non_dns_lookup(fqdn) else: gethostbyname(fqdn) Presumably, browsers would do so as well. So it's possible that you could have *.foo.alt as the URI, but only *.foo is displayed in the browser (along with some chrome indicating it is non-DNS), similar to how only the base domain name is shown for some URIs (IIRC that's an SSL cert verification thing). The question then is how a browser would handle *.foo being typed in. You wouldn't want to query DNS and then try *.foo.alt afterwards, as that would be terrible for privacy, but if they tried *.foo.alt first, and didn't have FOOnet installed, should they try *.foo in the DNS? The browser either needs to know the full contents of *.alt (which is not possibly because by design it will have no official registration), or every registered TLD in DNS (which won't ever be added as a restriction because of various legacy local-net vendor TLDs like *.home). So with this approach, it's likely that .alt would need to stick around. Lots to think about here... str4d [0] https://tools.ietf.org/html/draft-ietf-dnsop-alt-tld-08 [1] https://www.ietf.org/mail-archive/web/dnsop/current/msg19983.html

1 0

Circuit times
by grarpamp 04 Apr '17

04 Apr '17

Anything going to blow up if set anywhere from 1k to 1M? CBT_NCIRCUITS_TO_OBSERVE

1 0

[prop269] [prop270] Ideas from Tor Meeting Discussion on Post-Quantum Crypto
by isis agora lovecruft 03 Apr '17

03 Apr '17

Hey hey, In summary of the breakaway group we had last Saturday on post-quantum cryptography in Tor, there were a few potentially good ideas I wrote down, just in case they didn't make it into the meeting notes: * A client should be able to configure "I require my entire circuit to have PQ handshakes" and "I require at least one handshake in my circuits to be PQ". (Previously, we had only considered having consensus parameters, in order to turn the feature on e.g. once 20% of relays supported the new handshake method.) * Using stateful hash-based signatures to sign descriptors and/or consensus documents, and (later) if state has been lost or compromised, then request the last such document submitted to regain state (probably skipping over all the leaves of the last used node in the tree, or the equivalent, to be safe). (This requires more concrete design analysis, including the effects of the large size of hash-based signatures on the directory bandwidth usage, probably in a proposal or longer write up, should someone awesome decides to research this idea further. :) Thanks to everyone involved in the breakaway group, and I apologise, but I don't actually remember all the attendants off the top of my head. If either of these were your idea, please message me off-list and I'll ensure you're credited in the eventual proposal(s)/documentation. Best regards, -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://fyb.patternsinthevoid.net/isis.txt

2 2

Re: [tor-dev] GSoC 2017 - unMessage: a privacy enhanced instant messenger
by Felipe Dau 03 Apr '17

03 Apr '17

Here is an update with the final proposal I submitted to GSoC. Thanks, -Felipe # unMessage: an anonymity enhanced instant messenger In an age where spying, surveillance and censorship evidently became regular practices by various kinds of attackers, it is sensible to be concerned about instant messaging applications, which are very popular communication tools that handle private and identifying information. Such a scenario demands solutions to prevent users from harm these attacks might cause. There are currently good solutions such as [Signal], [Wire] and [OMEMO] apps that make end-to-end encrypted conversations possible. Although such apps successfully provide privacy, they have a great dependency on servers and metadata in order to work and they are not able to provide anonymity. An app that solves this problem is [Ricochet], by not having such dependencies. However, it heavily relies on the transport it uses and does not offer its own encryption layer. [unMessage] is also one of those solutions: a peer-to-peer anonymity enhanced instant messenger written in Python that I have been working on for a while with [David Andersen] - my advisor. unMessage uses its own end-to-end encrypted [protocol] to maintain conversations, focusing in not depending on servers, metadata and transport. We have recently released an alpha version which should be easy for developers to install and test its current features such as message exchanges, authentication, and voice chat, but there is still a lot of work to do in order to achieve a mature state where users can trust it due to its properties and usability. As we believe unMessage has potential to become a great anonymity enhancing app with a code that is simple, readable and therefore easy to maintain, I propose to work on it during this year's Google Summer of Code with the support of the Tor Community to to make it closer to maturity. We expect to implement fixes, improvements and features from our discussions (on its [tracker] and [tor-dev]) in order to turn it into a maintainable, feature-rich and useful app which everyone can benefit from. ## Technologies unMessage's features were possible with the use of the following technologies: - Transport makes use of [Twisted], [Tor Onion Services] and [txtorcon] - Encryption is performed using the [Double Ratchet Algorithm] implemented in [pyaxo] - which uses [PyNaCl] - Authentication makes use of the [Socialist Millionaire Protocol] implemented in [Cryptully] - Transport metadata is minimized by Tor and application metadata by the unMessage [protocol] - User interfaces are created with [Tkinter] for the [GUI] and [curses] for the [CLI] - Voice chat uses the [Opus codec] for constant bitrate encoding ## Contributions Since its current (alpha) release, we have been discussing it with [Patrick Schleizer] and [HulaHoop] from [Whonix], who are making great contributions to help us test it, as well as suggesting new features and improvements. We are also working to run it on Whonix (which will allow it to be run on Tails as well) with help from [meejah] by adding a new feature to txtorcon to make unMessage (and all the apps that use txtorcon) "Control Port Filter friendly". Since the introduction of this project for GSoC, [dawuud] and [meejah] became interested in contributing and mentoring it and also assisted me on making this proposal. ## Tasks The project is split into tasks, each assigned an ID (in parenthesis) that is used to compose the timeline. I have been generous with how much time each task will demand and I am also leaving the whole week of each evaluation to review and make sure the deliverables meet expectations. Therefore, it is possible that I am able to work on additional tasks in case they consume less time than planned. ### Improve setup script (T1) This task will improve unMessage's `setup.py` by removing redundant package metadata, use files for the requirements and offer development requirements. This task will be tracked in [issue 35]. ### Use attrs (T2) [attrs] is used to simplify the code by removing boilerplate, make it more concise, and consequently improve its quality. Classes definitions will be modified to use attrs' declarations so that attributes have default types and values, as well as validation. This task will be tracked in [issue 34]. ### Support file transfer (T3) unMessage is able to support various elements of a conversation such as requests, messages and authentication. New elements to transmit file requests and the actual files will be added and handle by the elements parser. This task will be tracked in [issue 12]. ### Add a logger (T4) There is currently no logging being done and in order to debug, the only possible approach is using the UIs. A module will be added to send logs to the terminal and a file. This task will be tracked in [issue 30]. ### Make functions/methods asynchronous (T5) unMessage's initial implementation did not use Twisted and it had pre-defined callbacks in order to continue the path of the action it was performing. It later migrated to Twisted but the pre-defined callbacks are still used. Such callbacks will be removed and the functions that are part of these asynchronous actions will return `Deferred`s to make an actual callback chain. This task will be tracked in [issue 21]. *This task will be split into two (T5A and T5B) as it poses a higher level of complexity. I intend to deliver its first version, receive feedback from mentors and make another iteration so that it meets our expectations.* ### Add a test suite (T6) There is not a single test written for unMessage and that is crucial to continue its development. The test suite will be made with [pytest] and will also use [hypothesis] for fuzzing/property tests. Not only tests will be written, but some parts of the code will be refactored. I do not expect to achieve 100% converage, but test the most important parts of unMessage (mainly the `peer` module). Also, as I am not familiar with User Interface tests, these will not be part of the task (we are also planning to use a different framework for the GUI, so its tests will only be created after there is a decision). This task will be tracked in [issue 33]. *This task will be split into two (T6A and T6B) as it poses a higher level of complexity. I intend to deliver its first version, receive feedback from mentors and make another iteration so that it meets our expectations.* ### Deliverables - Mid-term 1: Tasks 1, 2, 3 and 4 - Mid-term 2: Tasks 5A and 6A - Final: Tasks 5B and 6B ### Timeline Tasks/Weeks | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 ------------+---+---+---+---+---+---+---+---+---+----+----+----+---- T1 | X | | | | | | | | | | | | ------------+---+---+---+---+---+---+---+---+---+----+----+----+---- T2 | X | | | | | | | | | | | | ------------+---+---+---+---+---+---+---+---+---+----+----+----+---- T3 | X | X | | | | | | | | | | | ------------+---+---+---+---+---+---+---+---+---+----+----+----+---- T4 | | X | X | | | | | | | | | | ------------+---+---+---+---+---+---+---+---+---+----+----+----+---- T5A | | | | X | | X | | | | | | | ------------+---+---+---+---+---+---+---+---+---+----+----+----+---- Mid-term 1 | | | | | X | | | | | | | | ------------+---+---+---+---+---+---+---+---+---+----+----+----+---- T6A | | | | | | | X | X | | | | | ------------+---+---+---+---+---+---+---+---+---+----+----+----+---- Mid-term 2 | | | | | | | | | X | | | | ------------+---+---+---+---+---+---+---+---+---+----+----+----+---- T5B | | | | | | | | | | X | | | ------------+---+---+---+---+---+---+---+---+---+----+----+----+---- T6B | | | | | | | | | | | X | X | ------------+---+---+---+---+---+---+---+---+---+----+----+----+---- Final | | | | | | | | | | | | | X ### Stretch goals As mentioned in the previous section, depending on how the development of each task it is possible that there will be more time avaialable to work on other ones. We would like to prioritize The following tasks in case that happens. #### Use automat There are certain objects in unMessage that are state machines. Their implementation are very simple and limited as initially they were not designed as state machines. In order to turn them into real state machines, [automat] will be used. This task will be tracked in [issue 26]. #### Offline messages As part of unMessage's design, no servers are used to establish and maintain conversations. As a consequence, peer-to-peer communication requires users to only be able to chat while both are online. Although unMessage's protocol supports asynchronous communication, this limitation forces conversations to be synchronous. In order to solve this problem, a [Tahoe-LAFS] grid will be used to temporarily store unMessage's packets for peers that were not available when they were sent and can be retrieved later once the peers are online. This task will be tracked in [issue 32]. # Background I am a Senior studying Computer Engineering at the Federal Technological University of Parana in Brazil. In January of 2014 I went to the U.S. for an exchange program, which lasted until December. During the Summer of that same year, I joined a research project lead by David Andersen where I learned about Anonymous Communication and became so attracted to the field that I continued to be part of the project since then. We have mostly worked on [nymphemeral], [pyaxo], [nymserv] and recently, unMessage. # Code sample I have a few repositories on my [GitHub profile] and I recommend taking a look at the ones referenced above, but specially [unMessage] and [nymphemeral], which are the ones I have mostly worked on. # Why The Tor Project? As I mentioned, I have been studying Anonymous Communication for almost three years now and I intend to keep doing it not only because I enjoy it, but because it is an important field capable of helping millions of people around the world. In my opinion, The Tor Project is the biggest organization of its kind and working with people responsible for software I run everyday is a dream of every developer. The Tor community continues to grow every day and I believe that participating in the Google Summer of Code will also contribute to that. # Experiences with free software development environments Since I joined the research project, I have been mostly working with David Andersen on the projects I mentioned previously and git/GitHub make our work a lot easier to work in parallel on the same code, manage tickets to help us keep track of the development and interact with contributors interested in what we do. Whenever I see a project which I can contribute to, even if a it is a small change, I open a ticket or make a pull request if I am able to. My [GitHub profile] lists all my contributions. PyNaCl is one of the recent projects I contributed to. While working on pyaxo I noticed some of the encryption calls could be improved to simplify their usage by making an argument optional. The developer who reviewed the pull request was very positive about it and assisted me while updating the docs to cover this new change. While working on unMessage I asked Patrick Schleizer and HulaHoop for help as it would be great to have it running on Whonix. We have had great discussions and contributed to both projects in order to provide this feature. Along with the development, some changes to txtorcon were appreciated and we have also been working with meejah on that. # Commitment I have concluded all classes for my degree and I am currently an industrial IT intern at an Engineering and Software company, which is the only commitment I will have besides GSoC throught the duration of the program. I intend to work on unMessage 5~6 hours on weekdays and the remainder of the workload on weekends. # Post GSoC The tasks we picked to work on GSoC are a subset of all the ones we have been discussing during unMessage's development, which means that there will be more work to be done after GSoC. Also, unMessage is quite a big project. There are lots of possibilities to explore in the instant messaging field as well as many challenges to overcome when offering an application with usability and features as good as the popular ones, while protecting users' privacy and anonymity. I intend to keep working on unMessage until we have an application that accomplishes our goals as well as maintain it to fix bugs and add features demanded by the community. Also, as I have been working with anonymous communication for a while, I do not see myself going somewhere else soon, so the chances of keeping contributing the Tor community are high. # Communication I intend to use IRC to discuss with my mentor and other tor devs (who wish to contribute to the project) about ideas and actions to be taken. To formalize what is discussed on IRC, I will use unMessage's tracker on GitHub to manage features/enhancements/issues to keep records and maintain an organized environment for the development of the project, as well as interact with contributors. I am suggesting this tracker as we have already been using it for a while, but I can migrate to Tor's Trac if needed. To summarize everything, I will do what seems to have worked well for previous students: regular reports on the mailing list to keep people updated with what is happening on the project from a higher level. ## Contact info OFTC: dau Email: dau(a)riseup.net PGP: 0xC5A49047572A0D47 # Other GSoC projects in mind? I am only applying to this one. # Anything else? I encourage you to take a look at the git logs and issue trackers from [unMessage], [nymphemeral] and [pyaxo]. I think I am a very organized developer and I have been trying my best to follow the gitflow model and take advantage of the features offered by GitHub. [attrs]: https://attrs.readthedocs.io [automat]: https://github.com/glyph/automat [cli]: https://unmessage.readthedocs.io/en/latest/cli/cli.html [cryptully]: https://github.com/shanet/Cryptully [curses]: https://docs.python.org/2/library/curses.html [david andersen]: https://github.com/rxcomm [dawuud]: https://github.com/david415 [documentation]: https://unmessage.readthedocs.io [double ratchet algorithm]: https://whispersystems.org/docs/specifications/doubleratchet [github profile]: https://github.com/felipedau [gui]: https://unmessage.readthedocs.io/en/latest/gui/gui.html [hulahoop]: https://github.com/HulaHoopWhonix [hypothesis]: https://hypothesis.readthedocs.io [issue 12]: https://github.com/AnemoneLabs/unmessage/issues/12 [issue 21]: https://github.com/AnemoneLabs/unmessage/issues/21 [issue 26]: https://github.com/AnemoneLabs/unmessage/issues/26 [issue 30]: https://github.com/AnemoneLabs/unmessage/issues/30 [issue 32]: https://github.com/AnemoneLabs/unmessage/issues/32 [issue 33]: https://github.com/AnemoneLabs/unmessage/issues/33 [issue 34]: https://github.com/AnemoneLabs/unmessage/issues/34 [issue 35]: https://github.com/AnemoneLabs/unmessage/issues/35 [meejah]: https://github.com/meejah [nymphemeral]: https://github.com/felipedau/nymphemeral [nymserv]: https://github.com/rxcomm/nymserv [omemo]: https://conversations.im/omemo [opus codec]: https://opus-codec.org [patrick schleizer]: https://github.com/adrelanos [protocol]: https://unmessage.readthedocs.io/en/latest/protocol.html [pyaxo]: https://github.com/rxcomm/pyaxo [pynacl]: https://github.com/pyca/pynacl [pytest]: http://docs.pytest.org [ricochet]: https://ricochet.im [signal]: https://whispersystems.org [socialist millionaire protocol]: https://en.wikipedia.org/wiki/Socialist_millionaire [tahoe-lafs]: https://github.com/tahoe-lafs/tahoe-lafs [tkinter]: https://docs.python.org/2/library/tkinter.html [tor onion services]: https://www.torproject.org/docs/hidden-services.html [tor-dev]: https://lists.torproject.org/pipermail/tor-dev [tracker]: https://github.com/AnemoneLabs/unmessage/issues [twisted]: https://twistedmatrix.com [txtorcon]: https://github.com/meejah/txtorcon [unmessage]: https://github.com/AnemoneLabs/unmessage [whonix]: https://whonix.org [wire]: https://wire.com

1 0

GSoC 2017 - Project "Onionoo"
by Nur-Magomed 03 Apr '17

03 Apr '17

Hi! I’m Nur-Magomed Dzhamiev, 4th year student from institute of information technology (speciality: computer security) of North-Caucasus Federal University. I have experience with Java, SQL, Web (HTML, CSS, JavaScript, PHP) and also I designed protocol based on JSON for Android app. I would love to contribute to the project "Onionoo". Please provide me some guide lines and additional materials for study and get a clear understanding about the mentioned project. Thank you! Regards Nur-Magomed

6 17

GSoC: Questions on allowing for more DNS request types
by Lucille Newman 03 Apr '17

03 Apr '17

Hello, I was interested in the project for allowing any kind of DNS support in Tor for GSoC, or, since it is late for that deadline, then also otherwise. After reading proposal 219, I have some questions. 1. A comment by NM suggests that we should specify exact behavior when generating DNS packets (line 56). Should the DNS packets not be generated as according to RFC 1035? Are there other things that need to be taken into consideration here? 2. Another comment (line 63) asks whether 496 bytes is enough for the DNS packet of a DNS_BEGIN cell. Since QNAME can be arbitrarily long, I suppose it is possible that 496 is not enough? If this seems like a reasonable concern, then maybe we could do a similar thing to the DNS_RESPONSE cells with allowing multiple cells for a single question and having a flag to indicate the last cell? 3. What would cause a DNS_BEGIN request or response to be aborted (line 105)? 4. How do we differentiate special names like .onion, .exit, .noconnect (line 145)? 5. The comments at (lines 135-143) indicate that it might not be necessary or practical to refuse requests that resolve to local addresses. This means that such queries will not be sent, but an error will be returned before sending to a DNS server? Thanks so much. Best, Lucy

2 1

Tor in a safer language: Network team update from Amsterdam
by Sebastian Hahn 03 Apr '17

03 Apr '17

Hi there tor-dev, as an update to those who didn't have the chance to meet with us in Amsterdam or those who haven't followed the efforts to rely on C less, here's what happened at the "let's not fight about Go versus Rust, but talk about how to migrate Tor to a safer language" session and what happened after. Notes from session: We didn't fight about Rust or Go or modern C++. Instead, we focused on identifying goals for migrating Tor to a memory-safe language, and how to get there. With that frame of reference, Rust emerged as a extremely strong candidate for the incremental improvement style that we considered necessary. We were strongly advised to not use cgo, by people who have used it extensively. As there are clearly a lot of unknowns with this endeavor, and a lot that we will learn/come up against along the way, we feel that Rust is a compelling option to start with, with the caveat that we will first experiment, learn from the experience, and then build on what we learn. You can also check out the session notes on the wiki (submitted, but not posted yet).[1] The real fun part started after the session. We got together to actually make a plan for an experiment and to give Rust a serious chance. We quickly got a few trivial things working like statically linking Rust into Tor, integrating with the build system to call out to cargo for the Rust build, and using Tor's allocator from Rust. We're planning to write up a blog post summarizing our experiences so far while hopefully poking the Rust developers to prioritize the missing features so we can stop using nightly Rust soon (~months, instead of years). We want to have a patch merged into tor soon so you can all play with your dev setup to help identify any challenges. We want to stress that this is an optional experiment for now, we would love feedback but nobody is paid to work on this and nobody is expected to spend more time than they have sitting around. We have committed to reviewing any patch that includes any Rust code to provide feedback, get experience to develop a style, and actually make use of this experiment. This means we're not ready to take on big patches that add lots of tricky stuff quite now, we want to take it slow and learn from this. We would like to do a session at the next dev meeting to give updates on this effort, but in the meantime, if team members would like to start learning Rust and helping us identify/implement small and well-isolated areas to begin migration, or new pieces of functionality that we can build immediately in Rust, that would be really great. So, for a TLDR: What has already been done: - Rust in Tor build - Putting together environment setup instructions and a (very small) initial draft for coding standards - Initial work to identify good candidates for migration (not tightly interdependent) What we think are next steps: - Define conventions for the API boundary between Rust and C - Add a non-trivial Rust API and deploy with a flag to optionally use (to test support with a safe fallback) - Learn from similar projects - Add automated tooling for Rust, such as linting and testing Cheers Alex, Chelsea, Sebastian [1]: Will be visible here https://trac.torproject.org/projects/tor/wiki/org/meetings/2017Amsterdam/No…

4 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev