[tahoe-dev] Announcement: lafs-rpg - Restrictive Proxy Gateway

Nathan nejucomo at gmail.com
Wed Jan 25 09:13:09 UTC 2012


Hello tahoe-dev,

There is demand for a more "locked down" webapi that the public can
use to retrieve content from a Tahoe-LAFS network, while minimizing
risk to the webapi operator.  I too have wanted this for awhile, and
I've implemented a set of HTTP redirection and access control rules in
haproxy.

I've made a script to stick the right parameters in the right spots of
the configuration and bundled it up here:

https://bitbucket.org/nejucomo/lafs-rpg/overview

This repository is intended to allow you to get a "public gateway" to
Tahoe content up and running on a debian system with minimal fuss.
Let me know if you try it and something doesn't work.  (Also, I've
tried to document it well, let me know if that needs improvement.)

I've spent some time thinking about and researching the webapi
frontend to understand what "locked down" should be.  If you want a
public webapi that is read-only, this project is a good start and
*should be* reasonably secure.  However, security is much harder to
notice than a lack of security.  If you see flaws, please let me know
with the bitbucket issue tracker.

I've created some new Tahoe-LAFS tickets and rounded up old tickets
that seem relevant to this project:

Here's a "brainstorm" that urges the community to think about the case
where an operator wants to provide a public gateway but have some
safeguards against malicious users:

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1665

That links to other tickets about documenting the webapi URL structure
(#1663) in a concise way (to make access policies easier to reason
about), and a few old ones about unconstrained uploads (#587) and
leaking an introducer furl (#860).


I've just set up a lafs-rpg site, with not much in the way of content,
in case you want to poke at a live demo:

https://con.struc.tv


Regards,
Nathan


More information about the tahoe-dev mailing list