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

[Jody Harris]

My Rackspace box would be ideal for everything except that I have to pay
for bandwidth by the GB.
----
Ph. 575-208-4567
- Think carefully.



On Wed, Jan 25, 2012 at 9:41 AM, Shawn Willden <shawn at willden.org> wrote:

> Anyone feel like setting this up?  I might give it a try, but the ideal
> would be to have a gateway on a super-fast, unlimited bandwidth connection.
>  Mine is pretty fast, but I think some folks have gigabit.
>
> ---------- Forwarded message ----------
> From: Nathan <nejucomo at gmail.com>
> Date: Wed, Jan 25, 2012 at 2:13 AM
> Subject: [tahoe-dev] Announcement: lafs-rpg - Restrictive Proxy Gateway
> To: Tahoe-LAFS development <tahoe-dev at tahoe-lafs.org>
>
>
> 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
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at tahoe-lafs.org
> http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>
>
>
> --
> Shawn
>
> _______________________________________________
> volunteergrid2-l mailing list
> volunteergrid2-l at tahoe-lafs.org
> http://tahoe-lafs.org/cgi-bin/mailman/listinfo/volunteergrid2-l
> http://bigpig.org/twiki/bin/view/Main/WebHome
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/cgi-bin/mailman/private/volunteergrid2-l/attachments/20120125/2401e23e/attachment.html>