Hi, [email protected] writes:
> Hi. Whonix [0] dev here. Welcome to Freenet! :) > We are looking for a censorship-resistant and decentralized way to > communicate notifications about critical situations [1] to our users and > host the project metadata and files themselves to resist a Permanent > Takedown Attack threat.[2] That is great! > Freenet meets our needs perfectly but > unfortunately as documented it cannot work over Tor. If this changes in > the short term we will be able to ship it in our distro to a userbase of > 15K users by conservative estimates. There is a way to route connections over Tor, but it isn’t tested regularly and currently only works in friend-to-friend mode. For details see: http://127.0.0.1:8888/freenet:USK@ED3bT6ngiUE1RayB9N~aQz6iIrc4Gwj-ubnaw22s~aY,kN3gtmcb9pHa2FKrVPw1U5209WvB7vvuQ7oC42gt6ic,AQACAAE/wats-dieh/17/freenet-over-tor.html You could provide several tor-enabled freenet nodes and pre-configure the nodes of users to connect to you. Doing this to scale would require you to devise a way to receive the freenet references of people who run Whonix. However Freenet does not need Tor as anonymizer (and would reduce its theoretical reachable security if it used it). Instead it has its own routing algorithm which profits from the relaxed requirements of a distributed storage network as opposed to the realtime routing tor needs to do. Therefore I’d suggest simply connecting to Freenet opennet. The only people for whom this can reduce the security compared to tor are those who currently use tor with secret bridges and pluggable transports. These could configure Freenet to use the friend-to-friend mode over Tor, or even a separate darknet. But that would be more effort to set up. You could build a small tor hidden service where people could submit their noderefs (or where a tool could do that automatically) and have these added automatically on your project-run nodes (for example distributed among them over a Freenet site and snarfed from that by supporters nodes). This does not exist yet, though. > Other points: > > * pyFreenet is very convenient in communicating with Freenet with > scripts. Is there a similar mechanism that we can use to customize node > settings? You can start with customizing the settings before launching the node, as it is done in spawn: https://github.com/ArneBab/lib-pyFreenet-staging/blob/py3/freenet3/spawn.py#L23 Also you can modify the configuration from pyFreenet but I did not test that in a long time: https://github.com/ArneBab/lib-pyFreenet-staging/blob/py3/fcp3/node.py#L1132 See also: https://wiki.freenetproject.org/FCPv2/ModifyConfig You can have a look at my work with auto-spawning of Freenet nodes in fcpupload and babcom. See http://www.draketo.de/light/english/freenet/pyfreenet-041-autospawn In short: fcpupload --spawn --fcpPort 9486 testfile ^ spawn a node, uploads testfile into Freenet. Provides the key to the file when the upload finishes and tears down the node again. I did not yet integrate the same into fcpget, but that’s a matter of a few hours free creative time (so I think I’d be able to provide it before the end of the first week of january, if you need it). auto-spawning currently downloads Freenet over the internet, though. Doing this download over Tor shouldn’t be hard. In fact it just requires setting the proxy: ## python3 import requests proxies = { 'http': 'socks5://localhost:9150', 'https': 'socks5://localhost:9150' } url = 'http://httpbin.org/ip' print(requests.get(url, proxies=proxies).text) > * Before including pyFreenet we would need it to be signed by its > respective dev so we can validate it before running anything of course. I’m the current maintainer. Do you need gpg signed git revisions or tags, signed release tarballs or signed Mercurial commits? > * We would prefer if you run a package repo so we can easily pull your > software for Whonix image builds. Tell me how I can easily integrate that into my release process and I can do that. pyFreenet consist purely of Python packages, without need of compilation steps. > [0] Whonix is an anonymous Debian based OS (whonix.org) > > [1] Apt CVE-2016-1252: During apt-get upgrading signature verification > can be > tricked resulting in arbitrary package installation, system compromise. > We would have liked a way to notify users to avoid running apt entirely > and instead the necessary manual steps to download/verify the patched > binaries. > > [2] https://www.whonix.org/wiki/Dev/Permanent_Takedown_Attack_Defender It’s great to see you tackle this thoroughly! Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken
signature.asc
Description: PGP signature
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
