What do you think about the most obvious approach? Use public intents than any other app can call to create/delete a hidden service or for get config files of his service?
2016-11-15 15:17 GMT+01:00 arrase <[email protected]>: > Are you suggesting something? XD > > I can take a look at the problem and propose a solution, it will not be > fast but I can do it. > > Tonight I will try to compile Orbot from sources and try to familiarize > myself with the code. (Is there a wiki with info??) > > How do you want to focus the change? What should be possible by a third > party? > > In my opinion: > > - Be able to register a hidden service for your ports without sharing it > with other applications. > - Be able to backup the configuration files in order to migrate the > service. > - Everything should be possible without root > > It would be nice if all this was possible without giving access to the Tor > configuration port, but right now I can not think of how to do it. > > I keep thinking ..... after working, I'll dedicate some time to the problem > > > 2016-11-15 14:19 GMT+01:00 Hans-Christoph Steiner < > [email protected]>: > >> >> >> arrase: >> > 2016-11-15 13:23 GMT+01:00 Michael Rogers <[email protected]>: >> > >> >> Hi arrase, >> >> >> >> Thanks for discovering this bug. Can you describe how Briar's Tor >> daemon >> >> conflicts with Orbot? What problems does it cause? Our goal is for >> Briar >> >> to be able to operate on the same device as Orbot without problems. >> >> >> >> >> > I do not think it could be called a bug, and definitely not a Briar bug >> at >> > all. I find it hard to argue in English, I'm sorry. >> > >> > But if it is true that is a problem if more applications follow the same >> > path as Briar implementing a Tor daemon within the application. >> > >> > Briar opens those ports for Tor: >> > >> > Tcp 0 0 127.0.0.1:59050 0.0.0.0:* LISTEN 10019 214952 18753 >> > Tcp 0 0 127.0.0.1:59051 0.0.0.0:* LISTEN 10019 213387 18753 >> > >> > If Orbot starts first, nothing prevents it from taking ports 59050 and >> > 59051 as control ports. It is a remote but real possibility and would be >> > more real when more applications opt for the same solution. >> > >> > It's just an argument about changing the hidden service API for Orbot. >> > >> > I think there are more strong arguments like that each application can >> > manage the configuration files of the hidden service to be able to >> migrate >> > between devices. >> > >> > It does not look very good to make an application that uses the hidden >> > service as a user identifier and if we lose the device we lose our >> entire >> > network of contacts. >> > >> > I think they are good arguments for bringing about an improvement in >> Orbot >> > APi as proposed by Nathan. >> >> I think we all want to have a nice Intent-based API in Orbot for apps to >> work with Hidden Services, the real question is: who is going to do the >> work. That would be a great place for you to start to get involved. >> >> .hc >> >> >> -- >> PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 >> https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556 >> _______________________________________________ >> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev >> To unsubscribe, email: [email protected] >> > >
_______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: [email protected]
