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

[Vratislav Podzimek]

On Tue, 2017-11-14 at 20:05 +0100, segfault wrote:
> 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.
TC/VC key files are not supported by libblockdev now. But I believe
everything else should be covered.

Thanks!

-- 
Vratislav Podzimek
Senior Software Engineer
Kernel Storage
Red Hat Czech, Brno
___
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] Verification extension [was: HTML prototype for new download page]

[sajolida]

sajolida:
> Uzair Farooq:
>>> When the extension gets installed, the page is not updated to show "Verify 
>>> download...". See this screencast:
>>>
>>>  https://dl.poivron.org/maad2a3jiuqdu3k3wjbf-dirqyvooctlkem57
>>> 
>>>
>>> Uzair: Could you help me fix that? Is it something that should be fixed
>> in the extension or on the page?
>>
>> Fixed, extension will change the view to "Verify download..."
> 
> I tried to test this change but now your branch conflicts when I try to
> merge it in mine. It seems like you didn't merge the work I did on
> https://git-tails.immerda.ch/verification-extension as I instructed in
> https://mailman.boum.org/pipermail/tails-dev/2017-November/011853.html.
> 
> Can you do that and ask for guidance if needed?

I wanted to publish a new version of AMO so I did that merge and
published 0.92:

https://addons.mozilla.org/en-US/firefox/addon/tails-verification/

While doing this I came to wonder whether the version check was not
broken again: the page asks for 1.0 minimum while it's 0.92 that is on
AMO and the extension set 'data-extension="up-to-date"' on the page.

Can you double-check what's going on?

Also, probably since 80773cb, my console complains about

"SyntaxError: redeclaration of let VerifyDownload"

But I'm not sure that's important...

> On top of this, I'm worried to see that you copied some of the code and
> display logic that we have on the page into the extension (80773cb).
> Until now, this was quite decoupled and the display logic was happening
> only on the page (in dave_2.js).
> 
> I also see that you initially tried to implement this with a message in
> 412cb50 and I would much prefer this approach. What made you change your
> mind between 412cb50 and 80773cb
___
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

[Vratislav Podzimek]

On Mon, 2017-11-13 at 17:36 +0100, segfault wrote:
> 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
> 
> 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.

Thanks!

-- 
Vratislav Podzimek
Senior Software Engineer
Kernel Storage
Red Hat Czech, Brno
___
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] Version numbers [was: Release schedule for 2018]

[sajolida]

sajolida:
> * 2017-11-14: Release Tails 3.3 (bugfix release)
> * 2018-01-16: Release 3.4 (Firefox 52.6, bugfix release)

Errata:

  * 2018-01-16: Release 3.5 (Firefox 52.6, bugfix release)

> * 2018-03-06: Release 3.6 (Firefox 52.7, major release)
> * 2018-05-01: Release 3.7 (Firefox 52.8, bugfix release)
> * 2018-06-26: Release 3.8 (Firefox 59.2, major release)
> * 2018-08-21: Release 3.9 (Firefox 59.3, bugfix release)
> * 2018-10-16: Release 3.10 (Firefox 59.4, major release)
> * 2018-11-27: Release 3.11 (Firefox 59.5, bugfix release)
>
> For the record, we agreed on using the scheme "even=major odd=bugfix"
> as a trade-off which is easier to handle for developers and might make
> sense for some of our power users even if it might imply in rare
> occasions some jumps in version numbers (for example 3.4 followed by
> 3.6) which probably doesn't make sense to the vast majority of our
> users.

Errata:

  * 3.3 followed by 3.5.
___
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] Version numbers [was: Release schedule for 2018]

[sajolida]

intrigeri:
>  - Check if we need to adjust our version numbering scheme.
>sajolida, can you please take the lead on this after we've made
>a decision on #14578?

I'm not sure I should "take the lead" now but in /contribute/calendar
I see:

* 2017-11-14: Release Tails 3.3 (bugfix release)
* 2018-01-16: Release 3.4? (Firefox 52.6, bugfix release)
* 2018-03-06: Release 3.5? (Firefox 52.7, major release)
* 2018-05-01: Release 3.6? (Firefox 52.8, bugfix release)
* 2018-06-26: Release 3.7? (Firefox 59.2, major release)
* 2018-08-21: Release 3.8? (Firefox 59.3, bugfix release)
* 2018-10-16: Release 3.9? (Firefox 59.4, major release)
* 2018-11-27: Release 3.10? (Firefox 59.5, bugfix release)

But if we want to keep the even=major odd=bugfix we should do:

* 2017-11-14: Release Tails 3.3 (bugfix release)
* 2018-01-16: Release 3.4 (Firefox 52.6, bugfix release)
* 2018-03-06: Release 3.6 (Firefox 52.7, major release)
* 2018-05-01: Release 3.7 (Firefox 52.8, bugfix release)
* 2018-06-26: Release 3.8 (Firefox 59.2, major release)
* 2018-08-21: Release 3.9 (Firefox 59.3, bugfix release)
* 2018-10-16: Release 3.10 (Firefox 59.4, major release)
* 2018-11-27: Release 3.11 (Firefox 59.5, bugfix release)

For the record, we agreed on using the scheme "even=major odd=bugfix" as
a trade-off which is easier to handle for developers and might make
sense for some of our power users even if it might imply in rare
occasions some jumps in version numbers (for example 3.4 followed by
3.6) which probably doesn't make sense to the vast majority of our users.
___
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] Verification extension [was: HTML prototype for new download page]

[sajolida]

Uzair Farooq:
>> When the extension gets installed, the page is not updated to show "Verify 
>> download...". See this screencast:
>> 
>> https://dl.poivron.org/maad2a3jiuqdu3k3wjbf-dirqyvooctlkem57
>> 
>> 
>> Uzair: Could you help me fix that? Is it something that should be fixed
> in the extension or on the page?
> 
> Fixed, extension will change the view to "Verify download..."

I tried to test this change but now your branch conflicts when I try to
merge it in mine. It seems like you didn't merge the work I did on
https://git-tails.immerda.ch/verification-extension as I instructed in
https://mailman.boum.org/pipermail/tails-dev/2017-November/011853.html.

Can you do that and ask for guidance if needed?

On top of this, I'm worried to see that you copied some of the code and
display logic that we have on the page into the extension (80773cb).
Until now, this was quite decoupled and the display logic was happening
only on the page (in dave_2.js).

I also see that you initially tried to implement this with a message in
412cb50 and I would much prefer this approach. What made you change your
mind between 412cb50 and 80773cb?
___
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] Verification extension [was: HTML prototype for new download page]

[u]

Hi!

>> - contentscript/verify.js:
>>  - fetchConf(): please wrap the regexps.
> 
> Not sure what you mean by this. Do you want me to convert them to 'new
> Regex()' format?

Just put them into parentheses, if this works.

>> - manifest.json:
>>  -  "permissions": [
>> "http://*/*;,
>> -> please deactivate HTTP. We only want to download over HTTPS.
> 
> Fixed this. Also, I removed 'http://*/*' permission and added only
> tails.boum.org permission as we don't require permission for all sites.

Great!

Cheers!
u.
___
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.