#2 Updated by intrigeri 2013-08-09 01:01:52

First of all, this can be manually added (at least as easily as Tahoe-LAFS can be configured on Tails currently) to the persistence configuration file, so actually it is already an option to make this directory persistent.

So, I guess you mean adding a persistence preset in the graphical persistence configuration assistant?

#5 Updated by zooko 2013-10-03 08:28:09

For what it is worth, I’ve been working on this by working on improving the init scripts in the Debian packaging:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652003

I’ve been doing this because of this mail from intrigeri saying what would make Tahoe-LAFS a good tool for use in Tails:

https://mailman.boum.org/pipermail/tails-dev/2013-August/003397.html

The first item was “Tahoe-LAFS is properly maintained in Debian”, and so I haven’t really thought more about the following items but instead did those code-reviews with Bertagaz for the Debian packaging. ☺

If there’s something else you’d like me to work on, please let me know. I’ve been waiting for a few days for Bertagaz to respond to my most recent — rather hefty — code review. Maybe I should make time to write a patch for the init scripts that demonstrates the suggestions in my review.

#6 Updated by intrigeri 2013-10-03 09:53:32

> For what it is worth, I’ve been working on this by working on improving the init scripts in the Debian packaging:

Yeah, bertagaz told me about it. This is awesome, thanks!

> The first item was “Tahoe-LAFS is properly maintained in Debian”, and so I haven’t
> really thought more about the following items but instead did those code-reviews with
> Bertagaz for the Debian packaging. ☺

FWIW, it wasn’t clear to me this effort was related directly to having
Tahoe-LAFS usable as a persistence option for Tails, hence my last
reply on this ticket. But anyway, this is a great (and necessary)
first step, be it to make Tahoe-LAFS usable in Tails, or even to
install it by default, or even to make it available (at the end of the
road) as an option for persistent storage.

For more information on what I mean with “persistence” in this
context, see our persistence documentation and
the design documentation

> If there’s something else you’d like me to work on, please let
> me know.

Well, once Tahoe-LAFS is in good shape in Debian, if you (or ioerror,
or anyone else) wants to tackle the actual goal of this ticket, see
how it can work, find a nice design and UX integration, then they’re
much welcome :)

#7 Updated by bertagaz 2013-10-03 15:29:27

intrigeri wrote:
> > For what it is worth, I’ve been working on this by working on improving the init scripts in the Debian packaging:
>
> Yeah, bertagaz told me about it. This is awesome, thanks!

Hefty or not, Zooko’s review was meaningful. In the meantime, I travelled and had work on Tails, but I planned to answer Zooko in the coming days. So far his inputs were once more enlightning, what lacked was my available time to implement them, and avoid lags. More on all this soon. :)

> > The first item was “Tahoe-LAFS is properly maintained in Debian”, and so I haven’t
> > really thought more about the following items but instead did those code-reviews with
> > Bertagaz for the Debian packaging. ☺
>
> FWIW, it wasn’t clear to me this effort was related directly to having
> Tahoe-LAFS usable as a persistence option for Tails, hence my last
> reply on this ticket. But anyway, this is a great (and necessary)
> first step, be it to make Tahoe-LAFS usable in Tails, or even to
> install it by default, or even to make it available (at the end of the
> road) as an option for persistent storage.
>
> Well, once Tahoe-LAFS is in good shape in Debian, if you (or ioerror,
> or anyone else) wants to tackle the actual goal of this ticket, see
> how it can work, find a nice design and UX integration, then they’re
> much welcome :)

The initscript feature we’re working on with Zooko doesn’t seem so much related to Tahoe-LAFS integration in Tails. It is much more meant for sysadmin easy maintenance, let say more related to the Tails server project.

But I agree that Tahoe-LAFS integration in Tails would deserve some thoughts and time to be at least minimally designed and tested. And mixing this two tools could bring a lot of interesting usage.

Still a first start might be to add this ~/.tahoe in live-persistence-setup, as ioerror asked. It doesn’t sound to me such a big move in term of maintenance, but still a big step to go on collaborating between the two projects.

#8 Updated by zooko 2013-10-03 15:31:28

Here is the list of steps that intrigeri wrote in https://mailman.boum.org/pipermail/tails-dev/2013-August/003397.html :

• Tahoe-LAFS is properly maintained in Debian

I think this is currently the case, so we can check this item off. If there’s something in this that is a blocker for Tails integration, please spell it out.

• we know how much it would make the ISO bigger
• we know what packages it pulls as dependencies in a Tails system and the list doesn’t look too scary

Someone more familiar with Tails than I should do these steps.

• the tooling is available that makes it useful for many Tails users, without low-level expertise (I’m glad you’re working on it!)
• as usual, design documentation + end-user documentation is ready :)

Here is the introductory doc for users:

https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/running.rst

Here is the index of all user docs:

https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Doc

Here is the index of all developer docs:

https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Dev#DeveloperDocs

I think this documentation is currently good enough. If you disagree, please say so.

So I think the remaining TODO items from that last are:

• we know how much it would make the ISO bigger
• we know what packages it pulls as dependencies in a Tails system and the list doesn’t look too scary

#9 Updated by zooko 2013-10-03 15:35:20

intrigeri wrote:
>
>
> For more information on what I mean with “persistence” in this
> context, see our persistence documentation and
> the “design documentation”: https://tails.boum.org/contribute/design/persistence/

I have looked this over a couple of times. I’m not sure if it is a good idea to store Tails persistence data e.g. OTR keys and ssh client configuration in LAFS, and if it is a good idea, I’m not sure of the specifics of how it ought to be done. LAFS is good for things that need to be stored remotely, because they are potentially large or because they need to be accessed from multiple clients. There are obvious major anonymity/privacy implications of storing and accessing anything remotely.

Would a good next-step be to include Tahoe-LAFS as a default part of the Tails distribution? I think so!

#10 Updated by intrigeri 2013-10-04 01:02:42

> * Tahoe-LAFS is properly maintained in Debian

> I think this is currently the case, so we can check this item off. If there’s
> something in this that is a blocker for Tails integration, please spell it out.

I’m happy to check this item off once a new upload fixes #683331 and
migrates to testing. (Also, I’m told some additional FHS compliance
work may be needed to make the package up to Debian standards, but
I’ll let the maintainer start this discussion on the upstream bug
tracker :)

Oh, while we’re at it: is 1.9.2 good enough for Tails, or do we have
to wait for the latest upstream release to be packaged, migrate to
testing, and be backported for Wheezy?

> I think this documentation is currently good enough. If you
> disagree, please say so.

Perhaps something (minimal) would be needed in the Tails
documentation, that points to the upstream doc, and (if needed)
mentions specific consequences of running Tahoe-LAFS within Tails,
wrt. our threat model (not that I know which ones there are, that’s
why someone needs to research this, and write down the result into our
design doc).

#11 Updated by intrigeri 2013-10-04 01:03:02

> Would a good next-step be to include Tahoe-LAFS as a default part of the Tails
> distribution? I think so!

I think so too!

#12 Updated by zooko 2013-10-04 21:07:00

intrigeri wrote:
>
> (Also, I’m told some additional FHS compliance work may be needed to make the package up to Debian standards, but I’ll let the maintainer start this discussion on the upstream bug tracker :)

Yes, please open a ticket on https://Tahoe-LAFS.org in order to make the Tahoe-LAFS team will become aware of an issue.

> Oh, while we’re at it: is 1.9.2 good enough for Tails, or do we have to wait for the latest upstream release to be packaged, migrate to testing, and be backported for Wheezy?

There are no known security issues in 1.9.2 which would make it necessary to wait for 1.10 or a newer release of Tahoe-LAFS. We try to document security issues thoroughly, so here you go…

• known issues in recent releases, including 1.10.0 and 1.9.2:

https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/known_issues.rst

• all notable changes from 1.9.2 to 1.10.0:

https://tahoe-lafs.org/trac/tahoe-lafs/browser/NEWS.rst

• then, of course the real nitty gritty, the cornucopia of interesting problems catalogued in our beloved issue tracker!

https://tahoe-lafs.org/trac/tahoe-lafs/wiki/ViewTickets

Here’s the kind of query you could get endless hours of entertainment from: https://tahoe-lafs.org/trac/tahoe-lafs/query?status=assigned&status=new&status=reopened&keywords=~security&or&keywords=~anonymity&status=assigned&status=new&status=reopened&or&keywords=~capleak&status=assigned&status=new&status=reopened&or&status=assigned&status=new&status=reopened&keywords=~confidentiality&or&keywords=~websec&status=assigned&status=new&status=reopened&or&status=assigned&status=new&status=reopened&keywords=~rollback&group=priority&col=id&col=summary&col=keywords&col=status&col=owner&col=type&col=priority&order=priority

> Perhaps something (minimal) would be needed in the Tails documentation, that points to the upstream doc, and (if needed) mentions specific consequences of running Tahoe-LAFS within Tails, wrt. our threat model (not that I know which ones there are, that’s why someone needs to research this, and write down the result into our design doc).

That’s a good idea.

Using Tahoe-LAFS for anything means opening (encrypted) connections to one or many Tahoe-LAFS storage servers and doing one of a small number of “recognizable” operations, such as uploading a file, downloading a file, listing the contents of a directory, and traversing a directory into a subdirectory. By “recognizable” I mean that, even though all of the connections, and all of the contents of the files, and all of the filenames and other file-related metadata, is encrypted, nonetheless just the traffic patterns would probably indicate to an observer which of those operations you are doing, and on which files and directories you are doing them.

Is that incompatible with some of your use cases / threat models?

#13 Updated by intrigeri 2013-10-05 02:36:59

> Is that incompatible with some of your use cases / threat models?

That’s generally not something Tails tries to protect against, but
a warning for users of obfuscated Tor bridges may be useful.

#14 Updated by zooko 2013-11-02 10:51:30

Hi folks, I just posted a review of the init script over on Debian bug 652003. My review found no problem in it, so hopefully an update of Tahoe-LAFS will go into Debian soon.

I was re-reading this ticket and I thought maybe I had written too much on a class=‘issue tracker-2 status-9 priority-4 priority-default child’ href=‘/code/issues/6227’ title=‘Persistence preset: Tahoe’>Feature #6227–12 and overwhelmed the reader, so here is just one thing from that comment that I would like to draw your attention:

> intrigeri wrote:
>
> (Also, I’m told some additional FHS compliance work may be needed to make the package up to Debian standards, but I’ll let the maintainer start this discussion on the upstream bug tracker :)

Yes, please open a ticket on https://Tahoe-LAFS.org in order to make the Tahoe-LAFS team aware of an issue.

#15 Updated by zooko 2013-11-12 08:18:08

Hey folks, is there some issue with Tahoe-LAFS’s FHS compliance? Please let us know. If it is too much trouble to open a ticket on https://Tahoe-LAFS.org (you have to create an account by entering a username, email-address, and password and clicking on a challenge email that gets sent to your email address), then just post it into this ticket and I’ll copy it onto https://Tahoe-LAFS.org.

#16 Updated by zooko 2014-01-23 13:36:26

Here is a ticket to track fixing Tahoe-LAFS’s persistent state and configuration files to fit FHS:

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

#17 Updated by zooko 2014-01-23 13:40:54

The newest release of Tahoe-LAFS is now in Debian!

http://metadata.ftp-master.debian.org/changelogs//main/t/tahoe-lafs/tahoe-lafs_1.10.0-1_changelog

#20 Updated by zooko 2014-03-24 19:47:27

I can think of a few possible uses that LAFS could serve. You’ll have to tell me if any of these are of interest to Tails users. The general theme is that LAFS is good for off-loading data to a remote server without exposing the cleartext of the data to snooping or manipulation, and it is good for sharing data.

There are probably other possible uses along these lines that I haven’t thought of.

LAFS vs. putting data on the persistent volume

Suppose I have a large dataset that I want to access, and it is too big to keep a copy of it on my persistence volume. So instead I store that data in a LAFS grid (i.e. a set of servers, which can dynamically change as servers are added and removed), and I put the read-cap to it on my persistent volume. A read-cap is a short string, for example: “URI:DIR2-CHK:66yvqs3mjzlc3fxerfgk57earm:iv56s6qeyqowifawmmiq6qdxghfex2fqycq3vnfz7pupsuc73uaq:1:1:1006”.

A read-cap gives access to an arbitrarily large collection of files and directories (provided that your client can connect to at least some of the servers that make up the LAFS grid which is storing the ciphertext). Here is a live demo showing a directory containing three files that the read-cap above would give you access to: https://zooko.com/uri/URI%3ADIR2-CHK%3A66yvqs3mjzlc3fxerfgk57earm%3Aiv56s6qeyqowifawmmiq6qdxghfex2fqycq3vnfz7pupsuc73uaq%3A1%3A1%3A1006/

Aside from the benefit of off-loading the potentially-large data from the potentially-small persistent volume, another advantage of this approach is that the data can be updated, though the read-cap is static. The read-cap can be made read-only, or even burned into read-only media such as a CD-ROM (if anyone uses those things anymore), while giving access to a directory that can have new files added into it, or extant files updated to new versions.

A related benefit of this approach is that the data can be shared. Many different Tails USB sticks (or CD-ROMs or whatever) could come with the same read-cap burned into them, and that would give the users of those sticks read access to the same dynamically-updatable (provided they could each connect to at least some of the LAFS servers).

LAFS vs. an SFTP server

Okay, now let’s compare and contrast using LAFS as described above vs. using an SFTP server for the same purpose. The SFTP server has the same effect of off-loading bulk data from the persistent volume but requiring live access to remote server to access that data. The difference between SFTP and LAFS for this is in the the confidentiality and authentication of the data.

If you use SFTP then whoever controls the SFTP server gets to see the contents of all the files, and also gets to control the contents of those files, i.e. the SFTP server can change the contents of the files, or could even cause some clients to see different contents of the files than other clients see.

If you use LAFS, then the encryption and authentication are performed end-to-end instead of client-to-server.

This means the LAFS server or servers do not have the ability to read or modify the contents of the files.

For example, suppose you made a single physical Tails USB stick which had a write-cap (the cryptographic identifier that gives the ability to upload new files or change the contents of files) to a directory, and you made many physical Tails USB sticks which had the read-cap to that directory. Then the people using those latter sticks would have a cryptographic assurance that the contents of that directory was generated by someone who had access to that former stick (or otherwise had access to that write-cap). They would also have the cryptographic assurance that nobody, including LAFS server operators, could read the contents of that data unless they first gained access to the read-cap or write-cap for that data.

Another feature of LAFS compared to SFTP is that LAFS can spread the data across multiple servers in a “grid”, so that the failure of unavailability of a single server or a small subset of the servers doesn’t render the data inaccessible.

#23 Updated by intrigeri 2014-03-25 09:33:40

Another question while I’m at it: is the tahoe-lafs package in Wheezy (1.9.2-1) good enough for these usecases, or should we look into a backport of something newer?

Also, note that in the current state of things, Tahoe-LAFS won’t be part of Debian Jessie as it is RC-buggy (https://bugs.debian.org/735940, not mentionning the potential FHS issues that IIRC bertagaz has been working on upstream, but that are unfortunately not tracked in the Debian bug tracker), so if we want to make it a supported option in Tails on the long term, someone will have to invest time into maintaining the Debian package.

#24 Updated by zooko 2014-03-25 13:22:40

I don’t know where the Debian version of Tahoe-LAFS stores files. In the upstream version, all such files are stored in a single “base directory” that can be specified on the command-line, and that defaults to “~/.tahoe”.

Tahoe-LAFS v1.9 is good enough for those use cases.

I’ll try to help with https://bugs.debian.org/735940 , although I’m not entirely sure what needs to be done. (See that ticket for details of my ignorance.)

#25 Updated by zooko 2014-03-30 03:48:14

Okay we have a plan to fix https://bugs.debian.org/735940 : https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2208#comment:3

Now, what else can I do to help the Tails project use Tahoe-LAFS? How about an experiment in which some Tails developers try it out and see how it works? My company provides free storage service to deserving Free/OpenSource projects, and if you are interested we will provide free storage service to the Tails project for the use of the Tails developers. (I.e., if you think of Tahoe-LAFS as being better-than-SFTP as mentioned in https://labs.riseup.net/code/issues/6227#note-20 , then I’m offering the equivalent of running a good SFTP server for you. This doesn’t preclude you or anyone else from running servers yourselves, of course.)

How else can we help? Could we offer to write some documentation or something?

#26 Updated by intrigeri 2014-03-30 11:43:14

> Okay we have a plan to fix https://bugs.debian.org/735940

Great :)

> Now, what else can I do to help the Tails project use Tahoe-LAFS?

First, as written before, “someone will have to invest time into maintaining the Debian package”.

I’m sorry to put it bluntly, but the maintenance history of this package in Debian is not confidence-inspiring, and I would suggest interested people to team up with bertagaz and give him a hand.

> How about an experiment in which some Tails developers try it out
> and see how it works?

I agree the next step is to test Tahoe-LAFS in the context of Tails,
probably using an (experimental) Tails ISO based on Debian Wheezy:
http://nightly.tails.boum.org/build_Tails_ISO_feature-wheezy/

Then, someone will have to sort out the “what path(s) should be made persistent?” matter.

I doubt any Tails core developer will have time to work on this any
time soon, so likely creating sub-tasks of this ticket for every such
step would help getting other people to understand what’s the next
thing to do, and hopefully to do it themselves :)

> How else can we help? Could we offer to write some documentation or something?

I don’t think we’re at the point when documentation is required yet.

Cheers!

#27 Updated by zooko 2014-03-30 13:32:59

Could you be more specific about the maintenance history of Tahoe-LAFS in Debian? I was under the impression that it has been working fine all these years and there have never been any critical bugs or security problems in it. If you can explain to me what the issues are that undermine confidence in it, I would appreciate it.

#28 Updated by intrigeri 2014-03-30 15:07:51

redmine@labs.riseup.net wrote (30 Mar 2014 13:32:59 GMT) :
> Could you be more specific about the maintenance history of Tahoe-LAFS in Debian?

To be clear, my comment was not about the upstream code or release process.
Only about how the package is maintained in Debian.

So, here we go:

• Since it was introduced in Debian mid-2011, Tahoe-LAFS was removed twice from testing due to RC bugs. Such a removal does not happen unless it takes a long time to address a RC bug.
• The package has been missing a dependency during 6 months, and it took 3 months to the maintainer to reply the bug report.
• A RC bug was reported more than 2 months ago, no reply from the maintainer to this date yet.
• An important bug (738952) was reported 1.5 months ago, no reply from the maintainer yet.
• It has taken more than 6 months to package 1.9. No communication from the maintainer in the meantime.
• It has taken more than 6 months to fix a FTBFS (653312), which is RC.

This is, by far, not the worst track record one can find in the (huge)
Debian archive. Still, the lack of time the current maintainer clearly
experiences, and his resulting unresponsiveness, does not make me wish
we depend on this package in the current state of things. I personally
would recommend team-maintenance.

#29 Updated by vu3rdd 2014-04-02 07:59:06

intrigeri wrote:
> redmine@labs.riseup.net wrote (30 Mar 2014 13:32:59 GMT) :
> > Could you be more specific about the maintenance history of Tahoe-LAFS in Debian?
>
> To be clear, my comment was not about the upstream code or release process.
> Only about how the package is maintained in Debian.
>
> So, here we go:
>
> * Since it was introduced in Debian mid-2011, Tahoe-LAFS was removed twice from testing due to RC bugs. Such a removal does not happen unless it takes a long time to address a RC bug.
> * The package has been missing a dependency during 6 months, and it took 3 months to the maintainer to reply the bug report.
> * A RC bug was reported more than 2 months ago, no reply from the maintainer to this date yet.
> * An important bug (738952) was reported 1.5 months ago, no reply from the maintainer yet.
> * It has taken more than 6 months to package 1.9. No communication from the maintainer in the meantime.
> * It has taken more than 6 months to fix a FTBFS (653312), which is RC.
>
> This is, by far, not the worst track record one can find in the (huge)
> Debian archive. Still, the lack of time the current maintainer clearly
> experiences, and his resulting unresponsiveness, does not make me wish
> we depend on this package in the current state of things. I personally
> would recommend team-maintenance.

I would like to be a co-maintainer. I am a DD but I don’t have much experience maintaining python based packages.

I have the cowbuilder based scripts to build the package for testing and unstable. But the errors like #738952 can perhaps only be fixed if we run the tests as well, at least in the chroot environment. So, I modified the packaging to run the tests.

I will email the current maintainers tonight when I am near my desktop machine, so that I can gpg sign my email and ask if I can be a co-maintainer.

#30 Updated by intrigeri 2014-04-02 09:04:29

> I would like to be a co-maintainer.

Sounds great!

#31 Updated by vu3rdd 2014-04-07 18:31:17

intrigeri wrote:
> > I would like to be a co-maintainer.
>
> Sounds great!

Well, I haven’t heard anything from the current maintainers yet.

#32 Updated by zooko 2014-04-30 02:39:53

Okay we, the Tahoe-LAFS upstream maintainers, have made some fixes for Debian issue https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735940 . Here is our fix: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2208#comment:37 . Along the way we discovered some problems in the Debian package of libjs-d3 and the new Tahoe-LAFS maintainer, <rkrishnan@debian.org> opened tickets about that: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745688 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745687 .

#33 Updated by intrigeri 2014-04-30 07:00:56

Great news, congrats!

> […] the new Tahoe-LAFS maintainer, <rkrishnan@debian.org> […]

Perhaps I’m missing something else that happened privately, but I see no such maintainer change on http://packages.qa.debian.org/t/tahoe-lafs.html, just a recent NMU. If Ramakrishnan Muthukrishnan intends to maintain this package, and if this hasn’t been done yet, I suggest they get in touch with bertagaz and propose to move maintainance to a packaging team.

#34 Updated by micah 2014-04-30 16:33:27

There was a request by Ramakrishnan Muthukrishnan to Bertagaz and myself in a private email exchange where we were asked about co-maintainership. I responded indicating that my role in the tahoe-lafs package has been only as a sponsor for reviews and uploads for Bertagaz and because of that didn’t feel like I could speak authoritatively for the maintainership of the package, but I thought that such a co-maintainership arrangement made sense, even if I cannot speak for Bertagaz.

I’m of school of thought that any help on a package is good, I have no personal investment in a package being “mine” and if someone has the ability to help, we should welcome that help (this is why I am a member of the Low Threshold NMU group).

Because it has been almost a month now since the original request, I’m going to say that we should go ahead and accept Ramakrishnan to be on the team. If Bertagaz later wakes up and has a problem with it, he can speak up then, but I suspect he wont mind!

#35 Updated by intrigeri 2014-04-30 17:02:35

> Because it has been almost a month now since the original request, I’m going to say
> that we should go ahead and accept Ramakrishnan to be on the team. If Bertagaz later
> wakes up and has a problem with it, he can speak up then, but I suspect he wont mind!

Full ACK.

#36 Updated by zooko 2014-04-30 17:04:52

I’ve attempted to update https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735940 to have the tag “fixed-upstream”, but apparently I don’t know how to do that. Okay, we Tahoe-LAFS upstream folks have been looking over this ticket (https://labs.riseup.net/code/issues/6227 ). There were three Debian tickets mentioned in here:

• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738952 fixed
• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735940 fixed in upstream; rkrishnan is working on applying the patch to the Debian-packaged version of Tahoe-LAFS
• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653312 fixed
• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652003 fixed

Are there any other outstanding issues that Tails developers would like to see addressed in order to smooth the path for including Tahoe-LAFS in Tails?

For people just joining this ticket, please see my description in https://labs.riseup.net/code/issues/6227#note-20 of why including Tahoe-LAFS might be a useful feature for Tails users.

#37 Updated by zooko 2014-04-30 17:05:49

Oops, I mean four Debian tickets.

#38 Updated by intrigeri 2014-05-02 12:25:00

Great job!

zooko wrote:
> Are there any other outstanding issues that Tails developers would like to see addressed in order to smooth the path for including Tahoe-LAFS in Tails?

None that I can think of with my very limited knowledge of Tahoe-LAFS.

Anyone interested in pushing this further, see comment 20 on this very ticket :)

#39 Updated by vu3rdd 2014-05-02 18:56:45

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735940#106 -> fix uploaded.

#40 Updated by dawuud 2014-05-28 07:21:56

Greetings,

I am commenting on Zooko’s above comment #20
https://labs.riseup.net/code/issues/6227#note-20

I was able to install and configure Tahoe-LAFS on my TAILS persistent fs
by using this bash script here:
https://github.com/david415/tahoe-tails-utils/blob/tails_only/bootstrap.sh

Note #1:
HOWEVER… in my opinion the preferred way to install and configure Tahoe-LAFS is with my
Ansible role: https://github.com/david415/ansible-tahoe-lafs
I will soon soon create and test an ansible playbook for installing and configuring Tahoe-LAFS
on TAILS.

Note #2: this is NOT a generic bash bootstrap script for Tahoe-LAFS… it is in fact
a modified version of an associate’s bootstrap script for use with an onion grid
(a Tahoe-LAFS grid which is only accessible via Tor Hidden Services). It configures
your tahoe client to connect to a specific onion grid introducer.

procedure:
0. in TAILS you must first do a “apt-get update” before running this script.
1. when executing this script you tell it which directory to install the tahoe-lafs
and tahoe-lafs client directory.
3. this bash script created a symlink from ~/.tahoe to the directory in my persistent fs
where i chose to have the tahoe-client directory installed; I made a copy of this
symlink to my persistent dotfiles directory.
4. start tahoe… something like this: usewithtor path-to-tahoe-lafs/bin/tahoe start ~/.tahoe
5. create a tahoe root capability if you don’t already have one

I was able to put and get files from the onion grid. Easy!
Next time I reboot TAILS I do this:
0. enable persistent volume
1. start tahoe

After that I can easily put and get files from the onion grid again.

Say for instance, I had some huge files on my laptop’s harddrive… I could do this:
1. boot into tails
2. mount the storage disk (the one with the big ass files)
3. connect to the onion grid
4. upload file(s) to onion grid

Easy! I believe that’s the use-case Zooko was talking about.
I could then share the read-only or read-write capabilities to these files.

Furthermore… using the Tahoe-LAFS rpg we can easily create a “Tor Hidden Service web gateway” to
grid files; think of “big ass onion URLs with crypto capabilities in them”.

Here I have another slightly different use of TAILS + Tahoe-LAFS:

There could be an onion-grid-backup-daemon running which watches (via linux’s inotify)
my “onion-grid-backup” directory in my persistent volume…
All of it’s contents get automatically backed up to the onion grid
every 10 minutes if anything was changed.

There could even be some sort of TAILS GUI for it that let’s the user do an on-demand backup…
or let’s the user know when the “onion-grid-backup” dir has changed but isn’t yet synced to the onion grid.

Please please let me know what I have to do next to this ticket moving forward.
Onward!

#41 Updated by dawuud 2014-05-29 16:12:07

I need to retract my previous mistaken statement:
The preferred way to install Tahoe-LAFS is with the debian package. Obviously.

For testing I use the bootstrap.sh or my Tahoe-LAFS Ansible role to install a feature branch.
I don’t advise others to do this… unless you want to.

Tahoe-LAFS + Tails integration could involve feature additions to the Tails wizard
and a periodic tahoe back daemon + gui applet. This will make it easy for Tails users to use Tahoe.

#43 Updated by intrigeri 2014-06-06 12:31:36

(Being discussed on tails-dev.)

#44 Updated by Dr_Whax 2014-07-16 15:16:26

dawuud wrote:
> Tahoe-LAFS + Tails integration could involve feature additions to the Tails wizard
> and a periodic tahoe back daemon + gui applet. This will make it easy for Tails users to use Tahoe.

Perhaps so we should make this into a seperate ticket and keep this ticket as the master ticket?

#45 Updated by dawuud 2014-07-19 20:57:18

note that Tahoe-LAFS works fine on Tails 1.1~rc1…
simply: apt-get update && apt-get install tahoe-lafs

#46 Updated by broncospasm 2014-09-20 22:51:20

This could be a good option for users who can’t boot from USB; please see Feature #5561.

#49 Updated by Anonymous 2018-01-18 16:30:38

Short description of Tahoe: “Tahoe-LAFS is a system that helps you to store files. You run a client program on your computer, which talks to one or more storage servers on other computers. When you tell your client to store a file, it will encrypt that file, encode it into multiple pieces, then spread those pieces out among multiple servers. The pieces are all encrypted and protected against modifications. Later, when you ask your client to retrieve the file, it will find the necessary pieces, make sure they haven’t been corrupted, reassemble them, and decrypt the result.”

It’s now available in Debian.

However it remains unclear how useful this is to average users who have to set up / find /use Tahoe servers somehow. There does not seem to be a GUI.