Re: [tor-dev] reproducible builds for Android tor daemon
On Thu, 12 Sep 2019, Hans-Christoph Steiner wrote: > > And third, and tips on getting a Linux shared library to build > reproducibly. E.g. is faketime a hard requirement? Usually it's not needed to use faketime. It's only useful if the toolchain has bugs that cannot easily be fixed, causing some timestamps to be inserted somewhere. signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] TBB Memory Allocator choice fingerprint implications
On Wed, 21 Aug 2019, Daniel Micay wrote: > > No, you're just making false attacks and misleading comparisons / spin > to promote your own work, which is trash. You're being incredibly > dishonest and unethical. You didn't even bother to inform yourself about It's fine to disagree with Tom about what he wrote in his previous email, however calling him dishonest and unethical seems very wrong to me. If anything he wrote was not correct or misleading, I doubt it was intentional, and more likely it was some honest mistakes. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] obfs4, meek, active probing and the timeline of pluggable transports
On Mon, 29 Oct 2018, Michael Rogers wrote: > > If anyone on the list knows whether/when we're likely to see a pluggable > transport based on encrypted SNI I'd love to hear about it. There was a thread on this topic recently: https://lists.torproject.org/pipermail/tor-dev/2018-September/013453.html So it seems the first step is having major adoption by browsers and websites, before using it for anti-censorship. Otherwise censors could just block all encrypted SNI requests. signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor Browser downloads and updates graphs
Hi, On Mon, 12 Sep 2016, Rob van der Hoeven wrote: > Hi Georg, > > I think the behavior you see can be explained by an overloaded download > server. From the initial downloads graph you can see that there are on > average 80.000 downloads a day. From the update pings and update > requests graphs you can estimate that there are about 800.000 active Tor > browser users. So, when there is a new version of Tor browser the number We can estimate about 800.000 active daily users if we assume that they are all running their browser at different times during the day to make two pings a day. But some of them probably run it only during some part of the day that is less than 12 hours, which is not enough to make two pings per day. So I think from the update pings, we can only estimate that we have more than 800.000 active daily users, and less than 1.600.000. To get a more precise estimate of active users, we could maybe count the total of update downloads for each version (in an other graph). Although this would be different from the update pings, as it would also include the occasional users who don't use it everyday. > of update requests massively overloads the download server. The > saw-tooth form of the update requests graph is what you expect in this > situation. First you get an update request from all users, the next day > you get a request from all users minus the users who were updated the > previous day (max 80.) and so on. > > I wonder if it is possible that failed downloads are counted too? That > would explain the spikes. But systems that are so heavily overloaded can > generate all kinds of weird results. I think it is possible that failed downloads are counted too. What we are counting is the number of http 302 responses (redirect) to initiate a download. If the redirect works but the actual download fails, it is still counted. Nicolas signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [GSOC16] Fingerprint Central - Status report n°2
On Fri, 24 Jun 2016, Pierre Laperdrix wrote:
>
>
> On 06/23/2016 05:19 PM, Nicolas Vigier wrote:
> > On Fri, 17 Jun 2016, Pierre Laperdrix wrote:
> >
> >> Hi everyone,
> >>
> >> Here is my second status report for my GSOC project.
> >> A little reminder that the repo is located on GitHub:
> >> https://github.com/plaperdr/fp-central
> >
> > I have looked at this quickly, and the system to define the attribute
> > tests seems nice. Is there an option at the end of the tests to download
> > a file containing all the attributes collected?
> >
>
> I don't know if this is what you are looking for but I've just added a
> way to download a JSON file containing all the information in the
> fingerprint. Here is the commit:
> https://github.com/plaperdr/fp-central/commit/6f09ea5b88cf850f7be14af950e928327f0ded6c
Thanks!
> >> 1 - I have progressed faster than I expected in the last two weeks. Here
> >> is everything that I have done:
> >> - Storage of fingerprints in a MongoDB database
> >> - Adding a small API to get statistics on stored variables
> >> - Adding support of hashed variables for faster stats computation
> >> - Adding collection of new attributes and support of HTTP headers
> >> - Adding support of translation with the start of a French version
> >>
> >> 2 - I also started development of a page to tell if a user has an
> >> "acceptable" fingerprint or not (I haven't pushed the code to GitHub
> >> yet). So far, I'm verifying that the screen resolution is in the correct
> >> bounds (i.e. not fullscreen) and that there are no plugins in the
> >> browser. If anyone has any idea that I could implement to help users
> >> have a less recognizable fingerprint, I'll be happy to add it. I have
> >> also added steps to follow to help people better configure their browser.
> >
> > This "acceptable" fingerprint page is a good idea. However, unless I
> > misunderstood your latest commit, it seems to be done as a separate
> > thing from the attributes tests. Is there a reason for not using the
> > collected attributes to check if the fingerprint is acceptable, rather
> > than reimplementing the same tests separately?
>
> Right now, it is done as a separate thing because I'm only focusing on
> two key attributes for the moment. It could be integrated in the main
> collection page but I like the fact that it is separated. Also, I don't
> want to deceive the user because lots of automatic things are running
> and he or she doesn't have the control on it. That's why I put three
> buttons on the main FP page to trigger different actions because I want
> the user to understand and control what is happening. And so, one
> additional reason behind the separate page is to avoid a mega page with
> everything on it. Each page has its own purpose (and also for
> maintainability, it is a plus).
> I don't know if that makes sense but I can change how it is done if the
> approach is not good.
Ah, then it looks like the goal of this page is something different than
what I was thinking. The feature I was thinking was telling if a browser
looks exactly the same as the current version of Tor Browser, based on
all the attributes that we can collect. But your page is something else
that you do before running the fingerprint tests?
>
> >
> > I think one way to do it would be to have a directory with a list
> > of .json files containing attributes and their values, one file for each
> > supported version/slider-setting/platform. And if the browser is
> > matching one of the .json files, then it is considered good. The .json
> > files would not include attributes such as screen.width or screen.heigh,
> > but it could include other attributes indicating if they are rounded.
> >
After thinking again about this, rather than having a set of .json
files, with one for each supported version/slider-setting/platform
containing a lot of duplicate information (most attributes will be the
same in all the cases), an other way to do it would be to list in the
fingerprint/attributes/*.json files the expected values in the different
cases.
Adding something like this to the .json files:
"expected_values" : {
"variable_1" :
[
{
"security_slider": 4,
"value" : "X"
},
{
"security_slider": 3,
"value" : "Y"
},
{
"value" : "Z"
}
]
}
> I haven't thought about it that way but that could be a very good
&g
Re: [tor-dev] [GSOC16] Fingerprint Central - Status report n°2
On Fri, 17 Jun 2016, Pierre Laperdrix wrote: > Hi everyone, > > Here is my second status report for my GSOC project. > A little reminder that the repo is located on GitHub: > https://github.com/plaperdr/fp-central I have looked at this quickly, and the system to define the attribute tests seems nice. Is there an option at the end of the tests to download a file containing all the attributes collected? > > 1 - I have progressed faster than I expected in the last two weeks. Here > is everything that I have done: > - Storage of fingerprints in a MongoDB database > - Adding a small API to get statistics on stored variables > - Adding support of hashed variables for faster stats computation > - Adding collection of new attributes and support of HTTP headers > - Adding support of translation with the start of a French version > > 2 - I also started development of a page to tell if a user has an > "acceptable" fingerprint or not (I haven't pushed the code to GitHub > yet). So far, I'm verifying that the screen resolution is in the correct > bounds (i.e. not fullscreen) and that there are no plugins in the > browser. If anyone has any idea that I could implement to help users > have a less recognizable fingerprint, I'll be happy to add it. I have > also added steps to follow to help people better configure their browser. This "acceptable" fingerprint page is a good idea. However, unless I misunderstood your latest commit, it seems to be done as a separate thing from the attributes tests. Is there a reason for not using the collected attributes to check if the fingerprint is acceptable, rather than reimplementing the same tests separately? I think one way to do it would be to have a directory with a list of .json files containing attributes and their values, one file for each supported version/slider-setting/platform. And if the browser is matching one of the .json files, then it is considered good. The .json files would not include attributes such as screen.width or screen.heigh, but it could include other attributes indicating if they are rounded. signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] (no subject)
On Sat, 05 Mar 2016, Alex Mourtziapis wrote: > HI, > > My name is Alex and I am looking forward in collaborating with you. Hi! > > I am particularly interested in working for Tor messenger but sadly things > seemed > a little unclear to me and the existing code here [1] didnt help me at all. > If I got it right you want the messenger to be written in Node.js and use > a lib like nw.js or electron to package and distribute it. Am I looking at > the wrong direction? There is no plan to rewrite it in Node.js. Tor Messenger is based on Instantbird (which is based on Mozilla Gecko) on which we add some patches and extensions for OTR and Tor. > [1] https://gitweb.torproject.org/tor-messenger-build.git This repository contains the scripts to download all components, patch them and build everything in a reproducible way. signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [tor-commits] [tor-messenger-build/master] Bug 17492: Include default bridges configuration
On Fri, 06 Nov 2015, David Fifield wrote: > > You can also just run meek-client without the Firefox helper. It has a > standalone mode. Just change the torrc line > > ClientTransportPlugin meek exec > ./TorBrowser/Tor/PluggableTransports/meek-client-torbrowser -- > ./TorBrowser/Tor/PluggableTransports/meek-client > > to > > ClientTransportPlugin meek exec > ./TorBrowser/Tor/PluggableTransports/meek-client It works fine with this change. Thanks! Nicolas pgpN8piG3kpwX.pgp Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] tor-browser git repository
On Fri, 04 Sep 2015, tordev...@safe-mail.net wrote:
> Is there some documentation, how the tor-browser git repository is set up?
>
> In particular, how are new Firefox releases imported? How can I get a diff of
> Tor changes to the underlying Firefox release?
The branches are named like:
tor-browser-${firefox_version}-${torbrowser_version}-[1-9]
They are based on Mozilla's git mirror:
https://github.com/mozilla/gecko-dev
In the history of the branch you can find a commit whose author is
"ffxbld " which is the last commit from Mozilla. All
commits after this one are Tor Browser changes.
pgpaXcPpwhMrW.pgp
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor Messenger Third Alpha
On Wed, 01 Jul 2015, Fabian Keil wrote: > Nicolas Vigier wrote: > > > On Wed, 01 Jul 2015, Fabian Keil wrote: > > > > > Sukhbir Singh wrote: > > > > > > > * Feedback > > > > > > > > This is an early release and there may be serious privacy leaks and > > > > other issues -- please DO NOT recommend Tor Messenger to end users; > > > > this release is only for developers and advanced users who would > > > > like to help us with testing but understand the risks involved with > > > > using alpha software. > > > > > > Providing source tarballs would probably increase the number > > > of test reports from platforms that aren't supported by the > > > pbm. > > > > All the scripts and sources used to build Tor Messenger are available in > > this git repository: > > https://gitweb.torproject.org/tor-messenger-build.git/ > > I got that, but a casual tester with a limited amount of time > may not want to spent an unknown amount of it trying to get > the required sources out of a non-standard build system. Building for an unsupported platform will very likely require an important amount of time in any case, so not recommended if you only have a limited amount of time. pgpW08ZvqNVoH.pgp Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor Messenger Third Alpha
On Wed, 01 Jul 2015, Fabian Keil wrote: > Sukhbir Singh wrote: > > > * Feedback > > > > This is an early release and there may be serious privacy leaks and > > other issues -- please DO NOT recommend Tor Messenger to end users; this > > release is only for developers and advanced users who would like to help > > us with testing but understand the risks involved with using alpha > > software. > > Providing source tarballs would probably increase the number > of test reports from platforms that aren't supported by the > pbm. All the scripts and sources used to build Tor Messenger are available in this git repository: https://gitweb.torproject.org/tor-messenger-build.git/ However, as we are cross-compiling everything from Linux, building for a new platform is not always straightforward. Which platform are you interested in ? pgpwmvDVlAwQ1.pgp Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Different Key Fingerprints for Tor Browser?
On Thu, 05 Mar 2015, Florian Rüchel wrote: > Hey, > > just downloaded Tor Browser and noticed that most of the fingerprints on > the page " 0x4E2C6E8793298290". However, under "Mac OS X and Linux" it > reads " Erinn Clark signs the Tor Browsers. Import her key > (0x416F061063FEE659) ". Shouldn't this be updated to the other > fingerprint as well oder am I missing something? Updated: https://gitweb.torproject.org/project/web/webwml.git/commit/?id=5d6192e86d8ed588acf51fae455a0a4955369347 Thanks for noticing. Nicolas pgpE5l_DK0jBn.pgp Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Stormy - request for feedback
On Mon, 17 Nov 2014, Griffin Boyce wrote: > Hello all, > > So as some of you know, I've been working on installers for hidden > services, to ideally make very common services (such as blogs and plain > websites) easy to deploy and automatically update. This is a very rough > version of the one-click hidden service installer, but I'd love to get > feedback on places where it breaks and where it could use a major structural > change. Here is an idea for a major structural change. That's probably too much changes if you're planning to have a first version soon, but maybe for a future 2.0 version if this change looks like a good idea. After looking at the scripts, it looks quite similar to configuration that is usually done with tools such as ansible, puppet, saltstack, etc ... So I am thinking that an other way to do it could be to write a few ansible modules (or modules for your favorite configuration management tool) for the various tasks currently done by the script (installing nginx, installing a blog software, setup a hidden service, configure the firewall, etc ...), or take existing modules if they do what is needed. Then write a GUI program that will ask some questions, and when you click on the "setup" button generate an ansible variables file containing the answers to those questions (variables which are used by the ansible modules), and run ansible to apply the changes on the system. Normal users would only use the GUI and click "setup", but expert users would be able to take the modules and include them in their own ansible setup without the GUI. pgpWb4vd1ElPC.pgp Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Mbox sandbox
On Fri, 16 May 2014, isis wrote: > Nicolas Vigier transcribed 2.6K bytes: > > > > - Looked at Mbox[2]: a sandboxing tool based on ptrace and seccomp/BPF. > > This can be used in the test suite to get the list of files modified > > by the browser after running a test, to check that it did not create > > or modify files in unexpected places. This can also be used to log > > all network connections, to check that everything goes through tor. > > I was previously thinking about doing that using Docker, but now it > > seems more simple with Mbox. > > Mbox is neat! It looks like it's git based, right? Or at least includes some > sort of CVS system. Either way, great idea, testing for connections not > matching " -> 127.0.0.1" should be easy. :) > > > [2]: http://pdos.csail.mit.edu/mbox/ Yes, it's nice! It's not git or CVS based. But it stores all new and modified files in a separate directory, doing copy-on-write when opening files with write permissions, by hijacking arguments of system calls which access files. And after running the program, asks you which copy of the files you want to keep (or you can manually copy the files from the sandbox directory). It can also be used to log in a file all network connections opened. Initially the filesystem sandoxing part didn't work with Tor Browser because of some bugs in Mbox, but it's now fixed so we'll be able to use it in the TBB test suite to monitor the files modified, created and removed by Tor Browser, and network connections made. Yesterday I also made a patch that allows filtering which connections can be made: https://github.com/tsgates/mbox/commit/6dd0e49202795564e627e9eeba664fc685b14bb7 It could be used for instance to make sure a program will not connect anywhere without using tor. This can be done like this: $ cat tor.profile [fs] direct: / [network] block: 0.0.0.0 allow: 127.0.0.1:9050 $ mbox -p ./tor.profile -- curl -I http://www.google.com/ curl: (6) Could not resolve host: www.google.com $ mbox -p ./tor.profile -- curl --socks5-hostname 127.0.0.1:9050 -I http://www.google.com/ HTTP/1.1 302 Found Cache-Control: private Content-Type: text/html; charset=UTF-8 Location: http://www.google.co.in/?gfe_rd=cr&ei=GoiDU-76DcSU-wbdy4HgDg Content-Length: 261 Date: Mon, 26 May 2014 18:29:46 GMT Server: GFE/2.0 Alternate-Protocol: 80:quic $ mbox -o /dev/null -p ./tor.profile -- nmap localhost Starting Nmap 6.45 ( http://nmap.org ) at 2014-05-26 20:32 CEST Nmap scan report for localhost (127.0.0.1) Host is up (0.0022s latency). Not shown: 999 closed ports PORT STATE SERVICE 9050/tcp open tor-socks Nmap done: 1 IP address (1 host up) scanned in 0.18 seconds $ nmap localhost Starting Nmap 6.45 ( http://nmap.org ) at 2014-05-26 20:32 CEST Nmap scan report for localhost (127.0.0.1) Host is up (0.00048s latency). Not shown: 996 closed ports PORT STATE SERVICE 25/tcp open smtp 111/tcp open rpcbind 631/tcp open ipp 9050/tcp open tor-socks Nmap done: 1 IP address (1 host up) scanned in 0.07 seconds It's also possible to kill a process which does unallowed connections, rather than just blocking those connections: $ cat tor.profile [fs] direct: / [network] kill: 0.0.0.0 allow: 127.0.0.1:9050 $ mbox -o /dev/null -p ./tor.profile -- nmap localhost Starting Nmap 6.45 ( http://nmap.org ) at 2014-05-26 20:37 CEST Stop executing pid=5298: Connect to 127.0.0.1 port 80 However, a warning if some people want to use this: it's still alpha quality software, so probably not a good idea to use it for something where security is important without more review. pgp_OylAkBXgC.pgp Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Panopticlick summer project
On Fri, 25 Apr 2014, Gunes Acar wrote: > > > > > And this looks like a very good start! If you think that's ready, I can > > merge your patch (fp_tests.patch) so we start running those tests on > > the next releases / nightly builds. > Hi Nicholas, > I think it won't hurt to merge and I'd be just glad. Great! Before merging your patch, a question about the license of your test scripts: is there a specific license you want to use ? The testsuite is currently under CC0. If you want your tests to be under a different license, they should mention the license in the headers. Nicolas pgpxtiql6JZwC.pgp Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Panopticlick summer project
On Mon, 21 Apr 2014, Gunes Acar wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > On Mon 21 Apr 2014 02:21:35 PM CEST, Mike Perry wrote: > > Gunes Acar: Sorry everyone for the long pause. > > > > I wrote down a proposal (and some code) to address issues raised > > by Mike and George: > > https://securehomes.esat.kuleuven.be/~gacar/summer_2014.pdf > > > > Looking for your comments and critics... > > > >> This proposal looks like quite a good start. With respect to > >> automated testing, you should definitely discuss this with > >> Nicolas Vigier, who is our lead automation engineer. He has begun > >> writing TBB automation tests, and can help you integrate your > >> tests into that framework. You can see a few links to the > >> existing testing infrastructure at in the QA and testing section > >> of the TBB hacking doc: > >> https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking#QAandTesting > > Sure, > >> > I already have some questions noted down for him. > But I must say the framework he set up is pretty easy to extend. > I could add and run my tests in minutes. Hello, I have been looking at your git repository with selenium tests: https://github.com/gunesacar/tbb-fp-tests And this looks like a very good start! If you think that's ready, I can merge your patch (fp_tests.patch) so we start running those tests on the next releases / nightly builds. After reading your proposal about this new Panopticlick project, something I'm wondering is if it would be possible to split this tool in two differents parts: - the part that generate a profile of the browser visiting the page(s) using all known fingerprinting techniques, and save this profile in a file (in json, yaml or any other format that is easy to read from an other program) - the part that takes this profile and adds it to a central database, and compute a uniqueness score to display it to the user The reason I'm thinking about this is that it could allow us to share the first part between the panopticlick website and the test suite. I've been thinking about making the test suite start a local web server that would be used to host some pages to be used by tests, and this fingerprinting website could be one of thoses. Does it sounds like something possible ? Nicolas pgp1Y3HBdYJmN.pgp Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Panopticlick summer project
(sending this again as I accidentally removed Peter from CC) On Mon, 21 Apr 2014, Gunes Acar wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > On Mon 21 Apr 2014 02:21:35 PM CEST, Mike Perry wrote: > > Gunes Acar: Sorry everyone for the long pause. > > > > I wrote down a proposal (and some code) to address issues raised > > by Mike and George: > > https://securehomes.esat.kuleuven.be/~gacar/summer_2014.pdf > > > > Looking for your comments and critics... > > > >> This proposal looks like quite a good start. With respect to > >> automated testing, you should definitely discuss this with > >> Nicolas Vigier, who is our lead automation engineer. He has begun > >> writing TBB automation tests, and can help you integrate your > >> tests into that framework. You can see a few links to the > >> existing testing infrastructure at in the QA and testing section > >> of the TBB hacking doc: > >> https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking#QAandTesting > > Sure, > >> > I already have some questions noted down for him. > But I must say the framework he set up is pretty easy to extend. > I could add and run my tests in minutes. Hello, I have been looking at your git repository with selenium tests: https://github.com/gunesacar/tbb-fp-tests And this looks like a very good start! If you think that's ready, I can merge your patch (fp_tests.patch) so we start running those tests on the next releases / nightly builds. After reading your proposal about this new Panopticlick project, something I'm wondering is if it would be possible to split this tool in two differents parts: - the part that generate a profile of the browser visiting the page(s) using all known fingerprinting techniques, and save this profile in a file (in json, yaml or any other format that is easy to read from an other program) - the part that takes this profile and adds it to a central database, and compute a uniqueness score to display it to the user The reason I'm thinking about this is that it could allow us to share the first part between the panopticlick website and the test suite. I've been thinking about making the test suite start a local web server that would be used to host some pages to be used by tests, and this fingerprinting website could be one of thoses. Does it sounds like something possible ? Nicolas pgpAYC4_jk46a.pgp Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] gitian replacement proposal
On Fri, 10 Jan 2014, Nicolas Vigier wrote: > Hello, > > You can find at this URL a proposal to refactor the tor browser bundle > build process, using an other tool to replace gitian: > https://people.torproject.org/~boklm/automation/tor-automation-proposals.html#build-tool > (also added as attached file to this email) > > I made a prototype to show how it would work: > https://github.com/boklm/burps-tor By the way, the name of the tool 'burps' is not that great, so I'm thinking about renaming it to 'Reproducible Build Manager', with 'rbm' as the name for the command and configuration file. There does not seem to be any command with that name yet. pgpPS6ByNs0TF.pgp Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] gitian replacement proposal
Hi,
On Mon, 13 Jan 2014, Georg Koppen wrote:
> Hi,
>
> Nicolas Vigier:
> > Hello,
> >
> > You can find at this URL a proposal to refactor the tor browser bundle
> > build process, using an other tool to replace gitian:
> > https://people.torproject.org/~boklm/automation/tor-automation-proposals.html#build-tool
> > (also added as attached file to this email)
>
> it seems to be much more than a proposal for refactoring the TBB build
> process as building packages of components is not relevant in the
> latter. So, I won't comment on the details but like to get consensus on
> the big picture first. Taking the main improvements you listed below as
> a starting point seems therefore fine to me:
>
> > The main improvements in this prototype from the current build process
> > are:
> >
> > - all components are built separately, and include in their output file
> > name the commit hash or version, architecture and OS (if architecture
> > dependant). This allows us to keep previous builds if the
> > commit/version/architecture/OS didn't change. So we can rebuild a
> > bundle very quickly when the browser didn't change.
>
> Yes, we start with #10120 (which I'd like to start working on in the
> next weeks). But avoiding to rebuild other parts of the bundle
> (torbutton etc.) should be easily doable as well (but keep the
> starting/updating/stopping-the-VM-overhead in mind).
>
> > - the gitian replacment has features to download tarballs and verify them
> > with sha256sum or gpg signature, so this can replace the fetch-inputs.sh
> > script.
>
> Yes, but we already have fetch-inputs.sh. So the advantage of burps
> seems not to be so big here.
The advantage is that it's more simple, and better integrated with the
rest of the tool.
For instance, the python sources tarball is currently defined in the
following files:
- versions: version and download URL
- fetch-inputs.sh: gpg signature verification, and creation of a
symlink Python-$VERSION.tar.bz2 -> python.tar.bz2
- descriptors/linux/gitian-firefox.yml: python.tar.bz2 is defined in
the list of files to be copied inside the build VM
In burps the equivalent can be defined in one place, in the file
projects/python/config, with the following lines:
version: 2.7.5
input_files:
- name: python
filename: 'Python-[% c("version") %].tar.bz2'
URL: 'http://www.python.org/ftp/python/[% c("version") %]/[%
c("filename") %]'
file_gpg_id: 1
sig_ext: asc
In this definition we have:
- the name of the file that should be copied to the build VM (filename)
- the URL to download the file if it is missing (URL)
- the 'file_gpg_id' option to indicate that a gpg signature file should
be downloaded too, and used to verify the file (using keyring python.gpg)
- no symlink needed. I think it is needed in the gitian build process
because there is no easy way to access the python version defined in
the versions file from the gitian descriptor, so a symlink is created
to avoid updating the filename in the gitian descriptor each time
the version changes. In burps we can access this filename, so we don't
need a symlink.
So I think this is more simple. An other advantage is that the files
are going to be downloaded only if they are needed: if we make python
build optional, and we run a build that doesn't need it, it won't be
downloaded.
>
> > - we can remove the linux/windows/macosx descriptors duplication, and
> > instead use template directives for the parts that differ between
> > those builds (it's still possible to use separate files if they differ
> > completly).
>
> Yes, that is good. Although I am not sure how much this buys us in a
> full-fledged gitian-like setup. And I guess the gitian people would be
> happy to take patches. :)
The prototype I have made does not support Windows and Mac OS X builds
yet, but I have looked at how it can be implemented.
Instead of having 3 separate descriptor files:
gitian/descriptors/linux/gitian-tor.yml
gitian/descriptors/windows/gitian-tor.yml
gitian/descriptors/mac/gitian-tor.yml
We have only one, but we make changes like this for the parts that
need to differ between Linux / Windows / Mac OS X builds:
diff --git a/burps.conf b/burps.conf
index 60d2868be16f..8941b0c7ed94 100644
--- a/burps.conf
+++ b/burps.conf
@@ -36,3 +36,9 @@ targets:
include_pt:
var:
include_pt: 1
+ win32:
+var:
+ crosscompile_host: i686-w64-mingw32
+ osx32:
+var:
+ crosscompile_host: i686-apple-darwin11
diff --git a/projects/tor/build b/projects/tor/build
index b8cd9f805922..42ac7cf9c67b 100644
--- a/projec
[tor-dev] gitian replacement proposal
Hello, You can find at this URL a proposal to refactor the tor browser bundle build process, using an other tool to replace gitian: https://people.torproject.org/~boklm/automation/tor-automation-proposals.html#build-tool (also added as attached file to this email) I made a prototype to show how it would work: https://github.com/boklm/burps-tor The main improvements in this prototype from the current build process are: - all components are built separately, and include in their output file name the commit hash or version, architecture and OS (if architecture dependant). This allows us to keep previous builds if the commit/version/architecture/OS didn't change. So we can rebuild a bundle very quickly when the browser didn't change. - the gitian replacment has features to download tarballs and verify them with sha256sum or gpg signature, so this can replace the fetch-inputs.sh script. - we can remove the linux/windows/macosx descriptors duplication, and instead use template directives for the parts that differ between those builds (it's still possible to use separate files if they differ completly). - we can define variables based on selected OS. This allows for instance to build python 2.7 when building on Ubuntu Lucid, but avoid building it on other distros which already provide python 2.7. - we can define variables based on "targets" that are set on command line. For instance in the prototype using "--target enable_pt" instructs to include the portable transports (only pyptlib in this prototype) in the bundle. - we can easily switch from building in a VM to building locally - build descriptors can depend on the result of another build descriptor. This remove needs for scripts like mkbundle-*.sh. And I think those improvements should make it easier to rebuild a new bundle automatically when any of the components of the bundle receives a new commit, and then run tests on this bundle. Nicolas Goals ~ It would be useful to have a tool that can be used for building Tor Bundle Browser, and packages for any of the Tor components. Tor Bundle Browser ^^ In the current build process for the Tor Bundle Browser, gitias is used to : - create and start an Ubuntu VM in KVM or LXC - install build dependencies in the VM - copy the sources files in the VM and start the build The parts that are not done by gitian but by a shellscript based wrapper around gitian: - initial clone of the git repository containing the sources (fetch-inputs.sh) - git tag gpg signature check (verify-tags.sh) - download tarballs from mirrors, and verify gpg signature or sha256sum (fetch-inputs.sh) Improvement that can be done from the current process: - some informations are duplicated in different places, such as git URLs (both in gitian descriptor and in fetch-inputs.sh) - linux, mac and windows gitian descriptors are separate, so part of them are duplicating some informations. It would be better to be able to share the parts that are common on all OSs. - build process is not very modular. It is not possible or simple to build only some components. - the build process can currently only be run from Ubuntu - the current process requires using git tags if gpg signature verification is wanted. It could be useful to be able to use gpg signed commits instead. To solve this, we can have a tool that handle both the tasks currently done by gitian, and the tasks currently done by shellscript wrappers: - store in a single descriptor the build instructions, build dependencies, git URL, tarball URLs, gpg keyring file, sha256sum, etc ... and have all the operations done by the tool. This should remove the need for wrappers. - create a separate descriptor for each software that we build, so that they can be built separately. The tool should be able to manage dependencies between separate builds to create a bundle of different software. - a templating system allows us to have some variables and use them at different places. This allows us to have a common build descriptor for all OSs, and use conditional templating instructions where the process differ between the different OSs. A prototype to show a possible build process is available, with more details below. Packages In addition to building the Tor Browser Bundle, we also need to build some rpm or Debian packages for different components. Some of them are also included in the Tor Browser Bundle. To be able to do continuous packaging, we need a tool that would allow us to produce an rpm or Debian package from a git commit. In the jenkins/tools.git repository, some shell scripts are used to produce Tor Debian packages from the latest commit. To avoid duplicating build instructions, URLs, gpg keyring and other infos, it would be useful if a single tool was able to produce the Tor Browser Bundle and also individual packages for some of the components. Prototype and current status ~
Re: [tor-dev] [tor-reports] boklm's report for December 2013
Hi Karsten, On Tue, 07 Jan 2014, Karsten Loesing wrote: > > Hi Nicolas, > > these two documents look like something you have put a lot of work into > and that you're still working on. Putting them on people.tpo has a few > (major, IMHO) disadvantages: nobody will learn about these documents > unless they know the exact URL, nobody will be notified when they change > (and therefore see that you're working hard on them), there's no > history, and when you delete them (by mistake) they're gone forever. About deleting them by mistake and history, I'm keeping the sources in a git repository: https://github.com/boklm/tor-automation The reason I'm doing this is that it's convenient to be able to edit them with a text editor when offline. But it's true that it makes them harder to find and see that they were updated. I will look if I can maybe push them to wiki pages using XML-RPC. Nicolas ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] bridgdb automation
Hi Matthew and Isis, On Sun, 22 Dec 2013, isis agora lovecruft wrote: > > > > If proper packaging is helpful for Jenkins, however, I can easily do so. > > > > > > An idea could be to have a Debian package for bridgedb, and make Jenkins > > > update the packages in a repository automatically when there are new > > > commits. > > > > > > > For our purpose I think debian packages are a bit overkill, but I have > > nothing against creating them if it will make testing and deployment > > easier. > > > > I am moderately to strongly against using Debian's packaging system for Python > things, because it is perpetually outdated, combined with the Python Software > Foundation's complete disregard for the standard packaging concept of > backporting patches. When something breaks in Python, they fix it in an > upcoming release. If you complain that something is broken which is fixed in a > newer release than the Python version you're using, the Python devs will tell > you to upgrade. > > Debian sid's version is currently 2.7.5-5. Which is outdated. 2.7.6 was > released two weeks ago. Wheezy is even worse; it's nearly two years > outdated. Briefly skimming it, I can point at roughly 30 bugs in the Python > release changelog [0] which BridgeDB will likely hit, if we use the wheezy > version (which we are using). Several of those bugs due to using ancient, > deprecated, OpenSSL API features, and other rather severe SSL bugs, one of > which was a recent CVE. (CVE-2013-4238) [1] > > [0]: http://hg.python.org/cpython/raw-file/99d03261c1ba/Misc/NEWS > [1]: https://security-tracker.debian.org/tracker/CVE-2013-4238 > > What is more important, and what I would *really* prefer not to fight, is the > inevitable slew of horrific glitches and hiccups which will occur from using > Debian's extremely outdated Python modules. Here is a list of Python packages > in Debian, compared to the version in Ubuntu, along with excuses for why the > haven't been updated. [2] Twisted in wheezy is also about two years > outdated. Jessie/sid aren't up-to-date either. This is madness. > > [2]: > http://qa.debian.org/developer.php?login=python-modules-t...@lists.alioth.debian.org > > I don't mean to start a holy war, and I love Debian… but their Python team is > failing. I think the only reason Debian managed to get a somewhat safe version > of Pip (v1.4.1) into jessie and sid is that one of the main organisers in > Debian Security convinced me to file CVEs for vulnerabilities in pip-1.3.1, > even though dstufft had already fixed the issues in 1.4.1. If I understood the > politics correctly, they needed me to file those CVEs so that the security > team could update the packages themselves ― without waiting for the lead of > the Debian Python group to give the okay (the latter being the person who > seems to be causing most of these problems; incidentally, that person works > for Canonical). Ok, I didn't know that, thanks for the details. So let's avoid Debian packages for BridgeDB for now. > > If, somehow, this process involves staging a violent revolutionary upheaval of > the current lead of the Debian Python team, and whichever other jerks are > preventing Debian from having decent Python packaging… count me in! Otherwise > I'd really rather steer clear of them. > > > > We could have the following package repositories : > > > > > > - bridgedb-common-wheezy: backports of dependencies required to run > > >bridgedb on wheezy > > > > > > - bridgedb-master-wheezy: packages produced from master (or > > >development) branch on wheezy > > > > > > - bridgedb-stable-wheezy: packages produced from stable branch on > > >wheezy > > > > > > - bridgedb--wheezy: packages from branch, if needed > > > > > > > We also have a develop branch, right now it only resides in our personal > > repos, though. This will be useful to test in the future. > > > > Develop is probably the branch to test. I don't ever make commits straight > onto master branches in any repo. > > > > When you push a new commit, Jenkins rebuilds the package and moves it to a > > > temporary repository. Then it starts a new container or VM with that > > > repository enabled, install the bridgedb package and run some tests. If > > > the tests succeed, the package is moved to the repository corresponding > > > to the branch. > > Does "repository" here mean "Debian repository"? Or "directory of tarballs and > sha256sums"? I was thinking about a Debian repository when writting this, but this can be done as a directory of tarballs and sha256sums if that's better. Is it something that pip can use ? But maybe that is not very useful as it seems pip can install from a git URL directly. > > > > When you think that what is in the master branch is ready to be used, > > > you merge it to the stable branch, wait for Jenkins to rebuild the > > > packages > > This is done! With the slight modification that my master = your stable, and > my develop = your mas
Re: [tor-dev] [Question to sysadmins and HS operators:] How should Hidden Services scale?
On Fri, 20 Dec 2013, George Kadianakis wrote: > > For this reason we started wondering whether DNS-round-robin-like > scalability is actually worth such trouble. AFAIK most big websites > use DNS round-robin, but is it necessary? What about application-layer > solutions like HAProxy? Do application-layer load balancing solutions > exist for other (stateful) protocols (IRC, XMPP, etc.)? I think HAProxy and DNS round-robin solve different kinds of scalability issues: - the application running behind the hidden service is taking too much ressources for a single node. Something like HAProxy can help split the application on multiple nodes, but all traffic still go through a single node. - the network bandwidth that a single node can have or the number of connections it can handle is not enough. A solution like HAProxy doesn't help, because everything still has to go through a single node. I think the DNS round-robin is used to solve this kind of problem. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] bridgdb automation
On Tue, 17 Dec 2013, isis agora lovecruft wrote: > Nicolas Vigier transcribed 1.4K bytes: > > Hi, > > Hey Nicolas, > > Thanks for all the work you're doing, and my apologies that I hadn't responded > to your tor-dev@ call yet. Hi Isis, thanks for your answer. > > Just in case you haven't seen it, Lunar made a wiki page which has quite a bit > of info on it, and I filled in some more on BridgeDB. [0] Yes, Lunar showed me this page, and we used it when he gave me a summary of what each of the projects do. > > aabgsn maintained BridgeDB for a year or so, but no longer works on it (though > they are more than welcome to do so, if they wish to). sysrqb has been helping > me maintain BridgeDB quite a bit (feel free to CC them on BridgeDB topics). > > > I am currently looking at the status and list of things to be done > > regarding automation on tor project. I have been looking at bridgedb : > > https://people.torproject.org/~boklm/automation/tor-automation-review.html#_bridgedb > > From that page: > > > Continuous Build > > BridgeDB is not currently built and tested by Jenkins. > > > > However, Isis Lovecruft has a personnal development fork on github that is > > built and tested by travis-ci.org: > > https://travis-ci.org/isislovecruft/bridgedb/ > > > > Packaging > > BridgeDB does not have packages. It is currently deployed using a Python > > virtualenv. > > > > To my knowledge, BridgeDB is not currently deployed in a virtualenv (sysrqb > was the last to redeploy it). I recently refactored the main loop and scripts > so that it *can* run in a virtualenv, and it *should* be run in one, because: > > 1. We won't need to nag weasel/Sebastian to update/install BridgeDB > dependencies. > 2. Dependencies will not be installed via sudo. I'm not familiar yet with the process to maintain *.tpo services, and what part is done by sysadmin team, and what part can be done by maintainer of a service, like installing dependencies or other operations that require root access. Do you (or someone else reading this) have more details about this ? > > I've been considering creating packages for BridgeDB on PyPI. > > Pros: > * Even if we manually download the bundle, verify the hash, and then > install it, this seems potentially easier and less error-prone than > checking out a git tag, verifying it, and then building. > * Packaging it now reserves the 'bridgedb' Python namespace for our use. > > Cons: > * I don't want to make people think that this thing is a polished > distribution system for people who wish to run their own BridgeAuths. > > If proper packaging is helpful for Jenkins, however, I can easily do so. An idea could be to have a Debian package for bridgedb, and make Jenkins update the packages in a repository automatically when there are new commits. We could have the following package repositories : - bridgedb-common-wheezy: backports of dependencies required to run bridgedb on wheezy - bridgedb-master-wheezy: packages produced from master (or development) branch on wheezy - bridgedb-stable-wheezy: packages produced from stable branch on wheezy - bridgedb--wheezy: packages from branch, if needed When you push a new commit, Jenkins rebuilds the package and moves it to a temporary repository. Then it starts a new container or VM with that repository enabled, install the bridgedb package and run some tests. If the tests succeed, the package is moved to the repository corresponding to the branch. When you think that what is in the master branch is ready to be used, you merge it to the stable branch, wait for Jenkins to rebuild the packages then run apt-get upgrade on the server where bridgedb is running. You can also setup a second server that is used as a staging environment, with the master branch packages repository. It might be possible to do something similar using pip and virtualenv. However if it can be done using Debian packages, it will be easier as the process to update and test Debian packages can be shared with the other projects that are not in python. > > > Testing > > Some unit tests are implemented in lib/bridgedb/Tests.py and can be run with > > the command python setup.py test. > > Actually, the tests in lib/bridgedb/Tests.py are old tests. Running them with > `python setup.py test` or `make test` will run them via the Python stdlib > unittest module (which doesn't play nicely with Twisted's asynchronicity). See > #9865, #9872. [1] [2] > > There are new tests in lib/bridgedb/test/test_*.py [3] and they can be run > with > `[sudo] make [re]install && bridgedb test`. Ok, so the tests shoul
Re: [tor-dev] Tor project automation work
On Tue, 10 Dec 2013, Nicolas Vigier wrote: > > > In order to help me doing that, I'm very interested to receive from > > > developers of any tor components : > > > > > > - a description or ticket number of bugs that you wish could have been > > > detected earlier with automated tests > > > > https://trac.torproject.org/projects/tor/ticket/8143 comes to mind here. > > Ok. We should soon be able to push tor browser to Mozilla's Try servers, > which will run all the unit tests, so we should be able to detect bugs > like #8143. Regarding this, we will be testing the version that is in tor-browser.git, when a branch receive new commits. In addition to this, an other thing that we could do automatically is rebasing the tor-browser patches onto the unreleased next mozilla esr from http://hg.mozilla.org/releases/mozilla-esr24/ in the default branch. This allows to see in advance if rebasing the patches on the next ESR release will require some work, and if some new Mozilla patches break the build or some tests. pgpy7URxUEvrC.pgp Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor project automation work
On Fri, 06 Dec 2013, Nicolas Vigier wrote: > - a description or ticket number of bugs that you wish could have been > detected earlier with automated tests Mike and Georg started tagging tickets that are possible test cases with keyword tbb-testcase: https://trac.torproject.org/projects/tor/query?keywords=~tbb-testcase If you know more tickets like this, you can tag them too and I will look at them. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor project automation work
On Tue, 10 Dec 2013, Lunar wrote: > Nicolas Vigier: > > Ok, we can have a test rebuilding several times the files that are most > > likely to become non deterministic. However it would be better if we can > > find some way to trigger those non-deterministic builds with only two > > builds. Maybe we can try something like this : > > > > - a library that we put in LD_PRELOAD as a wrapper on readdir to return > > directory entries in random order instead of inodes number, so it's > > more likely to be different on each build. > > > > - a python library that we put in PYTHONPATH, to override dict.iterkeys > > to return keys in random order. If I understand ticket #10159 > > correctly, it was caused by iterkeys returning keys in the same order > > most of the time, but not all the times. > > I would suggest using reverse order instead of random order. Random > order has the probability of being just like the original order. Indeed, reverse order is better. > For readdir(3), have a look at: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719845#39 This looks like exactly what we need. Thanks ! pgpj4o2YcROsG.pgp Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor project automation work
On Mon, 09 Dec 2013, Georg Koppen wrote: > Hi Nicolas, > > some remarks are below. Hi Georg, Thanks for your remarks. > > Nicolas Vigier: > > In order to help me doing that, I'm very interested to receive from > > developers of any tor components : > > > > - a description or ticket number of bugs that you wish could have been > > detected earlier with automated tests > > https://trac.torproject.org/projects/tor/ticket/8143 comes to mind here. Ok. We should soon be able to push tor browser to Mozilla's Try servers, which will run all the unit tests, so we should be able to detect bugs like #8143. https://wiki.mozilla.org/ReleaseEngineering/TryServer > > > - any wish or specific needs that you may have > > You write: "Tor Browser includes some patches to make the build > reproducible. We could have a test that check the reproducibility of the > build by building the browser twice." > > While this is indeed a good idea, it won't be enough as we had bugs in > the past that were only visible when builds on different machines got > compared. So, what I'd like to have (in addition to running browser > builds twice? on different machines?) are tests that cover specific bugs > we avoided (see: the "Remaining Build Reproducibility Issues" in Mike's > blog post covering the technical details of the Gitian build) or tracked > down. See: https://trac.torproject.org/projects/tor/ticket/10159 for an > example for the latter. (There, one could write a test that automates > the creation of the browser.manifest which would eventually (i.e. if run > a couple of times) show whether this bug still exists or whether not).) Ok, we can have a test rebuilding several times the files that are most likely to become non deterministic. However it would be better if we can find some way to trigger those non-deterministic builds with only two builds. Maybe we can try something like this : - a library that we put in LD_PRELOAD as a wrapper on readdir to return directory entries in random order instead of inodes number, so it's more likely to be different on each build. - a python library that we put in PYTHONPATH, to override dict.iterkeys to return keys in random order. If I understand ticket #10159 correctly, it was caused by iterkeys returning keys in the same order most of the time, but not all the times. > > > - anything else that you think might be useful for me to know > > You write: "We can produce some packages for Tor Browser, to make > testing of the browser easier." > > In which regard is it easier to test the browser if you have packages? Hmm yes, it does not really help in that regard, I've removed this. What can help is packages nightly builds, as it makes it easy for someone to update their tor browser every day to act as a beta tester. > And how should that look like outside of the Tor Browser Bundle? I fear > we create extra bugs if we move the browser outside the environment it > will be used in (i.e. the TBB) just for testing purposes. Even if we > won't create extra bugs this way we might miss some. To be clear, > running the tests you call "Usablility tests" and "Reproducible build > test" outside the bundle, seems fine to me, while my concerns apply to > the fingerprinting and privacy tests. What it would look like is similar to what they use in tails : https://tails.boum.org/contribute/release_process/iceweasel/ But you are right that we can miss some bugs if we only test it outside TBB, so we should also run the tests in TBB. > > The test helpers are a good idea. You might want to rename "Cookies > tool" to something like "Identifier tool" matching the Tor Browser > specification more closely (especially as you actually mean "Identifier > tool" as "Later versions could be extended to also use other techniques > for storing informations in the browser" indicates). Ok, updated. An other thing that can be done is keeping an archive of all builds for 3 months (or more depending on space available), so that git bisect can be done more quickly. Would that be helpful ? pgpmP9AIkHR6Z.pgp Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Tor project automation work
Hello, If you don't know me yet, I am the new person working on automation : https://www.torproject.org/about/jobs-lead-automation.html.en To get started working on tor automation, I am currently looking at all components that are part of tor project, to find what is the current status regarding build, packaging, testing, and what should be done. I'm going to write a summary of this, with some proposals and a general plan for the work to be done during the coming months, and it will be available at the following URLs : https://people.torproject.org/~boklm/automation/tor-automation-review.html https://people.torproject.org/~boklm/automation/tor-automation-review.pdf (you can find an early version there) In order to help me doing that, I'm very interested to receive from developers of any tor components : - a description or ticket number of bugs that you wish could have been detected earlier with automated tests - any wish or specific needs that you may have - anything else that you think might be useful for me to know If you want to discuss this on IRC, I'm 'boklm' on #tor-dev. Thanks! Nicolas ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
