Project

General

Profile

Feature #6227

Persistence preset: Tahoe

Added by ioerror over 6 years ago. Updated almost 2 years ago.

Status:
Confirmed
Priority:
Normal
Assignee:
-
Category:
Persistence
Target version:
-
Start date:
03/23/2015
Due date:
% Done:

0%

Feature Branch:
Type of work:
Code
Blueprint:
Starter:
No
Affected tool:

Description

If /home/amnesia/.tahoe is added to live-persistence.conf, it is possible to store all Tahoe related data in Tails - this is very useful.

What needs to happen to have this added as open persistence choice by default?


Related issues

Blocked by Tails - Feature #6015: Tails based on Wheezy Resolved 07/28/2013
Blocked by Tails - Bug #9101: Consider integrating Tahoe-lafs and `magic folders` into Tails Confirmed 03/23/2015

History

#1 Updated by intrigeri over 6 years ago

  • Tracker changed from Bug to Feature

#2 Updated by intrigeri over 6 years ago

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?

#3 Updated by intrigeri over 6 years ago

  • Assignee set to ioerror
  • QA Check set to Info Needed

Ping?

#4 Updated by intrigeri about 6 years ago

  • Priority changed from Normal to Low

Lacks info, nobody actively working on it apparently => downgrading to low priority.

#5 Updated by zooko about 6 years ago

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 about 6 years ago

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 about 6 years ago

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 about 6 years ago

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 about 6 years ago

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 about 6 years ago

  • 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 about 6 years ago

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 about 6 years ago

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…

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 about 6 years ago

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 about 6 years ago

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 #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 about 6 years ago

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 almost 6 years ago

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

#18 Updated by BitingBird over 5 years ago

  • Status changed from New to In Progress

#19 Updated by intrigeri over 5 years ago

  • Status changed from In Progress to New

The "New" status indicates that it is still unclear what this ticket is about, so we can't yet know if we can / want to do it. (Sure, there's been progress on the "make it possible to install Tahoe in Tails" front, but that's not what this ticket is primarily about.)

#20 Updated by zooko over 5 years ago

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.

#21 Updated by intrigeri over 5 years ago

  • Status changed from New to Confirmed
  • Assignee deleted (ioerror)

zooko wrote:

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.

Thanks a lot for the analysis, now it's clearer to me what the benefits would be.

Implementation-wise, once the software can easily be installed in Tails, what directory (or set of directories) need to be made (optionally) persistent to use this? (Jacob suggested ~/.tahoe/, but my understanding is that the Debian package also puts stuff in /var/lib, so I'm not sure.)

#22 Updated by intrigeri over 5 years ago

#23 Updated by intrigeri over 5 years ago

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 over 5 years ago

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 over 5 years ago

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 over 5 years ago

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 over 5 years ago

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 over 5 years ago

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 over 5 years ago

intrigeri wrote:

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 over 5 years ago

I would like to be a co-maintainer.

Sounds great!

#31 Updated by vu3rdd over 5 years ago

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 over 5 years ago

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 over 5 years ago

Great news, congrats!

[...] the new Tahoe-LAFS maintainer, <> [...]

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 over 5 years ago

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 over 5 years ago

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 over 5 years ago

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:

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 over 5 years ago

Oops, I mean four Debian tickets.

#38 Updated by intrigeri over 5 years ago

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 :)

#40 Updated by dawuud over 5 years ago

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 over 5 years ago

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.

#42 Updated by BitingBird over 5 years ago

  • QA Check changed from Info Needed to Dev Needed

#43 Updated by intrigeri over 5 years ago

(Being discussed on tails-dev.)

#44 Updated by Dr_Whax over 5 years ago

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 over 5 years ago

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

#46 Updated by broncospasm about 5 years ago

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

#47 Updated by BitingBird almost 5 years ago

  • Category set to Persistence

#48 Updated by BitingBird over 4 years ago

  • Subject changed from Add Tahoe as persistence option to Persistence preset: Tahoe

#49 Updated by u almost 2 years ago

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.

#50 Updated by u almost 2 years ago

  • Related to Bug #9101: Consider integrating Tahoe-lafs and `magic folders` into Tails added

#51 Updated by u over 1 year ago

  • Related to deleted (Bug #9101: Consider integrating Tahoe-lafs and `magic folders` into Tails)

#52 Updated by u over 1 year ago

  • Blocked by Bug #9101: Consider integrating Tahoe-lafs and `magic folders` into Tails added

Also available in: Atom PDF