Re: [Tails-dev] [tails-dev] [PATCH] Add minimodem package

[segfault]

Hi,

Roman Zeyde:

Adding `minimodem` [1] would allow air-gapped communication between Tails and 
other machines.


That sounds like a very special use case to me. But you can install 
minimodem via the Additional Software: 
https://tails.boum.org/doc/persistent_storage/additional_software/index.en.html


Cheers
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Tor Browser 12.0.6 Candidate Builds Available

[segfault]

[sending again because I replied to the tails-dev list only]

Hi,

Richard Pospesel:

Tor Browser 12.0.7 release candidate builds are now available for testing:

-  
https://tb-build-05.torproject.org/~ma1/builds/release/unsigned/12.0.6-build1/


Thanks for letting us know!

There is currently no detached signature for
sha256sums-unsigned-build.txt in that directory. Will you still add that?

Cheers
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Tor Browser 12.0.6 Candidate Builds Available

[segfault]

Hi,

Richard Pospesel:

Tor Browser 12.0.7 release candidate builds are now available for testing:

-  
https://tb-build-05.torproject.org/~ma1/builds/release/unsigned/12.0.6-build1/


Thanks for letting us know!

There is currently no detached signature for 
sha256sums-unsigned-build.txt in that directory. Will you still add that?


Cheers
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Results from usability tests of the new Persistent Storage in Ecuador

[segfault]

Hi,

sajolida:

In March, emmapeel traveled to Ecuador and conducted moderated in-person
usability tests of the new Persistent Storage.

https://gitlab.tails.boum.org/tails/tails/-/issues/18648

She recruited 4 women from feminist groups who had an interest in
privacy technologies but never used Tails before.

I prepared the tasks and testing image beforehand and trained her on
doing usability tests, as I couldn't travel myself this time. That's why
the tests were shorter and the tasks more basic.

We asked them to:

- Save an image to the USB stick in a way that protects it if their USB
stick gets stolen.
- Configure Tails to connect to a Wi-Fi network automatically.

See the stepped tasks here:

https://gitlab.tails.boum.org/tails/ux/-/raw/master/persistent%20storage/tasks-software-2023.odt?inline=false

I already tested similar tasks in Brazil in August and in other
occasions in the past.

The results were very good and emmapeel did a great job on her first
facilitation :)


Great stuff, thanks a lot both of you! I'm very happy to see that our 
work has actually led to a better user experience :)



- Saving an image from Tor Browser is still a nightmare.

Nobody made it. That's #15678 and related issues. I'm worried to see
that the situation hasn't improved for our users since 2018 and will
push for more action on this front in 2023.


That's more motivation for me to tackle #19408 ("Use desktop portals in 
Tor Browser") in the next few weeks.



- The concept of the Persistent folder, as part of the Persistent
Storage, was not always super clear. All the new issues identified had
to do with this:

* #19642: Implement missing descriptions of PS features
* #19645: Add a placeholder file in the Persistent folder
* #19646: Persistent folder should not appear as an external device


Thanks for identifying those issues! Maybe we should rethink the concept 
of the Persistent Folder and how we present it to the user. I would be 
open for a brainstorming session on that. A random thought: Maybe it 
would improve UX to support making the user directories (Documents, 
Pictures, Downloads, ...) persistent instead of a separate Persistent 
Folder (related issues I could find: #19255, #15028, #10790).


Cheers
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Proposal: Add support for curl (does ALL_PROXY fix it?)

[segfault]

David A. Wheeler:

You might want to try `torsocks --isolate curl` (I didn't test it but that's 
often enough to make any program use Tor).


Currently torsocks is never mentioned in the Tails user documentation,
so a typical Tails user has a good chance of not knowing about it. (yes, 
torsocks *is*
mentioned in the design docs, but that doesn't count as *user* documentation 
:-) ).
So: No matter what, documenting that "additional programs"
might need to use torsocks (and how to use it) would be a good idea.


I agree that it might be useful to document in the Additional Software 
docs that some applications need to be run via torsocks. I'll let our UX 
and documentation person decide on that.



However, in the case of *curl*, using torsocks has drawbacks.
The torsocks program uses the LD_PRELOAD trick that is
sometimes unreliable


I'm not aware of torsocks being unreliable. It's used in Tails for many 
applications and I use it myself for others and in my experience when it 
works once it works every time.

___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Proposal: Add support for curl (does ALL_PROXY fix it?)

[segfault]

Hi,

David A. Wheeler:



On Feb 4, 2023, at 2:18 PM, David A. Wheeler  wrote:

Currently Tails includes and supports wget. I propose *also* adding support for 
curl.


Replying to myself, I think there's a slightly better way to automatically 
support curl.
I previously proposed setting the "ALL_PROXY" environment variable, but the best
setting for curl using ALL_PROXY uses prefixes that might confuse other tools
that might *also* read from ALL_PROXY.

So instead I propose this, to make Tails automatically support curl, while not
interfering with any other program.


You might want to try `torsocks --isolate curl` (I didn't test it but 
that's often enough to make any program use Tor).


You can also make Tails install curl automatically via the Additional 
Software feature.


Cheers
segfault
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Rewrite live-persist as part of Persistent Storage settings rewrite

[segfault]

Topi Toosi:

Hi,


As a user I would be slightly worried if a user level script would be 
able to silently activate and start using persistence features I 
specifically have not enabled.


Currently there is some assurance that data related to one Tails session 
will not be written to the persistent storage if the storage is not 
mounted at bootup.


Will there be a way to ensure that the backend is unable to perform 
these steps without user interaction?


We will ensure that only the Persistent Storage frontend can access the 
backend, not any other applications started by the amnesia user.

___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] Rewrite live-persist as part of Persistent Storage settings rewrite

[segfault]

Hey,

as part of the rewrite of the Persistent Storage settings (#17803), I 
also want to solve #11529 "Save data to Persistence when it is created 
(no need to restart)".
The only way I see to solve this while providing a nice UX is to rewrite 
part of live-persist (and the live-boot functions uses by it) to allow
activating/deactivating a single persistence feature (that's the term we 
want to use instead of "persistence preset" IIUC).


This is the user flow I envision:
* In the Persistent Storage settings GUI, the user clicks on the switch
  of a  persistence feature to  activate/deactivate it.
* The frontend calls the Activate()/Deactivate() method of the feature's
  D-Bus object.
* The backend checks if any processes are running that must not be
  running when changing this feature (for example for the Thunderbird
  persistence feature, no process with executable "/usr/bin/thunderbird"
  or "/usr/lib/thunderbird/thunderbird" must be running).
  * If any such process is running, the backend sends a signal that it's
waiting for these processes to exit.
  * The frontend receives the signal and displays a message to the user
that they have to close the corresponding app ("Thunderbird") to
continue.
  * Once all conflicting processes have exited, the backend
automatically continues activating/deactivating the feature.
* The backend mounts/unmounts the files/directories of that feature.
* The backend adds/removes the corresponding line(s) to/from
  persistence.conf.

live-persist is not able to mount/unmount a a single file/directory 
instead of the whole persistence.conf. That's why we need to rewrite 
part of it.


I plan to do that in bash, copying the parts from live-persist and 
live-boot which we need for that.


During boot, we could still use live-persist, or we completely replace 
it with the new script (which means that it should also be able to 
activate features from a config file).


What do you think about that plan?

Cheers
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] overwriting with random data

[segfault]

Hi,

kirg...@riseup.net:
> Why does Tails default to overwriting with random data (instead of ones
> and zeros) ? When erasing files.

I'm not sure, but what issue do you see with the current behavior?

Cheers
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [review'n'merge] another typo

[segfault]

emma peel:
> ey there, a user reported this typo, please merge if you fancy:
> 
> https://git-tails.immerda.ch/emmapeel/tails/commit/?h=another_typo=60829a0ad8a5c1f597b0f99255191dcde08c1736
> 
> thanks, and thanks to the user that reported.

Merged, thanks!
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [Tails-project] Do you read the changelog?

[segfault]

anonym:
> As release managers, one of the things we produce is the changelog
(i.e. debian/changelog; we are *not* talking about the release notes).
We have the following questions for you, potential users of this file:
>
>  - Do you read the changelog at all?

To be honest, no, I don't remember ever reading it.
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Reddit Account

[segfault]

thenerdyanarchist--- via Tails-dev:
> I had asked in the XMPP chat, but just figured I'd send a message here to
> cover all bases.  Did anyone from the team create an account named
> Tails_OS on Reddit yesterday at around 18:00 UTC?
> 
> Since I haven't found any evidence that it's anyone from the team, I
> assigned a flair to the user in the Tails subreddit that clarifies that it
> is *not* associated with Tails in any official capacity.  I don't want
> other Reddit users in the sub thinking that advice coming from the account
> is some kind of "official" word from the Tails team.

Seems reasonable, thanks!
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Bugfix permission request

[segfault]

intrigeri:
>>> I would like to request permission to edit the redmine ticket, as 
>>> instructed in step 2 of the merge policy.
> 
>> Please just go ahead: Create an account on http://redmine.tails.boum.org
>> and assign the ticket to yourself. If you think you're done with the
>> implementation and tested that it works, set the ticket fields according
>> to the merge policy (Status -> Needs Validation, Assignee -> empty).
> 
> Since then, touss created themselves a Redmine account, and I give
> them "Contributor" status, so they can do what segfault described
> above (only project members can edit ticket medatada).

Oh, thanks, I didn't know that.
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Bugfix permission request

[segfault]

Hi,

> I've been meaning to contribute to Tais since i went to the 2017 Cryptorave 
> at Sao Paulo, and finally now i had some time to start. I  implemented a 
> bugfix to bug  15102  wich can be found at my branch at Salsa:
> https://salsa.debian.org/touss-guest/persistence-setup/tree/bugfix/15102-have-a-show-passphrase-option-when-creating-persistence
>  
> 

Thanks for working on this!

> I would like to request permission to edit the redmine ticket, as instructed 
> in step 2 of the merge policy.

Please just go ahead: Create an account on http://redmine.tails.boum.org
and assign the ticket to yourself. If you think you're done with the
implementation and tested that it works, set the ticket fields according
to the merge policy (Status -> Needs Validation, Assignee -> empty).

Feel free to ask here, on the ticket or in the tails-dev XMPP channel if
you have any questions.

Cheers
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [Tails-ux] Working group to define the "core Tails system" (#16531)

[segfault]

u:
>>> 2. Gather initial input from everyone (not just members of the
>>>working group)
>>
>>>→ Feel free to send me, by the end of July, a list of statements
>>>such as "I think feature X / application Y should be part of the
>>>core Tails system because $REASONS" or the opposite.
>>
>>>While doing so, please consider taking our personas into account
>>>since that's the closest thing we have at the moment to
>>>collectively defined priorities:
>>>https://tails.boum.org/contribute/personas/
>>
>>>I will collect this input. It will help the working group take into
>>>account diverse point of views right from the beginning.
>>
>> Same here: you now have until mid-September to share such input.
> 
> I did not reply previously because I felt like I did not have time to
> prepare a list of statements.

Same.

> 
> I would also like to suggest to also gather input during a short online
> meeting, on top of asking people to provide it by email. I believe this
> will be more efficient.

Same.

Cheers
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [Tails-ux] Working group to define the "core Tails system" (#16531)

[segfault]

u:
>>> 2. Gather initial input from everyone (not just members of the
>>>working group)
>>
>>>→ Feel free to send me, by the end of July, a list of statements
>>>such as "I think feature X / application Y should be part of the
>>>core Tails system because $REASONS" or the opposite.
>>
>>>While doing so, please consider taking our personas into account
>>>since that's the closest thing we have at the moment to
>>>collectively defined priorities:
>>>https://tails.boum.org/contribute/personas/
>>
>>>I will collect this input. It will help the working group take into
>>>account diverse point of views right from the beginning.
>>
>> Same here: you now have until mid-September to share such input.
> 
> I did not reply previously because I felt like I did not have time to
> prepare a list of statements.

Same.

> 
> I would also like to suggest to also gather input during a short online
> meeting, on top of asking people to provide it by email. I believe this
> will be more efficient.

Same.

Cheers
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [review'n'merge] typo on unlock_veracrypt_volumes

[segfault]

u:
> Hi!
> 
> On 29.04.19 18:21, intrigeri wrote:
>> sajolida:
>>> I've seen no answer to your email on tails-dev.
>>
>>> Foundations Team, should this be part of your mission? as per:
>>> « reviewing code contributions that are on nobody else's plate [...] »
>>
>> It definitely is part of our job. segfault asked me for guidance
>> a couple weeks ago wrt. how to handle this and I replies. I suspect
>> this fell through the cracks since. segfault, are you still on it?

Yes, it fell through the cracks, and yes, I'm on it.

>> (As we can see, email is slightly suboptimal to track such things.)
> 
> Maybe emmapeel can create a ticket on Redmine?

I created one now: https://redmine.tails.boum.org/code/issues/16696

Cheers
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Proposal: Redmine workflow change

[segfault]

Hi,

intrigeri:
> anonym:
>> intrigeri:
>>> Given we now have "mentions" (@nickname) on our Redmine, for the
>>> majority of cases, when the requested info can presumably be provided
>>> cheaply and quickly, I think we should use mentions and not reassign
>>> the ticket. And when I'm mentioned, if I realize that providing the
>>> requested info needs will take me great amounts of work, I should
>>> do whatever works for me to track this work, be it on a new ticket
>>> or my personal offline organization tools.
> 
>> I quite like this feature and have set up filter rules in my email
>> client for the resulting redmine notifications I receive so I don't
>> miss them. However, I wonder how this works out if you don't do
>> something like that. I also fear that the ad hoc tracking of
>> "mentions" that you propose above is easy to forget.
> 
> I think most of us are in one of these 4 situations:
> 
>  - They notice and track new incoming emails but don't pay much
>attention to tickets reassigned to them on Redmine (note that
>Redmine sends no notification to the new assignee).
> 
>Mentions help. Reassigning does not help (I've seen quite a few
>cases recently where it appears that the new assignee had no idea
>something was expected from them).
> 
>So dropping "Info Needed" is a no-op.

I fall into this category, *but* I think the "Info Needed" field is
still sometimes useful for me. While I at least take notice of all my
Redmine emails, I sometimes get a lot of them (because I also watch some
tickets which are not on my plate, but for which I would like to stay
up-to-date about the progress). And my tracking is not the best, I
sometimes forget to star an email that requires action by me. In this
case it does help if a ticket is assigned to me so that I see it when I
check my assigned tickets on Redmine (which I do rarely, but still).

But I also see that losing track of ones issue by assigning someone for
"Info Needed" is a problem. It would be nice if Redmine would support
multiple assignees for issues, which GitLab does support.

All in all I'm okay with trying to drop the "Info Needed" field and see
how it works out.

Cheers
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] TAILS amd64 3.13 boot issue

[segfault]

Hi,

Ron HulduNet - GM:
> amd64 3.13
> 
> Lenovo Thinkpad X200 Tablet
> 
> Sandisk 16GB
> 
> 
> Starts booting then stops at
> BusyBox <...>
> 
> (initramfs) Unable to find a medium containing a live file system

how did you install Tails? Did you use the .iso or the .img? And did
Tails fail to boot every time or did it work the first time?

Cheers
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Security implications: moving code from Verification Extension to our website

[segfault]

sajolida:
> u:
>> We know from Javascript statistics of our download page that roughly
>> ~20% of the downloads of Tails images are verified by users using the
>> verification extension. The optional OpenPGP verification accounts for
>> 9% of downloads (computed using the number of downloads of the OpenPGP
>> signature). This means that >70% of Tails downloads might currently not
>> be verified at all.

What about the downloads via bittorrent? There the OpenPGP signature is
bundled with the image, so we can't really tell how many of the
bittorrent downloads are additionally verified via the signature.
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Tails vs Electrum

[segfault]

Hi,

s7r:
> Or, if there are any downsides that prevent us from using the AppImage,
> (I hope there won't be any as it seams our easiest move here), 

There is at least one downside: the Electrum AppImage is 86 MiB, whereas
the Electrum Debian package and it's dependencies which we could remove
from Tails sum up to 1.3 MiB:

  total 1.3M
  723K Aug 15  2018 python3-electrum_3.1.3-1~bpo9+1_all.deb
  286K Nov 26  2016 python3-protobuf_3.0.0-9_amd64.deb
  100K Dec 24 20:43 python3-dnspython_1.15.0-1+deb9u1_all.deb
   35K Apr 25  2015 python3-ecdsa_0.13-2_all.deb
   32K Jan 13  2018 python3-jsonrpclib-pelix_0.3.1-1~bpo9+1_all.deb
   28K Aug 15  2018 electrum_3.1.3-1~bpo9+1_all.deb
   26K Aug 27  2016 python3-qrcode_5.3-1_all.deb
   16K Jan 13  2018 python3-pyaes_1.6.1-1~bpo9+1_all.deb
  6.5K Jul  5  2013 python3-pbkdf2_1.3+20110613.git2a0fb15~ds0-3_all.deb

Those are the packages which would be removed by running `apt remove
electrum`:

  The following packages were automatically installed and are no longer
required:
  python3-dnspython python3-ecdsa python3-electrum
python3-jsonrpclib-pelix python3-pbkdf2 python3-protobuf python3-pyaes
python3-qrcode

> we can
> always sponsor the maintenance upstream (Debian level).

I think this is the better option.

Cheers
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Tails vs Electrum

[segfault]

Hi,

sajolida:
> Summary of the situation
> 
> [...]

Thanks a lot for the comprehensive summary!

This sounds like a serious issue. I share your concern regarding losing
users (and good donors). So I think we should avoid removing Electrum
without at least documenting a workaround.

I would be willing to spend some hours on helping with this. I could
start with looking into whether it's feasible to ship the AppImage.

Other ideas: Could one of our Debian Maintainers sponsor a Electrum
3.3.2 upload? Or could we package and upload it to our own repositories
until it's updated in Debian?

Cheers
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Buggy boot

[segfault]

Hi,

thanks for the report.

bradley--- via Tails-dev:
> Hey,
> 
> Thanks for all the work you put into Tails. It is an amazing system and I
> find it very useful.
> 
> I would like to report one issue however. Every second time I boot Tails,
> it fails. It either displays some errors in the command line booting
> screen or the letters on the normal booting screen are not readable and I
> need to restart anyway.

What do you mean with every second time? Does it boot again when you
reboot after it failed to boot? Or does it not boot anymore at all after
the first boot? Because the latter is a known bug which still affects a
few users and which we are currently trying to debug.

> If what I am writing about does not ring a bell, I can try to elaborte a
> little more.

Yes, please describe what exactly you see. Does it just say "Unable to
find a medium containing a live file system", or something else?

Also, did you install your Tails via the new USB Image (the ".img" file)
or via the ISO, or is it an old installation which you upgraded?

Cheers
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Reusing the VeraCrypt icon for a custom mounter in Tails

[segfault]

Hi!

VeraCrypt Team:
> We have no problem with you reusing VeraCrypt logo in Tails. The logo
> itself is licensed under Apache License 2.0. I don't know if this can
> help integrate it into Tails. In case of problem, we can make
> exceptions for you.

That's great! But after some more discussions, we see some more license
problems, which we hope you can help us with:

 * We would like the custom mounter application we created to have
   "VeraCrypt" in it's name, so that it will be easier for our users
   to find it in the menus. Our working title is "VeraCrypt Mounter".
   But we found that the VeraCrypt license states:

   "This license does not grant you rights to use any contributors'
   name, logo, or trademarks, including IDRIX, VeraCrypt and all
   derivative names."

   So we would like to ask you if you could give us permission to use
   "VeraCrypt" in the application name.

 * We were thinking about creating a Debian package for the custom
   mounter application, and trying to get it into the Debian
   repositories. We don't know yet if this will work, because it has to
   be compliant with the Debian Free Software Guidelines [1], but if you
   are in favor of this, we could try it if you give us permission along
   the lines of:

   "We allow the software "VeraCrypt Mounter" and all derivatives to use
   the name "VeraCrypt" in its name and the VeraCrypt logo in its logo."

   [1] https://www.debian.org/social_contract#guidelines

 * Note: This point is only relevant if we can't create Debian packages.

   You gave us permission to use the VeraCrypt logo in the icon of the
   custom mounter application that we want to ship in Tails. But
   derivatives of Tails currently don't have this permission, so they
   have only the permissions granted by the VeraCrypt license, which
   does not allow the use of the logo. We don't want to make life hard
   for Tails derivatives, so it would help if you could grant the same
   permission to Tails derivatives (same applies to the use of
   "VeraCrypt" in the application name).

Thanks in advance!

Cheers

___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] installing a package with double click

[segfault]

hi,

emma peel:
> as now we are having so many possibilities with the new Additional Software 
> feature coming, with some friends we are working on some apps that can be 
> used in Tails.
> 
> We have a nice .deb package for newbie users to be able to install a small 
> catalogue of tools, but  we dont fin a way to bootstrap it nicely.
> 
> Would it be possible to install, for example, gdebi, so users can
> 
> - double-click on a .deb file on Nautilus
> - get asked the admin password
> - install the debian package
> 
> it is quite straighforward once you have installed it.
> 
> or maybe there is a way to add a MIME type for Nautilus that will trigger 
> some fancy thing?
I'm not sure if we should make it easy for users to install software
from untrusted sources.



signature.asc
Description: OpenPGP digital signature
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] VeraCrypt support in GNOME

[segfault]

Hi,

first a quick status update: the project to add VeraCrypt support to
GNOME made good progress in the last months. Our work on Disks, glib,
GVfs, and partly GTK+, was merged already:

  https://gitlab.gnome.org/GNOME/gnome-disk-utility/issues/84
  https://gitlab.gnome.org/GNOME/glib/merge_requests/120
  https://gitlab.gnome.org/GNOME/gvfs/merge_requests/4/
  https://gitlab.gnome.org/GNOME/gtk/merge_requests/260

The remaining important merge requests are:

  https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/126
  https://gitlab.gnome.org/GNOME/gtk/merge_requests/200
  https://gitlab.gnome.org/GNOME/gtk/merge_requests/244

We hope that these can be merged in time for the GTK+ 3.24 / GNOME Shell
3.30 releases. Given the feature freeze will happen soon, time is pressing.

Our main concern is the GNOME Shell merge request
(https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/126), which
seems to be stalled, possibly due to holiday or higher priority work,
which is why we're hereby reaching out to the broader GNOME development
community, in the hope that someone has time to look into it :)

We are also concerned about the merge request for including interesting
device mapper devices and loop devices in the GTK places sidebar
(https://gitlab.gnome.org/GNOME/gtk/merge_requests/200), which was
rejected. The purpose of this merge request is to include encrypted file
containers in the sidebar. Based on our user survey, file containers are
very common among VeraCrypt users (used by 76% of Tails+VeraCrypt users):

  https://tails.boum.org/blueprint/veracrypt/#survey

We did not get an explanation for the rejection, except that there
should be no special-casing of these devices in GTK+. So a couple weeks
ago, we asked for a clarification and we explained that we don't think
that this would qualify as special-casing, given these volumes are
already listed by the GVfs volume monitor:

  https://gitlab.gnome.org/GNOME/gtk/merge_requests/200#note_261361

The volume monitor documentation explicitly states that it lists devices
and volumes interesting for the user, i.e. "what a file selector or file
manager would show in a sidebar". In our tests, the only volumes that
were added to the sidebar by our patches were encrypted volumes
(excluding those on internal drives).

We would appreciate  to get a comment on this, because we see this as an
essential feature for the usability of the VeraCrypt support in GNOME.
Thanks a lot in advance!

Cheers
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] DeepOnion project

[segfault]

Hi,

Vaas !:
> We are glad to let your Team know that we were working on the Debian
> Repository in the last months with our Development Team and we did a lot of
> progress on it. We took your words about doing something first as a way to
> earn the trust from your members and who that we want to help and build
> something for the good of all with real commitment.

I don't see where anyone said anything like that. I suspect there is a
misunderstanding. When intrigeri was using the word "trust" in his
reply, he said that including your software in Debian's own
repositories, instead of a repository hosted by you, requires less trust
of *users* towards your project (when they decide themselves to install
your software in Tails).

> Right now we are even looking for a mentor for Debian (I don't know if some
> people from your Team can help us with this) but all the hard work seems to
> be done and we are on the testing phase.

See here for information on how to find a mentor who could upload your
package to the Debian repositories:

https://mentors.debian.net

> We would like to know if one of your Team would like to Talk with us on
> Wire, we can set a meeting with our Developers for testing purposes

I don't see the point of setting up such a meeting with you. You are
working on making your software available to Debian users (which
includes Tails users). If you need help with that, I'd suggest you try
to find a Debian mentor (see above).

Cheers
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] How to use a non-standard persistent volume?

[segfault]

gaff-tails:
> Is there a way I can create and mount a persistent volume that isn't
on a USB stick? I understand that this comes with security risks - My
main aim here is develop and test tails features using virtual box or
similar.

For testing purposes, you can also use this tool to create a disk image
from a Tails ISO. You can boot the resulting image via
libvirt/virt-manager and create a persistent partition on it:

https://gitlab.com/segfault3/tails-usb-image-from-iso

Cheers
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] VeraCrypt/TrueCrypt support in GNOME Disks

[segfault]

Hi,

segfault:
> We are currently working on the patches for the unlock dialog in Disks.
> This will probably be finished soon. The resulting UI is much more
> complex than in the LUKS case, but this simply reflects the more complex
> needs of VeraCrypt users.

the Disks patches are ready now, they can be found in the support-tcrypt
branch at https://github.com/segfault3/gnome-disk-utility.

This branch requires udisks and libblockdev with TCRYPT support, which
can be found in the support-tcrypt and add_veracrypt branches at:
https://github.com/segfault3/udisks
https://github.com/segfault3/libblockdev

This extends the unlock dialog by widgets which allow specifying the
parameters supported by TrueCrypt and VeraCrypt volumes. This includes:

 - Whether the volume to be unlocked is hidden.
 - Whether the volume to be unlocked is a system partition.
   Note: TrueCrypt and VeraCrypt only support encrypting Windows system
   partitions [1], so the label for this option is "Windows system".
 - Whether to use a PIM [2].
 - Whether to use one or multiple keyfiles. In the beginning there is
   only one button to choose a single keyfile. When a keyfile is chosen,
   another button appears below to allow selecting another keyfile, and
   so on.

To reduce the number of options displayed by default, the additional
options are hidden below an expander labeled "More options".

Since TCRYPT volumes cannot be reliably detected as such, a label is
displayed at the top of the unlock dialog to indicate to the user that
this volume might not actually be encrypted.

[1] https://www.veracrypt.fr/en/System%20Encryption.html
[2] https://www.veracrypt.fr/en/Header%20Key%20Derivation.html

Cheers!
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] VeraCrypt/TrueCrypt support in GNOME Disks

[segfault]

Hi,

segfault:
> Hi,
> 
> we at Tails (tails.boum.org) currently work on integrating support for
> unlocking VeraCrypt (and probably also TrueCrypt) volumes in Tails via
> udisks2 and GNOME Disks (and maybe also GNOME Files and the GVfs
> monitor). We internally track the status of this work in [1] and [2].
> Currently we are gathering data on the requirements of our users via a
> survey [3], in order to make decisions about which features we want to
> implement (support for legacy TrueCrypt volumes, file containers, hidden
> volumes, keyfiles).
> 
> We would like to know whether you want to have VeraCrypt/TrueCrypt
> support in upstream too. I assume that this is wanted in udisks2,
> because there is already an open ticket for this [4]. What about GNOME
> Disks?
> 
> [1] https://labs.riseup.net/code/issues/6337
> [2] https://labs.riseup.net/code/issues/11684
> [3] https://mailman.boum.org/pipermail/tails-ux/2017-October/003505.html
> [4] https://github.com/storaged-project/udisks/issues/282

Yesterday I opened pull requests for this in libblockdev [1] and udisks [2].

I mentioned previously that we were gathering data on the requirements
of our users. The results are available on our website [3]. We found
that all of the various VeraCrypt/TrueCrypt specific features, like
hidden volumes, system volumes, keyfiles, are used by a high ratio of
users, so we implemented all of them.

We are currently working on the patches for the unlock dialog in Disks.
This will probably be finished soon. The resulting UI is much more
complex than in the LUKS case, but this simply reflects the more complex
needs of VeraCrypt users.

We already designed the UI changes for creating VeraCrypt/TrueCrypt
volumes in Disks [4], but this will not be implemented before at least a
few weeks, because we chose to prioritize other work higher (backporting
the patches to the versions shipped in Tails / Debian Stretch, patching
the unlock dialog opened by the GVfs udisks2 volume monitor).

Cheers!

[1] https://github.com/storaged-project/libblockdev/pull/320
[2] https://github.com/storaged-project/udisks/pull/495
[3] https://tails.boum.org/blueprint/veracrypt/#survey
[4] https://tails.boum.org/blueprint/veracrypt/#ui
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Tails Server docker support

[segfault]

forgottenbeast:
> 
>> 1. The size of the docker images. The debian base image is > 100MB.
>> Downloading this would increase both the service installation time and
>> the requirements on the system's RAM.
> 
> This problem can easily be circumvented by using alpine based images:
> the alpine base image itself is around 4mb and many packages already
> exist for alpine based systems for this reason.

Ok, that's good to know. I was indeed able to find alpine-based docker
images for the use cases that are already implemented in Tails Server.

> For those that do not exist I agree that the whole repackaging process
> could be a pain AND involve a security risk (one would need to be able
> to audit the whole process and ascertain that the repackaged application
> has not been modified in any way)

Agreed.

>> 2. The lack of trustworthy sources. For many services there are "public"
>> images available, which, IIUC, can be created and maintained by anyone.
> 
> https://docs.docker.com/engine/security/trust/content_trust/#content-trust-operations-and-keys
> outlines the way the docker developers envisioned their image trust model.

So this allows verification of the image publisher, but my problem is
that I don't trust the image publishers.

> Since docker images uses a pretty standard key hierarchy scheme (offline
> root key and repository tagging keys to sign tags) it shouldn't be hard
> to verify the signatures of every image that is downloaded and only run
> those that have a verifiable chain of trust.
> 
> I can see two ways to do this:
> 
> 1. Trust everyone that sign and warn the user every time the certificate
> chain does not have a Tails signing key in it. Double warning (or demand
> a specific manipulation a la persistent packages) to run an unsigned image.>
> 2. Set up a linux tails registry containing audited and signed base
> images to build from as well as pre-built, audited and signed service
> images.

Both of these options would require us to create and maintain docker
images ourselves, which I don't want to do, because it is too much work.
So I prefer using the Debian packages instead.

Cheers

___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Tails Server docker support

[segfault]

Hi,

forgottenbeast:
> Greetings,
> I've been following the announcements about tails server and I would
> like to know if there are any plans regarding the support of docker
> containers?
> 
> The use case I am thinking about would be the ability to pull a docker
> image and run it as a hidden service.

I don't think this is a bad idea, and I also thought about using docker
for Tails Server before. I'm open for discussing it (and also other
isolation methods). The current plan is to simply install services via
Debian packages and monitor them using systemd. To reduce access to the
rest of the system the plan is to use apparmor profiles and systemd
security features.

With docker I see two main problems:

1. The size of the docker images. The debian base image is > 100MB.
Downloading this would increase both the service installation time and
the requirements on the system's RAM.

2. The lack of trustworthy sources. For many services there are "public"
images available, which, IIUC, can be created and maintained by anyone.

Cheers
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Release schedule for 2018

[segfault]

Hi,

intrigeri:
> Hi,
> 
> intrigeri:
>> FYI Mozilla has changed their 2018 release schedule. I'll update our
>> own calendar + Redmine, and will come back to this thread later.
> 
> Here we go (sorry for the noise, I didn't think I would do it
> immediately):
> 
>  * 2018-01-23: Release 3.4?  (Firefox 52.6, bugfix release)
>  * 2018-03-13: Release 3.5?  (Firefox 52.7, major release)
>  * 2018-05-08: Release 3.6?  (Firefox 52.8, bugfix release)
>  * 2018-07-03: Release 3.7?  (Firefox 59.2, major release)
>  * 2018-08-28: Release 3.8?  (Firefox 59.3, bugfix release)
>  * 2018-10-23: Release 3.9?  (Firefox 59.4, major release)
>  * 2018-11-27: Release 3.10? (Firefox 59.5, bugfix release)
> 
> Everyone affected, please check if/how this impacts your work.

works for me.

Cheers
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] VeraCrypt/TrueCrypt support in GNOME Disks

[segfault]

.. ink ..:
> On Tue, Nov 14, 2017 at 10:02 PM, segfault <segfa...@riseup.net> wrote:
> 
> 
>> We do not plan to support creating new TC/VC containers, and I didn't
>> even know that zulucrypt can do this (thanks for the hint!). I find the
>> idea tempting, maybe I will work on that at some point.
>>
> 
> zuluCrypt[0] uses zuluplay[1] to create and unlock TC/VC volumes and
> if you are to add support for creating
> TC/VC volumes then i think zuluplay will be a better dependency to have.

Thanks, I will look into this when/if I start working on support for
creating TC/VC volumes.

> While here,i think it is a bad idea to try to figure out if a volume
> is a TC/VC volume because there will be no point
> in using these over LUKS if a volume can reliably be guessed to be
> TC/VC. Best thing to do is to call blkid on the
> volume and assume it is encrypted if blkid fail to find a file system
> on it and the volume is not a swap partition.

I think there is no way to identify a swap partition as such (unless it
is currently enabled for swapping).

> Doing guess work here will just result in inconsistent behavior and a
> support nightmare.

I think the opposite is true. If we would use standard ways to identify
the filesystem type, we would have inconsistent behavior, because this
means checking for (small) magic numbers, often only two bytes. I
verified that modifying only two bytes in a TC volume made it appear as
a FAT volume in UDisks / GNOME Disks. So there is a non-negligible
chance that a TC/VC volume would be wrongly detected as
filesystem-formatted (i.e. greater than 1/2^16). In contrast, the
chi-squared test never identifies a filesystem header as random (I
forgot to note in my previous email that we calculate chi square only
over the first 512 bytes of the volume). There are still false
positives, but none that the blkid method wouldn't also have (i.e.
devices overwritten with random data, dmcrypt-plain volumes or loopAES
volumes).

Cheers!
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] VeraCrypt/TrueCrypt support in GNOME Disks

[segfault]

Vratislav Podzimek:
> On Tue, 2017-11-14 at 17:36 +0900, Kai Lüke wrote:
> [...]
>> * GNOME Disks and GIO/GVFs need to make use of the keyfiles parameter in
>> UDisks (currently lacking for LUKS as well) and a way to select a
>> keyfile from GNOME Shell is needed. One could also decide to explicitly
>> ignore them there and only offer unlocking via GNOME Disks.
> Correct me if I'm wrong, but key files in TC/VC are a little bit different
> concept than key files in LUKS where they are simply files containing the
> passphrase (binary) data.

This is correct, but it is also true that both LUKS and TC/VC keyfiles
are currently not supported by GNOME Disks and GVFs, which could be
fixed via the same UI patches.

>> Please give some feedback if this rough plan fits the needs. Not all can
>> be planned in advance but discussing things now raises the chances to
>> consider some corner cases before code lands.
>> The best is to open issues for each needed part in every involved
>> project, I will review the parts for GNOME Disks and also have time to
>> work on something from January/Feburary if needed.
> Sounds great to me otherwise. Thanks for working and willing to work on
> this, everybody!

Same!
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] VeraCrypt/TrueCrypt support in GNOME Disks

[segfault]

Vratislav Podzimek:
> On Mon, 2017-11-13 at 17:36 +0100, segfault wrote:
> [...]
>> I forgot to add: Assuming that you would like to have this in upstream,
>> some heads up for when it would be ideal for us if an upstream
>> maintainer was available for reviewing:
>> - We will evaluate the results of the survey and make design decisions
>> in December
>> - Patches will probably be ready in January
> Hi,
> as far as this is concerned I would say it doesn't really matter. The only
> thing related to this is that fact that the libblockdev patches need to
> land first so it would be nice if they came first.

Ok. I'm not sure if libblockdev patches are required at all, but if it
turns out they are, I will try to prepare them first.

Cheers!
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] VeraCrypt/TrueCrypt support in GNOME Disks

[segfault]

Hi,

thanks for the quick reply! I re-add the tails-dev mailinglist to Cc.

Kai Lüke:
> Seems I misunderstood while reading, so you already have code.

Correct. Sorry if I didn't make that clear enough. I will still answer
your previous email below. In case you already want to have a look at
the current status (which only supports basic unlocking/locking of
"standard" VeraCrypt/TrueCrypt volumes), the code lies in my forks of
the udisks and gnome-disk-utility repos [1][2] in branch "support-tcrypt".

[1] https://github.com/segfault3/udisks
[2] https://github.com/segfault3/gnome-disk-utility

> If your way of identifying encrypted partitions works good enough (which
> is funny because the partition is not really hidden then) you can ignore
> my sentences on presenting those device contents.

Standard TCRYPT volumes are not supposed to be hidden (in contrast to
the hidden volumes, of which we don't know yet if we want to support
them or not), they are only supposed to be indistinguishable from random
data. We identify TCRYPT candidates by performing a chi-squared test [3]
on each volume, which is a fast test for randomness. We had a discussion
about this here [4].

[3] https://en.wikipedia.org/wiki/Chi-squared_test
[4] https://mailman.boum.org/pipermail/tails-dev/2017-October/011754.html

> From the GNOME Disks point of view it would be good if things work
> mostly the same, e.g. UDisks.Block.CryptoBackingDevice and
> udisks_client_get_cleartext_block.

ACK, I did use the same interfaces that are used for LUKS. As a result,
besides renaming, I only had to modify 3 lines in GNOME Disks to
integrate unlocking and locking support for "standard" VeraCrypt and
TrueCrypt volumes.

> Am 14.11.2017 um 17:36 schrieb Kai Lüke:
>> Hello,
>>
>> of course there is more than one way to do it, but this is how I quickly
>> thought about this:
>>
>> * use the cryptsetup support for locking/unlocking in libblockdev and
>> make it work from the UDisks2.Encrypted interface

Yep, this is what I did.

>> * add the UDisks2.Encrypted interface in UDisks if the block device
>> content could not be identified

Also did that, except that I only add the UDisks2.Encrypted interface if
the device passes the chi-squared test, to have fewer false-positives.

>> * GNOME Disks needs some changes in terms of how to present such a
>> device in a different way from normal LUKS devices since for most people
>> the block device is indeed empty and it would be confusing to confront
>> everybody with failing decryption actions (maybe call the action
>> "attempt to unlock hidden volume")

Exactly, this is the problem of indicating to the user that the volume
*could* be a TCRYPT candidate, which I mentioned in my previous email.
I'm not sure how to best solve this. Currently I set the id_type
long_name to "Possibly Encrypted" and the short_name to "Encrypted?".
But we actually have a UX person in our team who will take a look at the
whole workflow after we evaluated the survey data and decided what
exactly we want to do.

>> * GNOME Disks and GIO/GVFs need to make use of the keyfiles parameter in
>> UDisks (currently lacking for LUKS as well) 

Right. To be sure I didn't miss anything: The only place in GIO/GVFs
which unlocks encrypted volumes is the gvfs-monitor, right?

>> and a way to select a keyfile from GNOME Shell is needed.

Yeah, I think this would be the hard part, because the GNOME Shell
password dialog doesn't allow other windows to be focussed, so I guess
we would have to patch that.

>> One could also decide to explicitly
>> ignore them there and only offer unlocking via GNOME Disks.

This is a decision which will be easier once we evaluted the survey
data, because we asked our users whether they use keyfiles.

>> This should give support for existing containers/partitions. I would
>> treat containers as normal filesystem images. When opened from nautilus
>> they are mounted read-only by default with gnome-disk-image-mounter →
>> need to expose writeable mount there.

If the survey evaluation shows that we should support file containers
(which I expect), then we will have to find a solution to allow the user
to unlock a container via Nautilus. UX-wise it would be best to
associate all file containers with the unlocking application (e.g.
gnome-disk-image-mounter), but this would require us to detect whether a
file is a TC/VC container. I don't think it would be a good idea to
perform the chi-squared test on every file encountered by Nautilus. An
easy solution would be to rely on the containers having the .tc/.hc
extensions. We will get data on this by the survey, but I'm in favor of
already thinking about alternatives.

I think it would be nice to be able to use gnome-disk-image-mounter in
order to trigger gvfs-udisks2-volume-monitor to unlock the "mounted"
(i.e. loop-device associated) image. But currently
gvfs-udisks2-volume-monitor does not attempt to unlock images which get
associated with loop-devices. Maybe we could change this. 

Re: [Tails-dev] VeraCrypt/TrueCrypt support in GNOME Disks

[segfault]

Hey,

thanks for the quick response!

Bastien Nocera:
> [...]
> What UI differences would be needed to handle those different types of
> encryption? I'm guessing none for handling encrypted disks, because the
> UI should be pretty much the same as for the existing LVM based
> encryption support.

Do you mean the LUKS encryption? In that case you would be correct, the
UI *should* be pretty much the same. But with VeraCrypt/TrueCrypt
encrypted volumes we have the difficulty that the volumes can not be
detected as such with absolute certainty, because, by design, they just
look like random data, and, in contrast to LUKS, have no cleartext
header. So we need to figure out a good way to indicate to our users
that a volume *could* be a VeraCrypt/TrueCrypt volume (because it looks
like random data).
There is also a possibility of confusion with dm-crypt plain and LoopAES
volumes, because those also look like random data. So we thought about
adding a dialog which lets the user specify the encryption type when
they want to unlock a (possibly) encrypted volume. We started discussing
implications of this on [1], and are currently leaning towards ignoring
dm-crypt plain and LoopAES and omitting an additional dialog.

[1] https://labs.riseup.net/code/issues/6337

> How to deal with creating encrypted volumes, and even more so when
> talking about other types of encryption would need to be designed after
> you've figured out whether it makes any difference to the user, and how
> it would get integrated in UDisks.

We do not intend to add support for *creating* encrypted volumes, but
only unlocking/locking.

> I'd start with adding a transparent way to mount encrypted disks and
> volumes in UDisks, and see whether anything else is needed on top of
> that for your users, including explaining why particular types of
> encryption are better than others and under which circumstances.

I agree that we should start with adding the support to UDisks (which I
already started doing).

> I'm also not sure what "file containers" and "keyfiles" are, but it
> sounds like filesystem level encryption which would likely live in GIO
> and UIs on top of it, not in Disks or UDisks.

File containers are not filesystem level encryption, but encrypted
volumes which are stored in a file on the filesystem instead of a block
device. They could be handled by UDisks/Disks by first mapping a loop
device to the file container (for example using udisksctl loop-setup,
gnome-disk-image-mounter or the "Attach Disk Image..." option in Disks).

If a VeraCrypt/TrueCrypt volume is configured to use keyfiles, all
configured keyfiles need to be added in addition to the password (if
any) in order to unlock the volume (similar to LUKS keyfiles, which are
supported by UDisks/Disks, except that those replace the passphrase).
This also has nothing to do with filesystem level encryption.

Cheers!
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] VeraCrypt/TrueCrypt support in GNOME Disks

[segfault]

Hi,

we at Tails (tails.boum.org) currently work on integrating support for
unlocking VeraCrypt (and probably also TrueCrypt) volumes in Tails via
udisks2 and GNOME Disks (and maybe also GNOME Files and the GVfs
monitor). We internally track the status of this work in [1] and [2].
Currently we are gathering data on the requirements of our users via a
survey [3], in order to make decisions about which features we want to
implement (support for legacy TrueCrypt volumes, file containers, hidden
volumes, keyfiles).

We would like to know whether you want to have VeraCrypt/TrueCrypt
support in upstream too. I assume that this is wanted in udisks2,
because there is already an open ticket for this [4]. What about GNOME
Disks?

[1] https://labs.riseup.net/code/issues/6337
[2] https://labs.riseup.net/code/issues/11684
[3] https://mailman.boum.org/pipermail/tails-ux/2017-October/003505.html
[4] https://github.com/storaged-project/udisks/issues/282

Cheers!
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] Logo broken on tails.boum.org/install

[segfault]

I just noticed that the logo looks broken on every page under
tails.boum.org/install/ (see attached screenshot).

I suspect that this has something to do with the "Removing the subtitle
in our logo" threat, maybe a test version was accidentally pushed to master?

Cheers!
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] TrueCrypt/VeraCrypt volumes undetectable

[segfault]

anonym:
> segfault:
>> Hi,
>>
>> so I started working on the project a few days ago and now I realize
>> that we might have a problem, because TC/VC volumes are undetectable.
>> Unlike LUKS encrypted volumes, TC/VC encrypted volumes don't have a
>> cleartext header. Instead, the TC/VC header is encrypted with the
>> passphrase / keyfile provided when unlocking it. This means that TC/VC
>> volumes are undistinguishable from random data.
> 
> There is a probabilistic algorithm for detecting TrueCrypt container *files* 
> since they exhibit certain characteristics [0]. It's not foolproof, and can 
> produce both false positives and false negatives, so it might not be suitable 
> at all, and I don't know if it identifies VeraCrypt volumes. Furthermore, I 
> believe one of the steps (chi-square distribution test [1]) is 
> computationally too heavy to run on each file encountered by GNOME Files. 
> [0] implemented by TCHunt: https://github.com/stephenjudge/TCHunt
> [1] and it's a bit ironic that the "pass chi-square distribution test"
is one of the things identifying a TC volume -- I suspect TC ensures its
volumes pass that test in order to "look random" (which the test more or
less is about) instead of "encrypted"... but few other header-less data
passes that test. :)

Even if it was not too computationally heavy, GNOME Files does currently
not automatically open and (partly) read every file it encounters (I
verified that using strace), and I don't think we should change that.

> However, it might be feasible for media scanning; this requires that the 
> algorithm can be re-adapted to identify TC partitions instead of container 
> files [2], and we'd only run the computationally heavy operation on a subset 
> of the disk data (e.g. the first megabyte of the device/partition), if that 
> doesn't break the algorithm. IMHO this is worth looking into, possibly also 
> asking the author for some tips.
> [2] for encrypted storage we have two cases: (1) the whole device is
TC encrypted, so there's no even a real partition table, and (2) there
is a partition table, and the TC volume is one of its partitions. For
neither of these cases I think the two criteria about file size can make
sense, but it deserves some thinking/experimenting.

I reimplemented the chi-square calculation (see attachment) in order to
test how long the calculation takes and which results it gives for TC/VC
devices and other kinds of devices. I only inspect the first 512 Bytes
of the device, because I expect this to usually either contain a
partition table or something like a filesystem superblock, which are
both not random. This is also works for LUKS encrypted devices, which
start with a LUKS header.

The results seem good. Some examples:

$ ./chi_square truecrypt_device
Chi square: 264.00
Execution time: 0.36

$ ./chi_square luks_device
chi square: 50663.00
execution time: 0.000127

$ ./chi_square ext4_device
chi square: 130560.00
execution time: 0.36

$ ./chi_square ntfs_device
chi square: 6864.00
execution time: 0.33

$ ./chi_square fat32_device
chi square: 10100.00
execution time: 0.35

$ ./chi_square lvm2_device
chi square: 130560.00
execution time: 0.17

So the execution time is low enough to perform the calculation for every
device.
I also implemented an entropy calculation on the same data, which
produces what looks like equally good results to me, with about the same
execution time. So I think we could also use entropy as an indicator.

The only problematic result I got is from my encrypted swap partition:
chi square: 244.00
execution time: 0.35

This is because the swap partition is encrypted in dm-crypt in plain
mode, i.e. non-LUKS mode, so there is no LUKS header. As a result, all
volumes encrypted in dm-crypt plain mode are indistinguishable from
random data, just like TC/VC volumes. The same is true for cryptoloop
(loop-AES) volumes.

Since both the dm-crypt plain mode and loop-AES encryption are also
supported by cryptsetup, we could solve this by letting the user choose
the encryption mode when they try to unlock a volume that looks like
it's encrypted. They would have to select from all of TrueCrypt,
VeraCrypt, dm-crypt plain, and loop-AES.

> Returning back to container files vs GNOME Files, I think it's enough if we 
> simply consider those that have the .tc or .hc extensions. One could consider 
> running the TCHunt algorithm on files with those extensions, but given the 
> risk for false negatives/false positives that seems like it doesn't add 
> anything (contrary to the partition case, where that is all we have).

I'm not sure what you have in mind for how we should handle container
files in GNOME Files. Is this about double-clicking a file in order to
decrypt it? I don't know exactly how to handle this case, but I don't
think it

[Tails-dev] October meeting notes

[segfault]

Here are the October meeting notes.

Cheers!
From 3509c2f0689b0a48096abbec24ad692549fb7ee6 Mon Sep 17 00:00:00 2001
From: segfault <segfa...@riseup.net>
Date: Tue, 3 Oct 2017 20:36:48 +0200
Subject: [PATCH] Add October meeting notes

---
 wiki/src/contribute/meetings/201710.mdwn |  39 
 wiki/src/contribute/meetings/201710/logs.txt | 284 +++
 2 files changed, 323 insertions(+)
 create mode 100644 wiki/src/contribute/meetings/201710.mdwn
 create mode 100644 wiki/src/contribute/meetings/201710/logs.txt

diff --git a/wiki/src/contribute/meetings/201710.mdwn b/wiki/src/contribute/meetings/201710.mdwn
new file mode 100644
index 00..44b98ffd5f
--- /dev/null
+++ b/wiki/src/contribute/meetings/201710.mdwn
@@ -0,0 +1,39 @@
+[[!meta title="October 2017 online meeting"]]
+
+[[!toc levels=2]]
+
+# Meta
+
+- Attendees: anonym, emmapeel, intrigeri, pablonatalino, segfault, spriver, u
+
+- [[Logs|201710/logs.txt]]
+
+# Volunteers to handle "Hole in the roof" tickets this month
+
+Nobody.
+
+# Volunteers to handle important tickets flagged for next release, but without assignee
+
+There are no such tickets.
+
+# Important missing bits in the next monthly report
+
+u will add something about the reproducibility progress
+
+# The monthly report is looking for coordinators
+
+We still need someone for October. u will write an email to tails-project to ask people to do this.
+
+# [[!tails_ticket 7224 desc="Link different design documentations from user documentation"]]
+
+Problem description: It happens regularly, that people have questions or doubts about *how* we implemented what we promise. So we have to manually point them to the design doc. It's somewhat tiring. And chances are a few other people have the same questions/doubts but don't ask. We might also be losing potential new contributors there.
+
+The proposed solution is to link from the documentation pages to the appropriate design pages, so that power users can better find those pages on their own. But we worry about the added complexity for 99% of the readers. We hope that a good web designer will find a good solution.
+
+We agree that, to be more welcoming to that web designer, we would like to *first* propose a few (say, 5-10) design docs to link.
+
+Intrigeri volunteers to create this list of design docs to link. Then we have to wait for someone to do the web design work. The actual implementation could be done by anonym, segfault or u.
+
+# Other tickets
+
+We noticed that there are other tickets to discuss, which are not on the agenda, but couldn't find / agree on one that would still fit in the meeting.
diff --git a/wiki/src/contribute/meetings/201710/logs.txt b/wiki/src/contribute/meetings/201710/logs.txt
new file mode 100644
index 00..2b15071399
--- /dev/null
+++ b/wiki/src/contribute/meetings/201710/logs.txt
@@ -0,0 +1,284 @@
+[07:04:43 PM] ‎u‎: Volunteers to handle hole in the roof tickets? https://labs.riseup.net/code/versions/198
+‎[07:04:43 PM] ‎intrigeri‎: go go go!
+‎[07:04:57 PM] ‎u‎: i'm too busy atm to do more..
+‎[07:04:58 PM] ‎anonym‎: nope
+‎[07:05:12 PM] ‎segfault‎: same here
+‎[07:05:15 PM] ‎intrigeri‎: not me.
+‎[07:05:42 PM] ‎u‎: Volunteers to handle important tickets flagged for next release, but without assignee (let me search for the url)
+‎[07:05:56 PM] ‎‎pablonatalino‎ has left (Disconnected: closed)
+‎[07:06:33 PM] ‎‎pablonatalino‎ has joined the group chat
+‎[07:07:02 PM] ‎intrigeri‎: u: there's none.
+‎[07:07:09 PM] ‎u‎: yep
+‎[07:07:18 PM] ‎intrigeri‎: Redmine mafia strikes again! :)
+‎[07:07:19 PM] ‎u‎: so next: availability and plans until the next meeting
+‎[07:07:23 PM] ‎u‎: intrigeri: :)
+‎[07:07:56 PM] ‎anonym‎: office hours without any planned exceptions so far
+‎[07:08:02 PM] ‎u‎: i'm working on another project this month, but i'm also andling our donation campaign and i hope i'll be able to launch in the middle of october
+‎[07:08:23 PM] ‎u‎: i'm mostly available, except on weekends
+‎[07:08:59 PM] ‎segfault‎: i will continue working on the OTF/Veracrypt project, where I will hopefully finish the udisks part and start with the GNOME Disks part
+‎[07:09:10 PM] ‎u‎: :)
+‎[07:09:31 PM] ‎segfault‎: and i'm also mostly available
+‎[07:09:54 PM] ‎‎pablonatalino‎ has left (Disconnected: closed)
+‎[07:10:09 PM] ‎intrigeri‎: October will be primarily about Buster (it rhymes!) + helping with reprobuilds if/where needed + quite some accounting/management/organization stuff such as documenting the sponsorship process. Plus the usual daily core work stuff. I'll take week 43 (Oct 23-29) off and then Reproducible Builds World Summit (nothing less).
+‎[07:10:52 PM] ‎u‎: ok!
+‎[07:10:53 PM] ‎‎pablonatalino‎ has joined the group chat
+‎[07:10:57 PM] ‎intrigeri‎: (speaking of which, I should send my 

Re: [Tails-dev] Debian 9: Build fails consistently, name resolution fails sooner or later

[segfault]

Arnaud:
> The failure doesn't always happen at the same point of the build. At
> first, I thought it was related to `apt`, but I also experienced in
> failure on a `curl` command (when downloading Tor Browser, in
> `config/chroot_local-hooks/10-tbb`). I don't have the log anymore, but
> it was also a name resolution failure.

I too experienced build failures during
`config/chroot_local-hooks/10-tbb`. It turned out to be caused by
insufficient memory, of which I had 8 GB RAM (some took by the gnome
session and system services) plus 8 GB swap. I could build successfully
after increasing swap to 16 GB.

Hope this helps.

Cheers!
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [review'n'merge] March contributors meeting notes

[segfault]

intrigeri:
> segfault:
>> Hi, here are the notes of today's meeting. Please review and merge.
> 
> applied, thanks!
> 
> will you update the tickets accordingly in Redmine?

Done!
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] [review'n'merge] March contributors meeting notes

[segfault]

Hi, here are the notes of today's meeting. Please review and merge.
Cheers!
>From 835a9183ed777d727db35afaaa2489a796466a12 Mon Sep 17 00:00:00 2001
From: segfault <segfa...@riseup.net>
Date: Fri, 3 Mar 2017 22:35:00 +
Subject: [PATCH 1/1] March contributos meeting notes

---
 wiki/src/contribute/meetings/201703.mdwn | 58 
 1 file changed, 58 insertions(+)
 create mode 100644 wiki/src/contribute/meetings/201703.mdwn

diff --git a/wiki/src/contribute/meetings/201703.mdwn b/wiki/src/contribute/meetings/201703.mdwn
new file mode 100644
index 00..c2073af46d
--- /dev/null
+++ b/wiki/src/contribute/meetings/201703.mdwn
@@ -0,0 +1,58 @@
+[[!meta title="March 2017 online meeting"]]
+
+[[!toc levels=1]]
+
+
+# Hole in the roof
+
+intrigeri will work on [[!tails_ticket 8449 desc="Tails Upgrader fails to install some IUKs"]] and the related [[!tails_ticket 11839 desc="After automatic upgrade from Tails 2.5 to 2.6, keyboard and mouse stop working"]].
+emmapeel will see if she can take care of [[!tails_ticket 5597 desc="obfsproxy design documentation"]].
+
+
+# Volunteers to handle important tickets flagged for next release, but without assignee
+
+All the tickets for Tails 2.12 were already assigned!
+
+
+# Availability
+
+* emmapeel will be in Valencia with sajolida... plans to warm up to some funders, localisation lab, guardian project people. also pushing for the spanish translation of course
+* intrigeri: plans: mostly reproducible builds sprint, Stretch sprint, Tor dev meeting. maybe start working on my keynote for cryptorave. and smaller 2.x Foundations Team stuff like tor and Linux upgrades. availability: mostly available for Tails but mostly busy with my commitments.
+* spriver: I'll work on #12260 and #5323. and doc updates for 3.0 during the Stretch sprint. availability: medium for Tails, mostly at weekends
+* segfault: I plan to work on the Tails Server beta release, but I'm very busy with other stuff, so I'm not sure how much I will be able to work on this. Availablility will be low.
+
+
+# Important missing bits in the next monthly report
+
+Report not written yet. Emmapeel will do it or mentor someone new until the 12th.
+
+
+# Discussions
+
+## [[!tails_ticket 6972 desc="Create a \"Sponsors\" page"]]
+
+We agreed on listing sponsors by year, and adding the ones for 2016. We postponed the discussion about 2015 and before, and the "when do we clean the 2016 section" topic too. There were no volunteers for this, thus the assignment falls to the fundraising team.
+
+
+##[[!tails_ticket 12076 desc="Have a sponsor per release"]]
+
+We discussed the concerns about this. Some of us have the feeling this might hurt the public image of the project, making it look cheap or more dependent from sponsors than previously conceived. On the other hand, we acknowledge that the release funding would actually be unrestricted funding, in contrast to other funding which is sometimes only for a specific purpose. It was noted that we need more funding in general and that we would like to have more unrestricted funding. We agreed that we would be ok with this if we make it clear what exactly the sponsor paid for (and what they didn't).
+
+
+## [[!tails_ticket 11882 desc="Consider disabling recent usage and history in privacy settings by default"]]
+
+We agreed that we are not convinced the proposed patch would be a security improvement. Intrigeri will write a comment on the ticket asking for clarification and explaining our thoughts.
+
+
+## [[!tails_ticket 12104 desc="Decide whether we can drop DKMS modules support"]]
+
+We acknowledge that losing clipboard sharing is an important UX hit for VirtualBox user. Whether that's a good enough reason to 1. spend tons of time maintaining the DKMS thing; 2. making grsec much harder to get in Tails; was not something we could make up our mind firmly about. But we were leaning towards 'no' as an answer.
+
+
+## [[!tails_ticket 9003 desc="Cleanup outdated blueprints"]]
+
+We agreed to move the old blueprints to an archive page.
+
+## Other tickets
+We postponed the discussions of [[!tails_ticket 9900 desc="Improve Website search"]] and [[!tails_ticket 12214 desc="Consider documenting a way to manually backup persistent data"]]. cbrownstein noted that they would like to work on [[!tails_ticket 12214 desc="Consider documenting a way to manually backup persistent data"]].
+
-- 
2.11.0

___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Why Tails partition is non-deterministic?

[segfault]

Joanna Rutkowska:
> On Sat, Aug 27, 2016 at 06:54:10PM +0000, segfault wrote:
> The added value would be ensuring the unused portion of the disk blocks
> (occupied by the Tails partition) are not populated with some random garbage,
> which might be e.g. user's previous (unencrypted) content, such as... family
> pictures ;)

Ok, but data leakage and verification are different problems IMO. In the
tails-verifier I did not try to prevent data leakage or the other
possibility of using unverified parts as a hidden channel (which could
be used by malware), but only focus on modifications which could alter
the behavior of Tails (i.e. changes in boot code or files).
I think preventing data leakage and hidden channels is also desirable,
but because of the behavior of flash drives you mentioned, I think it is
hard to guarantee this.

> Generally, I think the Tails installer should at least ask the user to wipe 
> the
> disk with 'dd if=/dev/zero'. Admittedly, because of wear leveling mechanisms
> this might not be effective, because AFAIU modern flash memories would include
> (X*size) of the actual physical storage in order to expose (size) bytes of
> storage to the host, where X > 1. 

Right, so `dd if=/dev/zero` would not always protect from data leakage.
So I tend to disagree that we should do this in Tails Installer, because
it would make the installation process slower and might give a wrong
feeling of security.

> But perhaps if the wiping were repeated N times, where N = ceiling (X), with
> random content this time (in order to fool any optimizations by the device),
> then it should be fine?

Would this guarantee that every byte was overwritten? Wouldn't it be
possible that the same (size) bytes get overwritten multiple times but
the (X-1)*size other bytes stay the same?

Cheers
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Why Tails partition is non-deterministic?

[segfault]

Hi,

somehow I missed this thread, just noticed it right now.

intrigeri:
> Hi,
>
> thanks Joanna for raising this topic!
>
> I've just thought about it a little bit and I see no technical reason
> that prevents us from resetting all timestamps in the filesystem to
> some fixed value that depends only (if at all) on the version of Tails
> being installed/upgraded, during some late stage of the
> installation process.

I think you're right. I did not test if the modification date is indeed
the only thing that differs, but I think Joanna is right, I don't see
anything else that should differ. This would also make tails-verifier
less complex, because we wouldn't have to look at each file but can
check the whole partition at once, like Joanna suggested (although the
file verification is not the complex part).

>
> And it would be nice if tails-verifier looked at filesystem metadata
> as well as files content, if it doesn't yet. I bet it's cheaper to add
> this check than to prove that it's not needed :)

I can't find a source which explicitely states this, but I'm pretty sure
the modification date is the only file metadata available in unix' vfat
(beside the size, which is also checked with the hash sum). See for
example the full list of attributes in the FAT32 directory table [1] and
this short paragraph in wikipedia about unix' vfat driver [2].

[1]
https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#Directory_entry
[2] https://en.wikipedia.org/wiki/FAT_filesystem_and_Linux#vfat

Currently I don't compare the dates, because they differ from the ones
on the ISO, so the verification would fail.

Cheers
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] [GSoC] Tails Server - Final status report

[segfault]

Hi everone,

the GSoC ends this week. My goal was to implement the basis of the Tails
Server, which should include a GUI and a CLI to install, configure and
start onion services in Tails. I implemented a prototype which meets
this goal. There are nightly images [1] of Tails including this
prototype and the code is available here [2]. This is not yet a call for
testing, but there will be one at some point.

[1]
http://nightly.tails.boum.org/build_Tails_ISO_feature-5688-tails-server/builds/lastSuccessfulBuild/archive/
[2] https://gitlab.com/segfault_/tails/commits/feature/5688-tails-server

The current prototype does not meet all the requirements for shipping it
in Tails yet (which was not the goal of the GSoC), but it won't require
too much additional work.

These are some things that still need to be done before including
Tails Server in Tails IMO:
- Implement client authentication
- Run as non-root user
- Fix some UI issues
- Test performance on low end hardware
- Find and fix bugs
- Improve user documentation
- Write design documentation
- Write tests for Tails' test suite

I will definitely keep on working on this and try to finish it ASAP. I
don't know exactly how much time I will be able to spend on this from
now on, but a first version of Tails Server could be shipped with Tails
in early 2017 or even late 2016.

Cheers
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [GSoC] Tails Server - status report 5

[segfault]

sajolida:
> segfault:
[...]
>> - Write documentation
> 
> Where can I see this?

Currently I only have this documentation for the Mumble server:

https://gitlab.com/segfault_/tails/blob/feature/5688-tails-server/wiki/src/doc/tails_server/mumble.mdwn

>> - Make the application translatable
> 
> I really want to review all your user-visible strings at some point but
> I'll wait until I can see all of them in a PO file.

I created a PO to translate the strins. But I didn't know how to
integrate it in Tails, so I just put it in
`config/chroot_local-includes/usr/share/locale/de/LC_MESSAGES/` (but I
know that's not how it's done). Anyway, you can take a look at it here:

https://gitlab.com/segfault_/tails/blob/feature/5688-tails-server/config/chroot_local-includes/usr/share/locale/de/LC_MESSAGES/tails-server.po
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] [GSoC] Tails Server - status report 5

[segfault]

Hi everyone,

this is the fifth status report on the Tails Server GSoC project.

I did two batches of user tests in the last two weeks, with five
participants each. The results were mixed, more skilled users had a
better user experience than less skilled users. I will try to solve the
problems discovered and make it more user-friendly for less skilled
users. You can read my reports and the following discussions on the
Tails-UX mailinglist [1].

[1] https://mailman.boum.org/pipermail/tails-ux/2016-July/thread.html

Other things I did in the last two weeks:

- Fix and improve the "clickable label"-widget I implemented

- Implement the autostart feature

- Write documentation

- Make the application translatable

- Refactor the code

- Fix several bugs


You can still download nightly images from here [2], but the recent
images don't include the latest changes yet. They will be included in
the next few days.

Cheers!
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [tor-dev] [GSoC] Tails Server - status report 4

[segfault]

Hi,

George Kadianakis:
> segfault <segfa...@riseup.net> writes:
> 
>> [ text/plain ]
>> Hi everyone,
>>
>> this is the fourth status report on the Tails Server GSoC project.
>>
>> First off: There are nightly images of Tails with integrated Tails
>> Server available for download [1]. Some notes if you want to test it:
> 
> Hey segfault,
> 
> I gave your iso a try! The application seems to work pretty well!

Thanks for testing it!

> 
> Here are some nitpicking comments. Feel free to ignore comments that involve
> parts you have not yet implemented.
> 
> - When Mumble starts it just says "Online". There is no indication on how to
>   use it, what's the onion address, or how you connect to it.
>
> - Why is the reset button available only for Gobby?
>
> - Mumble has no options? Not even port or onion address like Gobby?

That should not happen. Seems like you discovered a bug. But I can't
reproduce it in the current version. :/

> 
> - OTOH, Gobby provides useful information when it starts, like the onion
>   address and the port.
> 
>   However, in both cases I was actually not sure how to test or use the
>   service. I wonder if it would make sense to have a small paragraph for each
>   type of service pointing to resources on the internet, or a small guide on
>   how your friends can connect to you... (hm, localization issues?)

I plan to relay on the documentation for this (the question mark).

> 
>   I guess the client-side of Mumble is also installed on Tails right? So
>   testing it from inside Tails should be quite easy.

Right.

> 
> - I tried starting up (installing) Mumble for the first time without
>   Internet. The startup blocked for a while and then it displayed a message
>   that said "An error occured. See the log for details." How is the user
>   supposed to find this log?

Installing services won't work without Internet, because the packages
are downloaded and installed on the fly. I didn't implement logging to a
file yet, only to stdout (so no log if you didn't start tails-server
from the command line). I think I should catch the error caused by
missing Internet connection and set the status message accordingly.

> - In Gobby, is the server password securely auto-generated? Can we make this
>   more obvious maybe? Or maybe can we have an opt-in "auto-generate" button
>   that generates a password only if the user wants?

In both Mumble and Gobby the server password is a 20 character random
string. We could implement a button to generate a new (secure) password,
but I kinda like the secure default. Do you think explaining this in the
documentation would be acceptable?

> 
>   Or maybe the current auto-generate by default approach is best for UI. Not 
> sure.
> 
>   BTW, did you write the password generation routine yourself or is it a
>   module? You don't have one that uses readable words instead of random 
> base64?

I use Python's random module:
import random; import string;
''.join(random.SystemRandom().choice(string.ascii_letters +
string.digits) for _ in range(20))

I kinda expect users to copy-paste the `Connection Info` (including
onion address and password). But I think you're right and it wouldn't
hurt to use something more readable. I did a quick search and didn't
find any Python module in Debian that provides such a function. Do you
know one?

> 
> - When Gobby is offline, the "Connection info" says "None". Maybe it should 
> say
>   "Service has not been started" or sth?

A status message is already displayed above, in the status line. The
onion address is also "None" if the service was not started yet. I don't
know if it makes sense to set them both to status messages instead.

> 
> - I pressed the "Help" question mark button, but it did nothing. I assume it's
>   not yet implemented.

Yeah, I only implemented this for Mumble two days ago. It will be
avaible in one of the next nightlies.

>   
> Hope some of these comments are useful, and I did not duplicate the 
> discussions
> you've been having on the other thread.

They were helpful :) Thanks again

Cheers
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [GSoC] Tails Server - status report 4

[segfault]

sajolida:
> segfault:
>> [1]: 
>> http://nightly.tails.boum.org/build_Tails_ISO_feature-5688-tails-server/builds/
> 
> That's super cool! I'm downloading one now (and I hope I'll get to test
> it before long)
> 
>>   * Implement three different approaches to edit the options. Discuss
>> each of them on the tails-ux mailing list. Start conducting short user
>> tests to get some data on which approach provides the best UX.
> 
> Which option is built in the branch?

None of the three we discussed, but simple text entries which are grayed
out when the service is running.

> 
>> Next up is (still) writing a short documentation for the upcoming user
>> tests.
> 
> Is this like writing a prototype of what the final end-user
> documentation would be so that people can refer to it during the tests?

Exactly.
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] [GSoC] Tails Server - status report 3

[segfault]

Hi everyone,

this is the third status report on the Tails Server GSoC project.

I had to omit the previous report because personal difficulties were
getting in the way.

So here is what I achieved in the last four weeks:

* Revamp the GUI
  * Replace the status panel with a config panel
  * Add a loading window

* Implement the persistence feature

* Refactor the code

* Many more changes in the code, you can look at my commit messages if
you want more details

* Keep discussing the design of the GUI on the Tails-UX mailing list

The prototype is actually working now. The persistence feature works
without dirty hacks now, because anonym kindly implemented a new feature
in  Tails' persistence (regular files can be bind-mounted now). Because
Tails Server now relies on this feature, it will only work properly in
this patched Tails version. I will integrate Tails Server in this branch
and send a link to a nightly ISO image on tor-dev and tails-dev in the
next few days, so you can test it.

Next up is some more polishing of the GUI and writing a short
documentation to be able to do some initial user tests. And then there
are still a lot of features to implement, like autostarting the
services, onion address regeneration, client authentication (not
necessarily in scope of the GSoC, but I want it anyway), and many more.
And I will have to refactor the code some more.

Cheers!
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Persistent torrc [Was: Tails Server: updated plan and GSoC!]

[segfault]

anonym:
[...]
>> Just to clarify things: Currently Tails Server does have a configuration
>> file for each service (which is made persistent if the service is
>> persistent). Those are currently in /usr/share/tails-server/options/,
>> e.g. /usr/share/tails-server/options/mumble. But I only store options in
>> there which are not part of some other configuration file, in order to
>> prevent redundancy and inconsistent states. So everytime Tails Server
>> needs the value of an user option, the corresponding configuration file
>> (e.g. /etc/mumble-server.ini for the server password) is parsed.
>> (But the persistent option is not stored anywhere else, so it is stored
>> in this internal options file.)
>>
>> Please tell me if you see any problems with this approach.
> 
> Yes, this is exactly what we had very good reason to agree to do before,
> so it's awesome! 

I just noticed that actually I do not parse the config files every time
I need an option value. I only read the value the first time I need it
and then store it in a variable. I do write to the config files
everytime the value is set though.
I can test later how much the performance impact of parsing the config
files every time.
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Persistent torrc [Was: Tails Server: updated plan and GSoC!]

[segfault]

anonym:
> segfault:
>> anonym:
>>> segfault:
>>>> anonym:
>>>>> segfault:
>>> [...]
>>>>>> I wrote some code to make single files persistent by creating a new
>>>>>> directory in TailsData_unlocked, moving the file into it and adding the
>>>>>> directory to the persistence.conf with type "link". I think this a
>>>>>> pretty ugly solution.
>>>>>
>>>>> It sounds ugly, indeed.
>>>>
>>>> Right. Do you have any other idea to solve this problem of making single
>>>> files persistent?
>>>
>>> Yes, to implement the support for this properly in the persistence
>>> back-end, in live-boot (which I believe mostly amounts to removing some
>>> `[ -d ... ]` checks). I believe I've offered before to do that if
>>> needed, otherwise, here's my explicit offer. :)
>>
>> Wow, that would be great. We talked about this feature before and we
>> agreed that it would be great if we had this, but I don't think you
>> offered to do this yourself :)
> 
> I now remember that I offered it to intrigeri, for another purpose.
> 
>> Actually, I took a look at the
>> persistence backend to figure out what would be needed to get this done,
>> but I was deterred by the vast amount of perl code :D
> 
> Yes, I remember that, but you were not looking at the right place if you
> found perl code. You probably looked at the frontend, e.g.
> tails-persistence-setup, which is a GUI for creating the persistence
> partition, and editing persistence.conf.

Right, I think it was tails-persistence-setup.

> If you are curious, the backend is written in even worse shell script,
> and lives in `/lib/live/boot/9990-misc-helpers.sh` (installed by the
> live-boot package).
> 
>>> However, if possible, let's try an approach that doesn't rely on this,
>>> ok? But I still guess you'd like to have this for the persistent
>>> configuration/date for services (i.e. the non-Tails Server bits, e.g.
>>> mumble-server's database and similar) as we've discussed before?
>>
>> ACK. I agree that the other options are better than making the torrc
>> persistent. But I still need to make single configuration files
>> persistent (e.g. /etc/mumble-server.ini).
> 
> Ok, I created #11533 [0] to track this and pushed a branch with a first
> attempt at patching live-boot. I haven't tested it, so please do! If it
> doesn't work, perhaps the patch gives you enough context to fix it
> yourself (it should be confined to `activate_custom_mounts()`)? :) But
> please don't waste time on it -- this code is my own baby Frankenstein.
> 
> [0] https://labs.riseup.net/code/issues/11533

I tested it and it works! Thanks so much for implementing this :)

>>> [...]
>>>>> # torrc.d hack
>>>>>
>>>>> We have a wrapper that we *always* use to (re)start to, namely
>>>>> restart-tor [0]. We could simply add logic to it so that before starting
>>>>> tor, for each $line of all files in /etc/tor/torrc.d/*.conf, check if
>>>>> $line is already present in /etc/tor/torcc, and if not, append $line.
>>>>> It's not as refined as the upstream feature will be, but it'll serve our
>>>>> purposes for now, so I think it is good enough.
>>>>>
>>>>> [0] config/chroot_local-includes/usr/local/sbin/restart-tor
>>>>
>>>> This way we would have to call restart-tor to add / remove a hidden
>>>> service, right? So this would actually restart Tor, but right now I use
>>>> "systemctl reload tor@default", which does not restart tor but still
>>>> adds / removes hidden services. I think reloading provides better UX,
>>>> because restarting Tor closes all circuits.
>>>
>>> You're right! The easy solution would be to extract that part into a
>>> reload-tor, which we'd call instead. Of course, restart-tor would also
>>> call it, to get what I described above.
>>
>> That would work, but I prefer the other options :)
> 
> Great, then we agree! :)
> 
>>>>> # Maintain HiddenService{Dir,Port} lines in /etc/tor/torrc
>>>>>
>>>>> This is very similar to the torrc.d hack above, but this logic is in
>>>>> Tails Server instead. This is what the mumble-server script did,
>>>>> essentially, and the availability of this option is what made me say "We
>>>>> won't have that problem, I think" in the text you quoted from an earlier
>>>>&g

Re: [Tails-dev] Persistent torrc [Was: Tails Server: updated plan and GSoC!]

[segfault]

anonym:
> segfault:
>> anonym:
>>> segfault:
> [...]
>>>> I wrote some code to make single files persistent by creating a new
>>>> directory in TailsData_unlocked, moving the file into it and adding the
>>>> directory to the persistence.conf with type "link". I think this a
>>>> pretty ugly solution.
>>>
>>> It sounds ugly, indeed.
>>
>> Right. Do you have any other idea to solve this problem of making single
>> files persistent?
> 
> Yes, to implement the support for this properly in the persistence
> back-end, in live-boot (which I believe mostly amounts to removing some
> `[ -d ... ]` checks). I believe I've offered before to do that if
> needed, otherwise, here's my explicit offer. :)

Wow, that would be great. We talked about this feature before and we
agreed that it would be great if we had this, but I don't think you
offered to do this yourself :) Actually, I took a look at the
persistence backend to figure out what would be needed to get this done,
but I was deterred by the vast amount of perl code :D

> However, if possible, let's try an approach that doesn't rely on this,
> ok? But I still guess you'd like to have this for the persistent
> configuration/date for services (i.e. the non-Tails Server bits, e.g.
> mumble-server's database and similar) as we've discussed before?

ACK. I agree that the other options are better than making the torrc
persistent. But I still need to make single configuration files
persistent (e.g. /etc/mumble-server.ini).

> [...]
>>> # torrc.d hack
>>>
>>> We have a wrapper that we *always* use to (re)start to, namely
>>> restart-tor [0]. We could simply add logic to it so that before starting
>>> tor, for each $line of all files in /etc/tor/torrc.d/*.conf, check if
>>> $line is already present in /etc/tor/torcc, and if not, append $line.
>>> It's not as refined as the upstream feature will be, but it'll serve our
>>> purposes for now, so I think it is good enough.
>>>
>>> [0] config/chroot_local-includes/usr/local/sbin/restart-tor
>>
>> This way we would have to call restart-tor to add / remove a hidden
>> service, right? So this would actually restart Tor, but right now I use
>> "systemctl reload tor@default", which does not restart tor but still
>> adds / removes hidden services. I think reloading provides better UX,
>> because restarting Tor closes all circuits.
> 
> You're right! The easy solution would be to extract that part into a
> reload-tor, which we'd call instead. Of course, restart-tor would also
> call it, to get what I described above.

That would work, but I prefer the other options :)

> 
>>> # Maintain HiddenService{Dir,Port} lines in /etc/tor/torrc
>>>
>>> This is very similar to the torrc.d hack above, but this logic is in
>>> Tails Server instead. This is what the mumble-server script did,
>>> essentially, and the availability of this option is what made me say "We
>>> won't have that problem, I think" in the text you quoted from an earlier
>>> email of mine above. No torrc persistence is needed for this -- Tails
>>> Server's persistent configuration will contain all the parameters needed
>>> for knowing exactly which HiddenService{Dir,Port} lines that should be
>>> in /etc/tor/torrc. Therefore I think it's preferable to the previous option.
>>
>> So you mean we shouldn't use the Tails persistence feature for this at
>> all and simply ensure the lines are present when starting a Tails
>> service, right? I didn't think about this before, but I think this would
>> work.
> 
> Unless I have the wrong assumptions here. :) How I imagine this is that
> Tails Server itself has a persistent configuration storing the settings
> exposed by Tails Server for each service (is service X persistent?
> autostart? and user options etc.). 

Just to clarify things: Currently Tails Server does have a configuration
file for each service (which is made persistent if the service is
persistent). Those are currently in /usr/share/tails-server/options/,
e.g. /usr/share/tails-server/options/mumble. But I only store options in
there which are not part of some other configuration file, in order to
prevent redundancy and inconsistent states. So everytime Tails Server
needs the value of an user option, the corresponding configuration file
(e.g. /etc/mumble-server.ini for the server password) is parsed.
(But the persistent option is not stored anywhere else, so it is stored
in this internal options file.)

Please tell me if you see any problems with this approach.

> Probably we'd also store all "persistent" hs keys here too. 

You m

Re: [Tails-dev] Persistent torrc [Was: Tails Server: updated plan and GSoC!]

[segfault]

sajolida:
> anonym:
>> # add_onion
>>
>> By using stem to communicate with Tor over the control port/socket to
>> add the hidden services, just like onionshare does (which would be a
>> good source for inspiration, code-wise), you don't need any torrc
>> persistence just like in the previous approach. This is probably the
>> most "proper" solution of these three (and requires implementing less
>> logic on our side), and it might even be the easiest after you've
>> familiarized yourself with the API. This seems like the best option to me.
> 
> Right, Stem has some API related to "_ephemeral_hidden_service" so maybe
> you could use that. What I'm saying here is way over my head but I knew
> about these functions so I thought it would be silly not to mention
> them. Search for "ephemeral_hidden_service" in
> https://stem.torproject.org/api/control.html.

Will do. Thanks.
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Persistent torrc [Was: Tails Server: updated plan and GSoC!]

[segfault]

anonym:
> segfault:
>> anonym:
>>> [...]
>>> One thing to note about the mumble-server script is the "little
>>> bind-mount trick" used to workaround Tor's AppArmor confinement. We
>>> won't have that problem, I think. I did that so that all things we want
>>> to make persistent for mumble-server lives in the same directory on the
>>> persistent media, i.e. both Tor's HS bits, and mumble-server's data. We
>>> certainly can do better by making these two separate, e.g. we make
>>> /var/lib/tor/hs persistent and store all HS bits there, and then make
>>> another directory outside of this persistent for the service
>>> configuration/data bits.
>>
>> I ran into this problem today.
> 
> :)
> 
>> To make it possible to use both ephemeral
>> services and persistent services at the same time, I can't simply add
>> all services to /etc/tor/torrc and make it persistent, because then
>> obviously all hidden services would be persistent. Sadly, we don't have
>> /etc/torrc.d yet. So instead I chose to use the
>> /usr/share/tor/tor-service-defaults-torrc for the persistent services
>> and /etc/tor/torrc for the ephemeral ones.
> 
> I think you should immediately look elsewhere for a better solution.
> tor-service-defaults-torrc must not be made persistent for the same
> reasons torrc must no (e.g. new versions will change this file, which
> persistence will "hide"). I don't even think this solution is wortwhile
> to use temporarily while fixing other parts -- a main goal of this
> project is to have a nice solution for this.
> 
>> I wrote some code to make single files persistent by creating a new
>> directory in TailsData_unlocked, moving the file into it and adding the
>> directory to the persistence.conf with type "link". I think this a
>> pretty ugly solution.
> 
> It sounds ugly, indeed.

Right. Do you have any other idea to solve this problem of making single
files persistent?

>> Now the problem is that the AppArmor confinement doesn't allow Tor to
>> use this symlink, because it points to a file outside of the allowed Tor
>> directories.
> 
> ACK, this was the "big" problem I had to fight with when playing with
> the mumble-server script.
> 
>> I could make the whole directory /etc/torrc or /usr/share/tor
>> persistent, but this would make some other files persistent too. I think
>> it would be problematic if a future release contains important changes
>> on any these files. Actually, this would also be problematic if we only
>> make one of the torrc files persistent and there would be important
>> changes to it.
>>
>> I could make this persistence feature even more ugly by creating a
>> subdirectory in /usr/share/tor/, making this subdirectory persistent,
>> then creating a symlink to it to TailsData_unlocked, putting the
>> tor-service-defaults-torrc in it and adding it to the persistence.conf
>> with type "link" to link the tor-service-defaults-torrc to /usr/share/tor.
> 
> None of this is good enough, IMHO, and I don't think we have to dive in
> to details why since there are good solutions.
> 
>> I think the best way would be to implement the torrc.d feature and/or
>> the bind-mounting-regular-files feature.
> 
> Among these I think hacking our own torrc.d feature is preferable, but I
> think there are a few other good solutions too:
> 
> # torrc.d hack
> 
> We have a wrapper that we *always* use to (re)start to, namely
> restart-tor [0]. We could simply add logic to it so that before starting
> tor, for each $line of all files in /etc/tor/torrc.d/*.conf, check if
> $line is already present in /etc/tor/torcc, and if not, append $line.
> It's not as refined as the upstream feature will be, but it'll serve our
> purposes for now, so I think it is good enough.
> 
> [0] config/chroot_local-includes/usr/local/sbin/restart-tor

This way we would have to call restart-tor to add / remove a hidden
service, right? So this would actually restart Tor, but right now I use
"systemctl reload tor@default", which does not restart tor but still
adds / removes hidden services. I think reloading provides better UX,
because restarting Tor closes all circuits.

> # Maintain HiddenService{Dir,Port} lines in /etc/tor/torrc
> 
> This is very similar to the torrc.d hack above, but this logic is in
> Tails Server instead. This is what the mumble-server script did,
> essentially, and the availability of this option is what made me say "We
> won't have that problem, I think" in the text you quoted from an earlier
> email of mine above. No torrc persistence is needed f

Re: [Tails-dev] Persistent torrc [Was: Tails Server: updated plan and GSoC!]

[segfault]

anonym:
> [...]
> One thing to note about the mumble-server script is the "little
> bind-mount trick" used to workaround Tor's AppArmor confinement. We
> won't have that problem, I think. I did that so that all things we want
> to make persistent for mumble-server lives in the same directory on the
> persistent media, i.e. both Tor's HS bits, and mumble-server's data. We
> certainly can do better by making these two separate, e.g. we make
> /var/lib/tor/hs persistent and store all HS bits there, and then make
> another directory outside of this persistent for the service
> configuration/data bits.

I ran into this problem today. To make it possible to use both ephemeral
services and persistent services at the same time, I can't simply add
all services to /etc/tor/torrc and make it persistent, because then
obviously all hidden services would be persistent. Sadly, we don't have
/etc/torrc.d yet. So instead I chose to use the
/usr/share/tor/tor-service-defaults-torrc for the persistent services
and /etc/tor/torrc for the ephemeral ones.

I wrote some code to make single files persistent by creating a new
directory in TailsData_unlocked, moving the file into it and adding the
directory to the persistence.conf with type "link". I think this a
pretty ugly solution.

Now the problem is that the AppArmor confinement doesn't allow Tor to
use this symlink, because it points to a file outside of the allowed Tor
directories.

I could make the whole directory /etc/torrc or /usr/share/tor
persistent, but this would make some other files persistent too. I think
it would be problematic if a future release contains important changes
on any these files. Actually, this would also be problematic if we only
make one of the torrc files persistent and there would be important
changes to it.

I could make this persistence feature even more ugly by creating a
subdirectory in /usr/share/tor/, making this subdirectory persistent,
then creating a symlink to it to TailsData_unlocked, putting the
tor-service-defaults-torrc in it and adding it to the persistence.conf
with type "link" to link the tor-service-defaults-torrc to /usr/share/tor.

I think the best way would be to implement the torrc.d feature and/or
the bind-mounting-regular-files feature.

___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [tor-dev] [GSoC] Tails Server - status report

[segfault]

sajolida:
> segfault:
>> I sent my first GSoC report only to tor-dev and forgot to send it to
>> tails-dev too. I quote it in full at the end of this mail.
> 
> I'll answer on tails-dev only and add George in explicit copy to avoid
> crossposting across mailing list.
> 
>> sajolida:
>>> segfault:
>>>> * I began implementing the CLI, the current code (not ready for review
>>>> yet) is also available on gitlab [2]
>>>>
>>>> Next I plan to continue the design of the GUI, after others commented on
>>>> the new prototype. There are still some features missing which I will
>>>> implement in time. In parallel I will continue implementing the CLI and
>>>> discussing the design decisions.
>>>
>>> Maybe the call for review for the CLI should be sent to
>>> tails-dev@boum.org instead of tails...@boum.org :P
>>
>> I didn't send a call for review for the CLI yet. Actually I wrote that
>> it's not ready for review yet (see the quote above).
> 
> I understood this and was mainly pointing out, partly as a joke, that
> once it was ready it should be sent to tails-dev and not tails-ux. Sorry
> I was unclear.

Oh, I didn't get that joke :)

> 
>>> Also, just out of curiosity, when are you planning to work on "Design an
>>> extensible and robust format describing the services and how they
>>> integrate into Tails"?
>>
>> I think this discussion has already started with anonym's mail [1]. I
>> discussed this further with him in XMPP because I had a different design
>> in mind but I think his is better, so I didn't write a mail about this
>> after the chat. I already started implementing and extending the design
>> (I think most shortcomings only become obvious during implementation).
>> Maybe I should send another mail about this.
>>
>> [1] https://mailman.boum.org/pipermail/tails-dev/2016-March/010506.html
> 
> You're right and I actually didn't read this thread very carefully
> myself because it was going out of my department. I was thinking that
> for example it would be good to have a blueprint that specifies how to
> describe a new service (the options specific to this service, what needs
> to be made persistent, how to start and stop it, etc.). And anonym's
> email looks like a good start indeed.
> 
> This will be useful during the design phase to allow people other than
> anonym and George to review it. For example, I really want intrigeri to
> review your specification because his vision is usually nicely
> complementary to anonym's but I don't expect him to follow our threads.

Ack.

> 
> This blueprint will also be easy to transform into a design document at
> the end of your project for more people to develop services. Because
> you're developing something like an API or a plugin mechanism here and
> this needs to be documented for others to use.

Ack.

> 
> That's something we do quite often while working on complex features: we
> elaborate blueprints as working documents and reference for reviews
> during the process, and then we turn them into design document once the
> project is over. And it will also be nicer to you not to have to write
> all this documentation once you delivered and want to go do something
> else more exciting than writing doc.

Ack.

I'm convinced and will start working on a blueprint for the TailsService
and TailsServiceOption designs. :)
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] An update to zuluCrypt status in debian

[segfault]

intrigeri:

> Is anyone here excited in working on this topic?

I am, but I have a lot of other things to do :/
Maybe in late summer I will have time for this.

> 
> Personally, I'd much rather see work towards having TrueCrypt volumes
> supported in udisks2 and GNOME Disks, than adding a second GUI to
> manage encrypted volumes: having to choose between two tools with
> overlapping functionality seems like a recipe for bad UX, to me.

I agree and I already planned to work on TrueCrypt / VeraCrypt support
in udisks and GNOME Disks.

> But of course it's a matter of "how much we really want TrueCrypt
> volumes support in a GUI" vs. "the UX regression of adding a tool with
> duplicated functionality".

Right. In my experience, TrueCrypt is something many users miss in
Tails. The most obvious use case is securely sharing files via storage
devices with non-Tails / non-Linux systems. For example users who want
to use Tails to edit documents and share them with others who do not
(yet) use Tails. This is possible with cryptsetup, but I would like to
support this via a GUI, because if this is too hard to do, some users
will instead use less secure systems for this purpose.

Cheers!
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [tor-dev] [GSoC] Tails Server - status report

[segfault]

I sent my first GSoC report only to tor-dev and forgot to send it to
tails-dev too. I quote it in full at the end of this mail.

sajolida:
> segfault:
>> this is the first status report on the Tails Server GSoC project. I
>> officially began working on it on April 25th, although I already did
>> some work in the weeks before.
>>
>> This is what I have done so far:
>>
>> * Updating the blueprint of the Tails Server [1]
>>
>> * Implementing two iterations of prototypes of the GUI. The most recent
>> one is available on gitlab [2].
> 
> The first one was a really cool step to see something tangible and
> comment upon, I'm excited about testing the second one now!
> 
>> * Discussing the design of the GUI on the Tails-UX mailing list [3][4]
>>
>> * I began implementing the CLI, the current code (not ready for review
>> yet) is also available on gitlab [2]
>>
>> Next I plan to continue the design of the GUI, after others commented on
>> the new prototype. There are still some features missing which I will
>> implement in time. In parallel I will continue implementing the CLI and
>> discussing the design decisions.
> 
> Maybe the call for review for the CLI should be sent to
> tails-dev@boum.org instead of tails...@boum.org :P

I didn't send a call for review for the CLI yet. Actually I wrote that
it's not ready for review yet (see the quote above).

> 
> By the way, maybe you should send you reports to tails-dev@boum.org
> also. We might be very few people from tails-dev@boum.org also following
> tor-dev@ closely.

Right. I said that I would do so previously and forgot.

> Also, just out of curiosity, when are you planning to work on "Design an
> extensible and robust format describing the services and how they
> integrate into Tails"?

I think this discussion has already started with anonym's mail [1]. I
discussed this further with him in XMPP because I had a different design
in mind but I think his is better, so I didn't write a mail about this
after the chat. I already started implementing and extending the design
(I think most shortcomings only become obvious during implementation).
Maybe I should send another mail about this.

[1] https://mailman.boum.org/pipermail/tails-dev/2016-March/010506.html

> 
> This discussion should definitely happen on tails-dev and I expect it to
> take quite a while. It's good that we started with the interface as it
> brings up concrete user scenarios that will influence the implementation
> and thus the format, but maybe you won't be able to jump straight from
> the interface to writing the backend before the format is better defined.
> ___
> tor-dev mailing list
> tor-...@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> 


> From: segfault <segfa...@riseup.net>
> To: tor-...@lists.torproject.org
> Date: Fri, 6 May 2016 18:04:58 +
>
> Hi everyone,
> 
> this is the first status report on the Tails Server GSoC project. I
> officially began working on it on April 25th, although I already did
> some work in the weeks before.
> 
> This is what I have done so far:
> 
> * Updating the blueprint of the Tails Server [1]
> 
> * Implementing two iterations of prototypes of the GUI. The most recent
> one is available on gitlab [2].
> 
> * Discussing the design of the GUI on the Tails-UX mailing list [3][4]
> 
> * I began implementing the CLI, the current code (not ready for review
> yet) is also available on gitlab [2]
> 
> 
> Next I plan to continue the design of the GUI, after others commented on
> the new prototype. There are still some features missing which I will
> implement in time. In parallel I will continue implementing the CLI and
> discussing the design decisions.
> 
> I did quite a lot during the last two weeks and I will have some other
> work to do in the next two weeks, so I expect to get less work done
> until the next report.
> 
> 
> Cheers!
> 
> [1] https://tails.boum.org/blueprint/tails_server/
> [2] https://gitlab.com/segfault_/tails_server
> [3] https://mailman.boum.org/pipermail/tails-ux/2016-April/thread.html#919
> [4] https://mailman.boum.org/pipermail/tails-ux/2016-May/thread.html#953




___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Tails Server: updated plan and GSoC!

[segfault]

Hi,

> At 32C3 we got quite inspired by the Tor presentation about onion
> services and started reviewing the plan we had on the Tails Server
> blueprint [0] with segfault.
> 
> [0]: https://tails.boum.org/blueprint/server_edition/
> 
> The Tails Server project has been on hold for many years, but segfault
> and anonym are interested in doing a GSoC about it this year. Yeah!
> I volunteered to help with the UX side of things.
Yay!


> Building on the simplified edition [1] I think we should aim at making
> the project as incremental as possible, getting really quickly to the
> minimal functionalities needed to get one or two templates for services
> and add more advanced administration features later in parallel with
> developing templates for more services.
> 
> [1]: https://tails.boum.org/blueprint/server_edition#index7h1
Yes, this is what I planned to do :)


> Ground work
> ===
> 
> It's also worth noted that this come when:
> 
> - The integration of OnionShare is moving forward [2] with some patches
> proposed to our tor-controlport-filter to support creating ephemeral
> onion services.
> 
> [2]: https://labs.riseup.net/code/issues/7870#note-15
I took note of this, but as I understand it, this will only enable
_ephemeral_ onion services, not reuse a key and onion address generated
previously, right? I plan to support both, persistent and ephemeral
onion services. Currently I think I will have to bind mount the hidden
service directory and reload Tor, just like it in the mumble server script.

> - We discovered other related works towards having a more feature-full
> Tor control port filter [3].
> 
> [3]: https://labs.riseup.net/code/issues/6742#note-13
Mmh, I think I should look for the Tor control port documentation and
read it. But first I have to focus on the GSoC application.

> - We know have a script to run a Mumble server from Tails [4] and are
> considering adding it to Tails [5].
> 
> [4]: https://labs.riseup.net/code/issues/9993
> [5]: https://labs.riseup.net/code/issues/11241
Yes, that's great! And the current version is really nice. I already
have some scripts written on my own to start other services, but the
mumble server one definitely does some things nicer than I do - it will
be very helpful during this project. Although it's a shell script and I
will implement the server in python3.

> - We have some very rough instructions to serve HTTP requests from Tails
> [6] and segfault has been working on making this available even when no
> administration password is set in Tails Greeter [7].
> 
> [6]: https://labs.riseup.net/code/issues/10970
> [7]: https://labs.riseup.net/code/issues/7879

I think this is a misunderstanding - actually my scripts need to be
executed as root and were never supposed to work without root. That
would definitely be a nice feature, but I don't think I will make this a
requirement for the GSoC project, because I think it won't be easy to
realize.

> - We wrote a statement of how Tails derivatives should be designed [8]
> which envision the need for more powerful customization mechanisms
> embedded in Tails.
> 
> [8]: https://tails.boum.org/contribute/derivatives/
> 
> Simplified edition reviewed
> ===
> 
> The current blueprint insists a lot on making Tails Server a special
> mode of operation, triggered on boot, and the possibility of running on
> dedicated hardware (possibly with no X). It's also based on slightly
> outdated assumptions:
I agree, the blueprint makes a lot of assumptions - I want to work on
the "simplified edition".


> - In [9] the blueprint seems to not take into account that we already
> have the Additional Software persistence feature.
> 
> [9]: https://tails.boum.org/blueprint/server_edition#index11h2
We could use the Additional Software persistence feature, but the last
time I used it, it installed the packages automatically at the end of
the boot up, increasing the time the user has to wait before he can use
the system. I guess this is still the case, right? I think installing
them only when the user actually wants to start the service provides
better UX. I prefer it this way, at least until we manage to make the
rest of the Tails server run without root privileges.

> - We now have a screen locker so a normal Tails session can be locked
> down properly and the special mode of operation is not needed for that.
Yes, that's also nice :)

> 
> - We removed Vidalia in 2.2.
> 
> So I propose that we don't make this special mode of operation a strict
> requirement for a first implementation and focus instead on being able
> to configure, start, and stop services from a normal Tails system, with
> persistence enabled and a GNOME session.
Agreed, that's what I planned too.

> 
> The "Use cases

Re: [Tails-dev] [review'n'merge] meeting notes

[segfault]

Hey,

I corrected the part about the pinentry decision.

cheers


emmapeel:
> 
> 
> emmapeel:
>> here you go!
>>
>> please add things you find missing...
>>
>>
> maybe i was not clear enough on the subject... please review the
> attachment and merge or correct...
> 
> 
> 
> 
> ___
> Tails-dev mailing list
> Tails-dev@boum.org
> https://mailman.boum.org/listinfo/tails-dev
> To unsubscribe from this list, send an empty email to 
> tails-dev-unsubscr...@boum.org.
> 
>From 42b117c8d6dc31c2ac9f84bc61e1987f6fe0907b Mon Sep 17 00:00:00 2001
From: emma peel <emmap...@aktivix.org>
Date: Fri, 4 Mar 2016 12:09:48 +
Subject: [PATCH] 2016 March meeting notes

---
 wiki/src/contribute/meetings/201603.mdwn | 56 
 1 file changed, 56 insertions(+)
 create mode 100644 wiki/src/contribute/meetings/201603.mdwn

diff --git a/wiki/src/contribute/meetings/201603.mdwn b/wiki/src/contribute/meetings/201603.mdwn
new file mode 100644
index 000..beaa8c8
--- /dev/null
+++ b/wiki/src/contribute/meetings/201603.mdwn
@@ -0,0 +1,56 @@
+1. Volunteers to handle "Hole in the roof" tickets this month
+-
+
+- anonym might already have dealt with [[!tails_ticket 7182]]: Identical branch HEADs can result in Vagrant building from the wrong branch
+- intrigeri is working on [[!tails_ticket 5650]] (rngd)
+- bertagaz is also working in background on [[!tails_ticket 7675]] 
+- [[!tails_ticket 6311]] is better done after [[!tails_ticket 6310]]
+
+2. Volunteers to handle important tickets flagged for next release, but without assignee
+
+
+- [[!tails_ticket 11075]]: Remove "Power Off" and "Reboot" from Applications → System Tools: we finally didn't had time to deal with this.
+- [[!tails_ticket 11175]]:  Decrease I/O load created by isotesters on lizard - this one was meant for bertagaz.
+
+3. Availability and plans until the next meeting
+
+
+- intrigeri: in March I should be mostly available for Tails. focus on SponsorS deliverables (mainly: freezable APT repo). except I'll have 1 week "off" (with lots time with new/wannabe contributors)
+- emmapeel is frontdesk,Valencia, translators, doc tickets, translation worflow
+- sajolida
+0. Refine the ideal workflow and review early mockups on [[network connection|https://tails.boum.org/blueprint/network_connection/]] (on Sunday).
+1. Make plans on what to do now and what to postpone regarding IA+DAVE.
+2. Invoice the two latest funders milestone.
+3. Start working on the redesign of the download page.
+- muri: iff, beach, cij; then clearing translation backlog; doing some other tickets i've on my watchlist; also thinking about writing a small python keysingning ui
+- anonym: I expect to be available all non-weekends all of March. I'll re-focus again on test suite robustness work, particularly on [[!tails_ticket 9521]] and trying out dogtail a bit more ([[!tails_ticket 7729]], [[!tails_ticket 10721]]). it also looks like I'll work on Icedove integration, unexpectedly. And look at Tails verifier.
+- ticketbot: Tails ☺ Feature #9521: Use the chutney Tor network simulator in our test suite https://labs.riseup.net/code/issues/9521
+- ticketbot: Tails ☺ Feature #7729: Evaluate using LDTP and/or dogtail to improve our automated test suite https://labs.riseup.net/code/issues/7729
+- ticketbot: Tails ☺ Feature #10721: Improve automated GUI testing robustness using "GUI aware" technologies https://labs.riseup.net/code/issues/10721
+- segfault: I will have more time in the next month than in february. I still want to work on the boot and upgrade process and on Tails server [[!tails_ticket 5688]]). And I'm looking forward to the review of the Tails verifier :)
+- bertagaz: March, mostly available hopefully, but focused on the monitoring deployment
+
+Discuss
+---
+
+[[!tails_ticket 11047]]: Decide if we want to have monthly reports and who should edit them 
+---
+
+- Everybody likes reports, but nobody gives input for them. Maybe a report that is incomplete is ok.
+- sajolida feels is a lot of effort to go through the logs or ask people for input.
+- Many of the 5 people that committed to make reports is not on this meeting so we skip the decision...
+- sajolida: is happy to manage the April report (or March) even, but somebody has to handle the weight of the Feb report
+
+[[!tails_ticket 11099]] Decide which pinentry we want to ship
+-
+
+- This and other related pinentry tickets will be taken by segfault. We decided to use pinentry-gtk2 with the 

Re: [Tails-dev] Hacking Team looking at Tails

[segfault]

> I'm not sure how the user could detect / verify that
> (realistically, you probably can't..). Running a rootkit checker from
> another *nix OS may be helpful, but of unknown effectiveness.

That's work in progress: https://labs.riseup.net/code/issues/7496
I implemented a prototype that's currently being QA checked:
https://gitlab.com/segfault_/tails_verifier
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.