Re: [Tails-testers] Request for JavaFX on Tails 3.0

Delete this message

Reply to this message
Autor: intrigeri
Data:  
A: Collin Sullivan, Tails developers
Assumptes nous: Re: [Tails-dev] [Tails-testers] Request for JavaFX on Tails 3.0
Assumpte: Re: [Tails-testers] Request for JavaFX on Tails 3.0
Hi,

[moving this discussion to tails-dev@]

Collin Sullivan:
> On 1/7/17 1:32 AM, intrigeri wrote:
>> I'll assume that the package Martus needs is either libopenjfx-java
>> or libopenjfx-jni.


> I'll need to confirm with some of the devs on my side. When we were
> experimenting with custom Tails builds that included Martus (where we
> did make some progress but ultimately didn't end up making a fully
> workable build), we included openjfx, libopenjfx-java and
> libopenjfx-jni. I don't know if all of them were necessary, and don't
> remember how large the resulting ISO was -- will look into that.


OK, please let us know once you have the exact list of dependencies
missing in Tails. I suggest you look into this using a Tails
experimental ISO based on Debian Stretch:

https://nightly.tails.boum.org/build_Tails_ISO_feature-stretch/lastSuccessful/archive/build-artifacts/

> You can look at the project here and see the other packages we
> included while testing: https://github.com/benetech/mtails/


Interesting. For those who want to follow along at home: that script
"remasters" a released Tails ISO to add some packages and
Martus itself.

Collin, if you folks ever come back to that script: you'll need to
ensure you set a custom TAILS_PRODUCT_NAME in /etc/os-release,
otherwise users of that Tails derivative will be proposed to install
automatic Tails updates, which will make their system behave in
undefined ways. Also, note that the way that script downloads .deb's
is not safer than the network link to the Debian mirror being used,
i.e. generally plaintext HTTP; I would not do that. And finally, our
documentation for derivatives might be interesting to you:
https://tails.boum.org/contribute/derivatives/

>> This seems to be exactly the kind of use cases for which we've
>> created the Additional Software Packages feature. So I'm curious:
>>
>> 1. Assuming we would ship the requested package by default: what's
>> the Martus setup process? Feel free to point me to you current
>> end-users documentation, I'll be happy to read it myself.


[...]

> In short, though, if you were to ship the requested packages by
> default, I assume the setup process would be something like:


> 1. Visit Martus.org, download the latest version of Martus for Linux
> (.zip file) to your Persistent folder and unarchive.


> 2. Either use a Terminal to cd into the Martus folder and run a
> certain command (which specifies Martus use the system Tor, saves all
> records in a Persistent subfolder, etc.); or run an executable text
> file including the command.


> This is off the top of my head but I believe that would be about it.
> Right now there are many more steps, including installing a non-system
> (and non-libre :P ) Java to the Persistent folder and pointing the
> Martus jar to that, which causes a lot of pain for users.


OK, so if we included Martus dependencies (or once we have a GUI for
managing additional software), the setup would be simplified, but it
would still not be straightforward. This is what I wanted to
understand. Thanks!

>> 2. What are the blockers for you folks to use the Additional
>> Software Packages feature to ensure the requested package is
>> installed in Tails?


> Good questions. There are a couple of things:


> 1) Our ultimate goal is to make the process of using Martus on Tails
> as easy as possible for our users. They tend to be somewhat
> intimidated by Tails as it is. Long lists of steps, including steps
> about installing additional packages, give them lots of opportunity to
> quit during setup, lots of ways things can go wrong, etc. We want to
> minimize frustration as much as possible.


Sure.

> 2) I could look again, but the libraries we need (I think) were not
> available in the Tails default repositories, so we needed to add new
> ones. That's another step for the user.


I expect this might have been fixed with Tails 2.x, or will be in 3.x.
But you may want to double-check :)

> 3) The less our partners/users need to use root / su / sudo, the
> better. Both for security and ease of use.


Absolutely, especially if command line is involved. This drawback will
be alleviated once there's a GUI to configure additional software (I'm
pretty sure it'll still require an administration password for the
initial setup, but at least there will be fewer steps that require
command line usage, and they will be required by your custom stuff
rather than by Tails limitations).

Cheers,
--
intrigeri