Re: [tor-dev] Ready to Integrate/Review New Marionette Version into Tor
* John Helmsen:
> David,
>
> Ben hit the following error while running 'make testbuild':
>
> --2018-07-26 08:33:09--
> https://downloads.sourceforge.net/stixfonts/STIXv1.1.1-latex.zip
> Resolving downloads.sourceforge.net (downloads.sourceforge.net)...
> 216.105.38.13
> Connecting to downloads.sourceforge.net
> (downloads.sourceforge.net)|216.105.38.13|:443...
> connected.
> HTTP request sent, awaiting response... 404 Not Found
> 2018-07-26 08:33:09 ERROR 404: Not Found.
(https://trac.torproject.org/projects/tor/ticket/26949 tracks this issue.)
If you want to fix it for now, you can apply this and it should work:
diff --git a/projects/fonts/build b/projects/fonts/build
index 9b33da9..a1e066b 100644
--- a/projects/fonts/build
+++ b/projects/fonts/build
@@ -13,8 +13,8 @@ mkdir -p $distdir
END; %]
[% IF c("var/linux") || c("var/osx") %]
- unzip -o STIXv1.1.1-latex.zip -d STIX
- cp "STIX/Fonts/fonts/opentype/public/stix/STIXMath-Regular.otf" $distdir/
+ unzip -o 2.0.0.zip -d STIX
+ cp
"STIX/stixfonts-2.0.0/archive/STIXv1.1.1/Fonts/STIX-Word/STIXMath-Regular.otf"
$distdir/
[% END %]
[% IF c("var/linux") %]
cp NotoEmoji-Regular.ttf $distdir/
diff --git a/projects/fonts/config b/projects/fonts/config
index 1547403..9d11d2c 100644
--- a/projects/fonts/config
+++ b/projects/fonts/config
@@ -102,6 +102,6 @@ input_files:
- URL:
https://github.com/googlei18n/noto-cjk/raw/f36eda03dfa5582a6d49abbfb5c83d0209584158/NotoSansTC-Regular.otf
sha256sum:
e6b82f7d3dab605c428161124ceb5e169cde93de632d800297b167cdd88e7baa
enable: '[% c("var/linux") %]'
- - URL: https://downloads.sourceforge.net/stixfonts/STIXv1.1.1-latex.zip
-sha256sum:
e3b0f712e2644438eee2d0dcd2b10b2d54f1b972039de95b2f8e800bae1adbd8
+ - URL: https://github.com/stipub/stixfonts/archive/2.0.0.zip
+sha256sum:
4327a16797dabebedce28a9075671730e22c7f74831b24b1fb91e27faec5a235
enable: '[% c("var/linux") || c("var/osx") %]'
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Ready to Integrate/Review New Marionette Version into Tor
David,
Ben hit the following error while running 'make testbuild':
--2018-07-26 08:33:09--
https://downloads.sourceforge.net/stixfonts/STIXv1.1.1-latex.zip
Resolving downloads.sourceforge.net (downloads.sourceforge.net)...
216.105.38.13
Connecting to downloads.sourceforge.net
(downloads.sourceforge.net)|216.105.38.13|:443...
connected.
HTTP request sent, awaiting response... 404 Not Found
2018-07-26 08:33:09 ERROR 404: Not Found.
When looking for the file, I found this on the website:
As of April 2018 STIX Fonts has moved to GitHub (
https://github.com/stipub/stixfonts/). All releases of STIX are available
only through GitHub and any new issues should be reported on the new site.
On Tue, Jul 24, 2018 at 2:09 PM, David Fifield
wrote:
> On Tue, Jul 24, 2018 at 01:57:36PM -0400, John Helmsen wrote:
> > Okay, I have generated a VM using VirtualBox of Ubuntu version 16. I've
> had to
> > restart the build process a couple of times, since the hard drive was
> 10GB,
> > then 20GB. Now I am using a 50GB box, so it may work this time.
> >
> > Should we create the branch using the -b command? ('git checkout -b
> > tbb-8.0a9-build3'?) Otherwise, it complains about being headless.
>
> It doesn't matter, just for the sake of doing a testbuild and priming
> the cache of dependencies (you'll notice the git_clones directory get
> filled in among others). But yes, you'll want a branch for integration,
> something like
> git checkout -b marionette-integration tbb-8.0a9-build3
>
--
John Helmsen
john.helm...@redjack.com
C: (240) 899-5676
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Sandboxed Tor Browser should be officially developed
2 of the 3 options mentioned by Matthew were that... On Thu, Jul 26, 2018 at 10:43 AM Nathaniel Suchy wrote: > Perhaps the developers could make something like Tor Tails but stripped > down bare bones to converse system resources with just Tor Browser > afterwards packaging it all into a nice Virtual Machine program that’s > invisible to the user. > On Thu, Jul 26, 2018 at 2:24 AM u wrote: > >> Hi! >> >> Yawning Angel: >> >> >> So please, make Sandboxed Tor Browser an official thing.>> Fuck you, >> pay me. >> While I believe that it is hard for some people to understand the free >> software ecosystem and personal development efforts, I think that this >> kind of reply is absolutely off-putting and intimidating. And it has the >> unfortunate side effect of not helping anybody understand what's gping on. >> >> Cheers, >> u. >> ___ >> tor-dev mailing list >> tor-dev@lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev >> > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Sandboxed Tor Browser should be officially developed
Perhaps the developers could make something like Tor Tails but stripped down bare bones to converse system resources with just Tor Browser afterwards packaging it all into a nice Virtual Machine program that’s invisible to the user. On Thu, Jul 26, 2018 at 2:24 AM u wrote: > Hi! > > Yawning Angel: > > >> So please, make Sandboxed Tor Browser an official thing.>> Fuck you, > pay me. > While I believe that it is hard for some people to understand the free > software ecosystem and personal development efforts, I think that this > kind of reply is absolutely off-putting and intimidating. And it has the > unfortunate side effect of not helping anybody understand what's gping on. > > Cheers, > u. > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Alternative directory format for v3 client auth
Alex Xu writes:
> Quoting George Kadianakis (2018-07-11 19:26:06), as excerpted
>> Michael Rogers writes:
>>
>> > On 11/07/18 14:22, George Kadianakis wrote:
>> >> Michael Rogers writes:
>> >>
>> > First, Ed25519-based authentication ("intro auth"). Could this be punted
>> > to the application layer, or is there a reason it has to happen at the
>> > Tor layer?
>> >
>>
>> Yes, it could be stuffed into the application layer. However that could be
>> an argument for everything (including end-to-end encryption of onions).
>>
>> It might be the case that some application-layer protocols don't allow
>> any sort of pluggable authentication to happen on top of them, or that
>> users wouldn't want to enable them for some reason. Does this feel like
>> an artificial reason to you?
>>
>> Another positive thing about intro auth is that it allows fine-grained
>> control over authentication, potentially allowing different tiers of
>> users etc.
>
> That might be true, but it's not an argument for intro auth, because
> application-layer authentication offers that too.
>
>> Also see https://lists.torproject.org/pipermail/tor-dev/2018-May/013155.html
>>
>> > Fourth, what goals does desc auth achieve in the v3 design? If I
>> > understand right, in v2 its major goal was to hide the intro points from
>> > everyone except authorised clients (including HSDirs). In v3 the intro
>> > points are already hidden from anyone who doesn't know the onion address
>> > (including HSDirs), so this goal can be achieved by not revealing the
>> > onion address to anyone except authorised clients.
>> >
>> > I'm probably missing something, but as far as I can see the only other
>> > goal achieved by desc auth is the ability to revoke a client's access
>> > without needing to distribute a new onion address to other clients. This
>> > seems useful. But again, I'd ask whether it could be punted to the
>> > application layer. The only advantage I can see from putting it at the
>> > Tor layer is that the list of intro points is hidden from revoked
>> > clients. Is there a real world use case where that's a big enough
>> > advantage to justify putting all this authorisation machinery at the Tor
>> > layer? Or maybe there are other things this design achieves that I
>> > haven't thought of.
>> >
>>
>> Yes, you identified the point of desc auth correctly.
>>
>> Another very important reason to have an authorization system inside
>> Tor, is because it allows only authorized clients to rendezvous (and in
>> general directly interact) with the onion service. That can mitigate all
>> sorts of guard discovery and correlation attacks that could be doable by
>> anyone, and restrict them only to authorized users.
>>
>> Of course the above is achieved with either desc auth or intro
>> auth. Having both of them does not offer any benefits in this direction.
>
> asn said that a benefit of Tor-level authentication is that users may be
> likely to accidentally reveal their onion service address, e.g. by
> posting screenshots, or copying and pasting the URL, but are less likely
> to accidentally reveal their separate authentication credentials.
>
> I thought of a minor benefit of desc auth: revoked clients are prevented
> entirely from attacking the onion service, e.g. by DDoS.
True. This is actually one of the most useful benefits of client auth
right now: blocking introduction requests from non-authenticated clients
and hence blocking guard discovery or DDoS attacks.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Alternative directory format for v3 client auth
Quoting George Kadianakis (2018-07-11 19:26:06), as excerpted
> Michael Rogers writes:
>
> > On 11/07/18 14:22, George Kadianakis wrote:
> >> Michael Rogers writes:
> >>
> > First, Ed25519-based authentication ("intro auth"). Could this be punted
> > to the application layer, or is there a reason it has to happen at the
> > Tor layer?
> >
>
> Yes, it could be stuffed into the application layer. However that could be
> an argument for everything (including end-to-end encryption of onions).
>
> It might be the case that some application-layer protocols don't allow
> any sort of pluggable authentication to happen on top of them, or that
> users wouldn't want to enable them for some reason. Does this feel like
> an artificial reason to you?
>
> Another positive thing about intro auth is that it allows fine-grained
> control over authentication, potentially allowing different tiers of
> users etc.
That might be true, but it's not an argument for intro auth, because
application-layer authentication offers that too.
> Also see https://lists.torproject.org/pipermail/tor-dev/2018-May/013155.html
>
> > Fourth, what goals does desc auth achieve in the v3 design? If I
> > understand right, in v2 its major goal was to hide the intro points from
> > everyone except authorised clients (including HSDirs). In v3 the intro
> > points are already hidden from anyone who doesn't know the onion address
> > (including HSDirs), so this goal can be achieved by not revealing the
> > onion address to anyone except authorised clients.
> >
> > I'm probably missing something, but as far as I can see the only other
> > goal achieved by desc auth is the ability to revoke a client's access
> > without needing to distribute a new onion address to other clients. This
> > seems useful. But again, I'd ask whether it could be punted to the
> > application layer. The only advantage I can see from putting it at the
> > Tor layer is that the list of intro points is hidden from revoked
> > clients. Is there a real world use case where that's a big enough
> > advantage to justify putting all this authorisation machinery at the Tor
> > layer? Or maybe there are other things this design achieves that I
> > haven't thought of.
> >
>
> Yes, you identified the point of desc auth correctly.
>
> Another very important reason to have an authorization system inside
> Tor, is because it allows only authorized clients to rendezvous (and in
> general directly interact) with the onion service. That can mitigate all
> sorts of guard discovery and correlation attacks that could be doable by
> anyone, and restrict them only to authorized users.
>
> Of course the above is achieved with either desc auth or intro
> auth. Having both of them does not offer any benefits in this direction.
asn said that a benefit of Tor-level authentication is that users may be
likely to accidentally reveal their onion service address, e.g. by
posting screenshots, or copying and pasting the URL, but are less likely
to accidentally reveal their separate authentication credentials.
I thought of a minor benefit of desc auth: revoked clients are prevented
entirely from attacking the onion service, e.g. by DDoS.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Ready to Integrate/Review New Marionette Version into Tor
David Fifield: > On Fri, Jul 20, 2018 at 04:12:21PM -0400, John Helmsen wrote: >> We are in the process of writing the documentation for Marionette, but the >> documentation on the web page should be sufficient for at least getting a >> full >> evaluation started. We'd like to have the evaluation complete by the end of >> next month, hopefully the middle of next month, and stand ready to make any >> and >> all changes necessary. >> >> A full set of documentation will also be written for designing your own >> protocols. This is in process. >> >> Please let us know what you need. > > The Tor Browser developers may have more specific requests, but I can > suggest some steps to get started. > > Open a ticket at https://trac.torproject.org/ for discussion and to > track progress. > Type: project > Component: Applications/Tor Browser > Keywords: marionette > The old ticket for FTE is a good reference: https://bugs.torproject.org/10362 > > And then it would help if you port your build process to the Tor Browser > build system. General information: > https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking > First, just build > git clone https://git.torproject.org/builders/tor-browser-build.git > cd tor-browser-build > git checkout tbb-8.0a9-build3 > make testbuild # or, e.g., testbuild-linux-x86_64 > Then you'll have to add a new project (consisting of a "build" and > "config" file) for Marionette and each of its dependencies. You can copy > from existing projects as templates. Here is the meek project, for > example: > https://gitweb.torproject.org/builders/tor-browser-build.git/tree/projects/meek > You'll also need to add bridge lines to: > https://gitweb.torproject.org/builders/tor-browser-build.git/tree/projects/tor-browser/Bundle-Data/PTConfigs/bridge_prefs.js > To build just one project, not an entire release, do e.g.: > rbm/rbm build gmp --target testbuild --target torbrowser-linux-x86_64 > rbm/rbm build marionette --target testbuild --target > torbrowser-linux-x86_64 Thanks David. Yes, those are good first steps to get started. Experience shows that getting things running for Linux is the easiest part, thus I'd suggest to start with that one first. There is no need to have everything ready for all supported platforms to get your PT integrated. It's fine to ship it for the alpha for some platforms only to further shake out bugs and make it more robust. Thus, don't hesitate to put things into review state early on. Finally, don't hesitate as well to ask in #tor-dev or by mail or on the trac ticket (I'll have it on my radar) in case you are stuck or are running into issues, we are happy to help. Georg signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Sandboxed Tor Browser should be officially developed
Hi! Yawning Angel: >> So please, make Sandboxed Tor Browser an official thing.>> Fuck you, pay me. While I believe that it is hard for some people to understand the free software ecosystem and personal development efforts, I think that this kind of reply is absolutely off-putting and intimidating. And it has the unfortunate side effect of not helping anybody understand what's gping on. Cheers, u. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
