Re: [Tails-dev] Installing Tails as a Virtual Machine

[sajolida]

nibs123 via Tails-dev:
I downloaded the Tails iso in order to run Tails as a virtual machine. 
What version of Debian Linux does Tails currently use?


Debian 11 (Bullseye) but it should work to configure your virtualization 
software for Debian 10:


https://tails.boum.org/doc/advanced_topics/virtualization/virt-manager/

--
sajolida
Tails — https://tails.boum.org/
UX · Fundraising · Technical Writing


OpenPGP_signature
Description: OpenPGP digital 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] Build Tails Image: rake build - No artifacts found - No ISO/USB image produced

[Toptin]

I opened a bug report:

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

Regards.
___
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] using tails on microsoft surface

[intrigeri]

Hi,

paul seßbrügger (2021-09-07):
> I hope you’re all good. I’m a big fan of tails and appreciate what
> you guys doing.

Thanks, this is heart-warming!

> Unfortunately tails is not working on my Microsoft surface laptop. I red in 
> reddit that more people have this problem,
> So I wanted to ask if you can help me with that or if I maybe just have to 
> wait until you update tails to make it
> Accessable also for newer computers.

In general we don't have resources to add support ourselves for
specific computers, so we rely on work happening upstream and
in Debian.

However, if you find out what needs to be added/changed in Tails to
fix this, we can certainly check if it's feasible (for example, we
could add missing firmware).

> So in my case my mouse and keyboard is not reacting after rebooting.

In any case, it could be useful to other users to know this is to be
expected (via our known issues page). I'm putting you in touch with
our Help Desk, who will ask you more information we need for this to
happen, starting with… which Microsoft Surface laptop, exactly,
as I see there are plenty:
https://en.wikipedia.org/wiki/Microsoft_Surface#Surface_Laptop_line
___
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] Using TAILS

[sajolida]

safe-the-planet via Tails-dev:
> Dear Ladies and Gentlemen,

Hi,

> 1) There are very good videos on YT how to install TAILS. We have
> already written out the procedure and wanted to install TAILS soon. But
> unfortunately you need two USB sticks for it. Now we have seen on the
> homepage of TAILS that you can also do this directly in Linux - in the
> terminal. This is faster and only one USB stick is needed. Not that we
> only have one USB stick, we find the installation via terminal easier.
> Do we see it right, that you can only copy the commands and paste them
> into the terminal? You have to be a little careful to use the right name
> ... But otherwise we find it easier.

Our official instructions have not required 2 USB sticks since October
2018. That's why we don't recommend YouTube videos: they tend to be very
outdated and confuse more than help.

Please refer only to https://tails.boum.org/install/.

> 2) We always read that you should NOT use TAILS or the TOR browser with
> VPN. What do you recommend? Why is it more insecure to use with VPN,
> should it be the case? Of course, we assume VPN's that have an
> appropriate reputation and can be classified safe. Otherwise, of course,
> the situation is clear.

See our FAQ on VPNs: https://tails.boum.org/support/faq/#vpn.

> 3) Why is the homepage called "tails.boum.org"? Why "boum"?

Our website used to be hosted by boum.org, but not anymore. We've been
looking for a better domain name but haven't got one just yet.

> 4) In the persistent folder the data is secure but the folder is
> visible. Will TAILS eventually come with programs similar to Veracrypt?

Not super likely: https://gitlab.tails.boum.org/tails/tails/-/issues/5929.

> Or can these invisible folders be displayed with appropriate software?

See https://tails.boum.org/doc/encryption_and_privacy/veracrypt/.

-- 
sajolida
Tails — https://tails.boum.org/
UX · Fundraising · Technical Writing



OpenPGP_signature
Description: OpenPGP digital 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] Question: Tails in undercover mode?

[Hans]

Hi folks,

ok, I have understood, that it is not easy to install a windowmanager looking 
like MacOS or Windows.

Also, you told me, you are using Gnome. 

Well, thinking about this, please allow me a very personal feedback:

1. The choice of using Gnome is IMO not very lucky. Gnome is big, Gnome is 
eating much ressources. 

2. I would use LXDE or better XFCE, because they are very small and tiny. XFCE 
also has the advantage, to use the very fine package "kali-undercover", which 
let XFCE look like Windows10.

3. The lack of TAILS in 32-bit is a great disadvantage, because it can not be 
used on netbooks, like EEEPC or others. I believe, many people are using these 
still. However, I agree, that journalists today might use all 64-Bit 
notebooks.

4. Tails should be for everyone, so it should be small and tiny, so it can be 
run smoothly also on older hardware. I am sure, especially in poorer 
countries, people are not able, to buy the newest hardware. 


Last but not least: Thank you for the documentation, how to build tails. This 
will allow me, to build a tails version according to my own needs. Of course, 
there is also much to learn.

Generally: Thank you all for the hard work - it is really needed and 
appreceated in this corrupt world!

Best regards

Hans

signature.asc
Description: This is a digitally signed message part.
___
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] Question: Tails in undercover mode?

[alienpup]

All, 

A quick follow-up to suggest that clearing the Tails screen saver/slide show 
require the key-press combination used to invoke it. A passer-by could 
otherwise restore the screen and reveal Tails with a single key press. 

This should perhaps be the case even when an admin password is set, as Tails' 
password entry screen doesn't look very "Windows".

regards,
alienpup

alienpup wrote:
> All,
> 
> I believe hiding Tails' UI would prove too resource intensive and 
> ultimately futile. It just can't be done and maintained well enough to 
> fool sharp-eyed observers. After all, the first thing a passer-by does 
> is study your screen. It's human nature and very hard to resist.
> 
> Tails users could however benefit greatly from a simple slideshow 
> screen saver that can be invoked instantly. Tails could ship with a few 
> uninteresting "stock" images and provide users the option of adding 
> more. Once invoked, Tails could not be distinguished from Windows. 
> Screen locking would remain dependent upon setting an admin password. 
> 
> regards,
> alienpup
> 
> 
> geb wrote:
> > Hello,
> > 
> > Hans:
> > > Dear list,
> > > 
> > > I am wondering, why tails no more get an undercover mode. IMO it is very 
> > > dangerous for users, if their window manager is not looking like the 
> > > normal 
> > > window manager used everywhere, especially in countries, where any 
> > > "strange" 
> > > desktop might cause attention on authorities.
> > > 
> > > This problem could be easily solved. Most users are running either 
> > > windows or 
> > > MacOS. For windows you can just use XFCE + kali-undercover, for 
> > > Mac-design 
> > > there are several windowmanagers available (there is coming ElementaryOS 
> > > in my 
> > > mind).
> > > 
> > > As you do only need the window-manager design, there should be no risk 
> > > change.
> > > 
> > > I might remember, tails got this option some years ago, but somehow this 
> > > is 
> > > gone. Dunno why
> > 
> > This camouflage option has been removed because the theme that proposed
> > this feature was not working anymore, and because of lack of resources
> > to work on it. You can read a bit more about that here :
> > 
> > https://gitlab.tails.boum.org/tails/tails/-/issues/10830
> > 
> > https://gitlab.tails.boum.org/tails/blueprints/-/wikis/update_camouflage_for_jessie/
> > 
> > Unfortunately, the problem is not that easy to solve. As you can see on
> > the previous links, reintroducing this feature using gnome themes would
> > requires lot of work (at least at the moment these links were updated).
> > 
> > Proposing other desktop-environments may looks simpler, but it would
> > requires even more work, for UX, documentation, testing, ensuring
> > everything works fine, keeping the image small enough etc, not only when
> > integrating these desktop environments, but also for every releases.
> > 
> > That said, maybe things have improved since last updates on the previous
> > links. So if you are interested to give a deeper look of how it could be
> > done in practice, that may be a small but important step :-). I did a
> > quick testing of https://www.gnome-look.org/p/1216281/ (which is nice
> > also because it has been maintained since a few years now). It seems the
> > menus are only for Cinnamon, but maybe I did not tested it enough.
> > 
> > --
> > geb
> > ___
> > 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 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 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] Question: Tails in undercover mode?

[alienpup]

All,

I believe hiding Tails' UI would prove too resource intensive and ultimately 
futile. It just can't be done and maintained well enough to fool sharp-eyed 
observers. After all, the first thing a passer-by does is study your screen. 
It's human nature and very hard to resist.

Tails users could however benefit greatly from a simple slideshow screen saver 
that can be invoked instantly. Tails could ship with a few uninteresting 
"stock" images and provide users the option of adding more. Once invoked, Tails 
could not be distinguished from Windows. Screen locking would remain dependent 
upon setting an admin password. 

regards,
alienpup


geb wrote:
> Hello,
> 
> Hans:
> > Dear list,
> > 
> > I am wondering, why tails no more get an undercover mode. IMO it is very 
> > dangerous for users, if their window manager is not looking like the normal 
> > window manager used everywhere, especially in countries, where any 
> > "strange" 
> > desktop might cause attention on authorities.
> > 
> > This problem could be easily solved. Most users are running either windows 
> > or 
> > MacOS. For windows you can just use XFCE + kali-undercover, for Mac-design 
> > there are several windowmanagers available (there is coming ElementaryOS in 
> > my 
> > mind).
> > 
> > As you do only need the window-manager design, there should be no risk 
> > change.
> > 
> > I might remember, tails got this option some years ago, but somehow this is 
> > gone. Dunno why
> 
> This camouflage option has been removed because the theme that proposed
> this feature was not working anymore, and because of lack of resources
> to work on it. You can read a bit more about that here :
> 
> https://gitlab.tails.boum.org/tails/tails/-/issues/10830
> 
> https://gitlab.tails.boum.org/tails/blueprints/-/wikis/update_camouflage_for_jessie/
> 
> Unfortunately, the problem is not that easy to solve. As you can see on
> the previous links, reintroducing this feature using gnome themes would
> requires lot of work (at least at the moment these links were updated).
> 
> Proposing other desktop-environments may looks simpler, but it would
> requires even more work, for UX, documentation, testing, ensuring
> everything works fine, keeping the image small enough etc, not only when
> integrating these desktop environments, but also for every releases.
> 
> That said, maybe things have improved since last updates on the previous
> links. So if you are interested to give a deeper look of how it could be
> done in practice, that may be a small but important step :-). I did a
> quick testing of https://www.gnome-look.org/p/1216281/ (which is nice
> also because it has been maintained since a few years now). It seems the
> menus are only for Cinnamon, but maybe I did not tested it enough.
> 
> --
> geb
> ___
> 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 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] Question: Tails in undercover mode?

[geb]

Hello,

Hans:
> Dear list,
> 
> I am wondering, why tails no more get an undercover mode. IMO it is very 
> dangerous for users, if their window manager is not looking like the normal 
> window manager used everywhere, especially in countries, where any "strange" 
> desktop might cause attention on authorities.
> 
> This problem could be easily solved. Most users are running either windows or 
> MacOS. For windows you can just use XFCE + kali-undercover, for Mac-design 
> there are several windowmanagers available (there is coming ElementaryOS in 
> my 
> mind).
> 
> As you do only need the window-manager design, there should be no risk change.
> 
> I might remember, tails got this option some years ago, but somehow this is 
> gone. Dunno why

This camouflage option has been removed because the theme that proposed
this feature was not working anymore, and because of lack of resources
to work on it. You can read a bit more about that here :

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

https://gitlab.tails.boum.org/tails/blueprints/-/wikis/update_camouflage_for_jessie/

Unfortunately, the problem is not that easy to solve. As you can see on
the previous links, reintroducing this feature using gnome themes would
requires lot of work (at least at the moment these links were updated).

Proposing other desktop-environments may looks simpler, but it would
requires even more work, for UX, documentation, testing, ensuring
everything works fine, keeping the image small enough etc, not only when
integrating these desktop environments, but also for every releases.

That said, maybe things have improved since last updates on the previous
links. So if you are interested to give a deeper look of how it could be
done in practice, that may be a small but important step :-). I did a
quick testing of https://www.gnome-look.org/p/1216281/ (which is nice
also because it has been maintained since a few years now). It seems the
menus are only for Cinnamon, but maybe I did not tested it enough.

--
geb
___
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] NSA tails and closed code

[Austin English]

On Tue, Jun 15, 2021, 16:42 syster via Tails-dev  wrote:

> What I always thought what would be nice:
>
> Having 2 versions of Tails. One pure and free, and one with proprietary
> code that is needed to run some hardware.
>
> If one has a wifi adapter that runs on free software, most if not all of
> the proprietary code that is included in Tails is of no use for that
> person, at least that's how I understand it. Such an wifi adapter can be
> be bought for the cost of an USB stick.
>

That has the downside of doubling development/testing efforts, and
confusion for users.

>
___
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] NSA tails and closed code

[syster via Tails-dev]

What I always thought what would be nice:

Having 2 versions of Tails. One pure and free, and one with proprietary 
code that is needed to run some hardware.


If one has a wifi adapter that runs on free software, most if not all of 
the proprietary code that is included in Tails is of no use for that 
person, at least that's how I understand it. Such an wifi adapter can be 
be bought for the cost of an USB stick.



On 6/14/21 10:01 AM, boyska wrote:

Georg Koppen:

anonym:

Romper Stomper via Tails-dev:

and why are there closed codes in “tails”?


I guess you are referring to the firmwares required for hardware
support? If we didn't ship these firmwares Tails would not run on most
hardware. It's a necessary trade-off.


Is there a list of those firmwares somewhere (I couldn't find anything
on the Tails website about that topic after searching a bit) or is it
"just" a Debian package taken 1:1 from upstream?


https://gitlab.tails.boum.org/tails/tails/-/blob/stable/config/chroot_local-packageslists/tails-common.list#L247 


this is the list of debian packages Tails installs to have firmwares


___
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] NSA tails and closed code

[boyska]

Georg Koppen:

anonym:

Romper Stomper via Tails-dev:

and why are there closed codes in “tails”?


I guess you are referring to the firmwares required for hardware
support? If we didn't ship these firmwares Tails would not run on most
hardware. It's a necessary trade-off.


Is there a list of those firmwares somewhere (I couldn't find anything
on the Tails website about that topic after searching a bit) or is it
"just" a Debian package taken 1:1 from upstream?


https://gitlab.tails.boum.org/tails/tails/-/blob/stable/config/chroot_local-packageslists/tails-common.list#L247
this is the list of debian packages Tails installs to have firmwares

--
boyska
___
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] NSA tails and closed code

[Georg Koppen]

anonym:
> Romper Stomper via Tails-dev:
>> Is it true that the “tails” ports are controlled by the NSA?
> 
> I'm not sure what you mean with "ports". However, NSA doesn't control
> anything related to Tails to our knowledge, and we do what we can to
> defend against it, e.g.: https://tails.boum.org/news/reproducible_Tails/
> 
> and why are there closed codes in “tails”?
> 
> I guess you are referring to the firmwares required for hardware
> support? If we didn't ship these firmwares Tails would not run on most
> hardware. It's a necessary trade-off.

Is there a list of those firmwares somewhere (I couldn't find anything
on the Tails website about that topic after searching a bit) or is it
"just" a Debian package taken 1:1 from upstream?

Georg



OpenPGP_signature
Description: OpenPGP digital 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] NSA tails and closed code

[anonym]

Romper Stomper via Tails-dev:

Is it true that the “tails” ports are controlled by the NSA?


I'm not sure what you mean with "ports". However, NSA doesn't control anything 
related to Tails to our knowledge, and we do what we can to defend against it, e.g.: 
https://tails.boum.org/news/reproducible_Tails/

and why are there closed codes in “tails”?

I guess you are referring to the firmwares required for hardware support? If we 
didn't ship these firmwares Tails would not run on most hardware. It's a 
necessary trade-off.

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] boot tails iso with grub

[intrigeri]

Hi,

the ubuntushop.eu folks told me privately on August 16 that they were
migrating away from Tails, as agreed back in January. Thanks!

For everyone else who's following along, it seems this migration is
not completed yet though:

 - https://www.ubuntushop.be/index.php/en/opensource-notebooks/
   still mentions "Tails live boot option"

 - 
https://www.ubuntushop.be/index.php/en/opensource-notebooks/kodachi-notebooks.html
   still mentions "Tails boot option".

Cheers,
-- 
intrigeri
___
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] boot tails iso with grub

[intrigeri]

Hi,

linux-service:
> no problem. I will consider ending this onboard tails.

I still see "The Amnesic Incognito Live System notebook" listed:
https://www.ubuntushop.be/index.php/en/opensource-notebooks/tails-notebooks.html

Did anything change, since we discussed this topic in January,
regarding how you ship Tails with these machines?

Cheers,
-- 
intrigeri
___
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] boot tails iso with grub

[Peter N. Glaskowsky]

> On Jan 25, 2019, at 2:10 AM, intrigeri  wrote:
> 
> I'd much rather see us work on
> making "installing and running Tails on an internal hard drive"
> a first-class citizen: it would benefit much more people.

I agree! As I’ve been saying for many years now. :-)

And the other thing I’ve been saying is that HD-resident Tails would be 
especially useful if it works on a Windows tablet, as there are still many of 
these priced around US $100. Such machines are cheap enough and small enough to 
act as companion devices for people who also have laptops.

While I’m thinking about it, it would be useful if Tails, while running from a 
hard disk, could still respond to the sudden removal of a USB flash drive in 
the usual way. The drive shouldn’t have to have anything on it, nor should it 
be necessary to mount it. Ideally, any kind of USB device connected to an 
external port should also be usable (a keyboard or mouse, for example). It 
should be enough to select a USB device from a panel icon so that the memory 
erasure procedure is triggered by a surprise removal.

Best regards,

. png

___
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] Working Tails on Mac

[intrigeri]

Hi Daniel,

Daniel Rostamloo:
>I've recently discovered your wonderful project and decided to explore
> as much as I could with my MacBook Pro (Early 2015). Of course, I soon
> found out that many users have had difficulty implementing Tails alongside
> their macOS systems. After doing some research and several trials, I've
> found a way to operate the OS without the use of additional boot managers
> -- such as rEFInd -- and I hope your development team can use this
> information to ease the experience for us Mac users.

Good news: Tails 3.12, to be released on January 29, will fix these
problems :)

Cheers,
-- 
intrigeri
___
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] New Tails Mirror

[u]

Hi Adam,

thank you for setting up a mirror.

Please use tails-mirr...@boum.org for future communication about a mirror.

I am forwarding your message there.

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.

Re: [Tails-dev] New Tails Mirror

[sajolida]

Douglas "Hardway" Goncz:
> Hello!

Hi Douglas and welcome :)

> This is my first post to the development list here. I am as usual using
> Google Voice due to some disability. I'd like to suggest the tales be
> released in a netboot version if that suggestion has not been made before.

I'm not sure to understand what you mean by "netboot", do you mean PXE?

https://en.wikipedia.org/wiki/Preboot_Execution_Environment

Can you elaborate on which user scenarios would benefit from a netboot?

-- 
sajolida
___
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] Build Tails on MacBook 2015?

[drwhax]

On 2018-06-08 15:49, u wrote:
>
> 
> 
>> Any chance to build Tails natively on macOS, without any VM? Unfortunately I 
>> don’t own any other hardware as of now.
> 
> I cannot answer this question, but I believe not.
> 

This is correct, building Tails natively on MacOS is not something that
is supported.

More information on how to build on Debian stretch here:
https://tails.boum.org/contribute/build/

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] Build Tails on MacBook 2015?

[u]

Hi Marco,

Marco Betschart:
> A quick heads up on the „Waiting for IP address…“ issue:
> 
> Seems like this is macOS/VMWare Fusion related. Trying to vagrant up a 
> regular debian/stretch64 shows the same symptoms.
> Conclusion: VirtualBox does not support passing VT-x, VMWare Fusion does not 
> seem to handle vagrant up as it expects.

That's "good" news, or at least we now know what happens.

> Any chance to build Tails natively on macOS, without any VM? Unfortunately I 
> don’t own any other hardware as of now.

I cannot answer this question, but I believe not.

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.

Re: [Tails-dev] Build Tails on MacBook 2015?

[Marco Betschart]

A quick heads up on the „Waiting for IP address…“ issue:

Seems like this is macOS/VMWare Fusion related. Trying to vagrant up a regular 
debian/stretch64 shows the same symptoms.
Conclusion: VirtualBox does not support passing VT-x, VMWare Fusion does not 
seem to handle vagrant up as it expects.

Any chance to build Tails natively on macOS, without any VM? Unfortunately I 
don’t own any other hardware as of now.


> Am 05.06.2018 um 09:59 schrieb intrigeri :
> 
> Marco Betschart:
>> I was able to fix that; VMWare does support passing VT-x to
>> the guest.
> 
> Progress, good!
> 
>> But now I’m stuck with this IP Address issue. For some reason, the
>> vagrant machine is not capable in getting one. Any idea how to fix
>> this? Below the full output I get - the build stucks while waiting
>> for the IP address. Please note: this is the master branch of the
>> repo, no changes made from my end.
> 
>> $: rake build
>> Using HTTP proxy: http://vagrant-stretch:3142
>> Bringing machine 'default' up with 'libvirt' provider...
>> [...]
>> ==> default: Starting domain.
>> ==> default: Waiting for domain to get an IP address...
> 
> I don't know what's going on. I suggest:
> 
> - looking at the logs in /var/log/libvirt/qemu/
>  (probably:
>  tails-builder-amd64-stretch-20180301-2f443fafad_default.log)
> - looking at the systemd Journal with the journalctl command
> - checking that your VMWare VM has enough RAM; I think you should give
>  it at least 1.5 GiB and even that might not be enough so if you can,
>  try with 3 GiB or more
> ___
> 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 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] Basing Tails on quarterly snapshots of Debian Testing: status update… and next steps?

[intrigeri]

Hi,

intrigeri:
> I'm not waiting for feedback anymore on this thread, but I still would
> love to read what you folks think about this.

Ten days later, I have to acknowledge this topic is less exciting to
our community than I thought, and/or everybody is too busy to think
about it.

> Meanwhile:
> sajolida:
>> intrigeri:
>>> When I wrote "I can look into the money aspect more closely" I didn't
>>> mean to put this back on the table. Instead, I meant looking into
>>> re-purposing money that's *already* budgeted elsewhere for purposes
>>> I find questionable at the moment. I'd rather not elaborate on
>>> a public mailing list though.

>> I'm fine with repurposing!

> Cool, I'll look into it.

I've been over-enthusiastic here: there are other, more pressing
discussions I need to have with the same people, so I'll put this on
the backburner until we have a team, plan and budget for the next
years regarding such big migrations.

So with these two above updates in mind, I think the only sensible way
to go is to defer this until April or May. I'll update tickets and
blueprints accordingly, and will then update version numbers for next
year (*if* we eventually decide to release Tails based on Buster at
some point in 2018 Q3 or Q4, then we may have to renumber again, but
meanwhile we do need adequate version numbers).

Cheers,
-- 
intrigeri
___
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] Basing Tails on quarterly snapshots of Debian Testing: status update… and next steps?

[sajolida]

intrigeri:
> sajolida:
>> Speaking as an accountant: I'm worried about taking important money
>> decisions before the end of the fundraising campaign and our budget
>> planning which will happen in February.
>> Because I wouldn't like to commit to paying work on "rolling Tails"
>> (what's the name of your project by the way?) to then realize two
>> months later that we will be very short on other core budget lines.
>> This applies to technical writing as well: I'd rather have more
>> money for core technical writing in 2018 than money for technical
>> writing on "rolling Tails" now.
> 
> Absolutely. We've already discussed this elsewhere and I think
> I already made it clear from the beginning that I agree with all this.
> 
> When I wrote "I can look into the money aspect more closely" I didn't
> mean to put this back on the table. Instead, I meant looking into
> re-purposing money that's *already* budgeted elsewhere for purposes
> I find questionable at the moment. I'd rather not elaborate on
> a public mailing list though.

I'm fine with repurposing!

> Regarding the project name: currently the best we have is "Basing
> Tails on quarterly snapshots of Debian Testing", sorry.
> Improvements are welcome. "rolling" means something different, let's
> not use it.

Ok :)
___
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] Changing Tails 3.0 release date?

[Marco Calamari]

On Thu, 2017-06-01 at 10:18 +0200, intrigeri wrote:
> hi!
> 
> anonym:
> > intrigeri:
> > > I'll make the call as the 3.0 release manager if no consensus
> > > emerges,
> 
> After re-reading this discussion, it appears that the only people
> substantially affected by this decision (apart of Tails users of
> course) will be myself and our usual manual testers. So I'll make the
> call by the end of this week, depending on how I feel about committing
> to RM'ing an extra release. I may follow anonym's very reasonable
> position, or go crazy for the sake of communication and
> Debian/Tails/FOSS relationships. I'm undecided yet and want to sleep
> on it and balance all this very carefully.
> 
> > > A. Coordinate Tails 3.0 and Debian Stretch releases
> 
> [...]
> > > B. Don't bother and proceed as our calendar says
> > >  - Option A forces us to integrate Tor Browser 7.0 into Tails 2.x:
> > >    this work has been based on the Tails 3.x codebase so far. I don't
> > >    know if rebasing it onto the stable branch would be trivial, or
> > >    a lot of work. anonym, what's your feeling?
> > Cherry-picking these commits will not result in any difficult conflicts 
> > (it's mostly
> > about s/32/64/, and some jessie vs stretch test suite images). But there 
> > could be
> > issues with running 7.0a4 on Tails Jessie/i386 -- we haven't tested the 7.x 
> > series at
> > all on that platform. Still I definitely believe it quite a bit more likely 
> > to Just
> > Work rather than introduce issues we don't see on Tails Stretch/amd64. So 
> > my feeling
> > is that this should be an hour of work.
> 
> OK, thanks for the insight!
> 
> > >  - Option B is less work, therefore it increases the chances that we
> > >    manage to make 3.0 build reproducibly, which gives us good
> > >    communication opportunities. So:
> > > 
> > >    [...]
> > > 
> > > * anonym (who is our lead developer on the reproducibility front):
> > >   if we go with option B, how confident are you that 3.0 can
> > >   build reproducibly? #12608, #12567 and #12566 should be good
> > >   starting points.
> > At least for me, locally, the only problem I see (after applying all 
> > unmerged fixes)
> > is that Chris' patch for #12567 seems to miss some case. I've asked for an 
> > ETA of
> > a fix. So assuming Chris is available, or I manage to identify and fix the 
> > issue,
> > it's looking really good. :)
> 
> Great :)
> 
> > > Other pros/cons or thoughts?
> > A con for option A:
> >  * Users will be prompted to do two updates within four days, which
> >    is a bit much both in terms of nagging frequency, bandwidth
> >    usage, and pure inconvenience.
> 
> Absolutely. This will be particularly painful for those who will have
> to do a manual upgrade to 2.12.1, as everyone will have to do a manual
> upgrade to 3.0 anyway.
> 
> On the other hand, if 2.12.1 is a thing, we give users almost two
> months to upgrade to 3.0 (vs. 0 days if we don't release 2.12.1),
> which is nice as they're often scared by such drastic change; also,
> anyone affected by a serious regression can temporarily downgrade to
> 2.12.1 until Tails 3.1 fixes their problem.
> 
> So all in all it's not clear cut to me which option provides the
> greater UX (once considering dozens of thousands of real-world users,
> and not only some theoretical, ideal one who would immediately upgrade
> to 3.0 and not have any big problem with it).

Agreed 
IMHO users come first ... continuity is not an optional.
3.x can wait

> > I'd also like to stress (pun intended!) the fact that option A's "more 
> > work" (as in
> > an extra release, 2.12.1) is not so suitable at this time. I think we're 
> > collectively
> > exhausted, and should try to take whatever breaks we can.
> 
> OK, thanks for sharing, I want to take this into account.
> 
> I'm committed to be the RM for 3.0 already; I understand you don't
> feel like taking care of 2.12.1 so let's assume I would handle both
> releases myself (if I convince myself that option A is the way to go).
> And then the additional work is only on my shoulders (I don't feel
> exhausted personally) and manual testers' (no idea how they feel about
> it, but we had no problem getting manual testers recently, did we?).
> 
> In passing: we have 4 emergency releases budgeted this year, and we
> did none of them yet. Given this data + the feelings you're sharing,
> I think we should acknowledge that we probably won't do more than
> 2 emergency releases this year. If you agree, I'll update our
> accounting accordingly, so nobody counts on (paid) RM work that's
> unlikely to happen in practice, first because there's no need for it,
> second because our RMs are not exactly thrilled at the idea of doing
> this work. Fair enough?
> 
> > Yup, I'm quite a lot in favor of option B.
> 
> Got it.
> 
> > > The decision algorithm I intend to use is:
> > > 
> > >  - If the reproducible builds people tell me they can make 3.0
> > >    reproducible and communicate 

Re: [Tails-dev] Changing Tails 3.0 release date?

[intrigeri]

hi!

anonym:
> intrigeri:
>> I'll make the call as the 3.0 release manager if no consensus
>> emerges,

After re-reading this discussion, it appears that the only people
substantially affected by this decision (apart of Tails users of
course) will be myself and our usual manual testers. So I'll make the
call by the end of this week, depending on how I feel about committing
to RM'ing an extra release. I may follow anonym's very reasonable
position, or go crazy for the sake of communication and
Debian/Tails/FOSS relationships. I'm undecided yet and want to sleep
on it and balance all this very carefully.

>> A. Coordinate Tails 3.0 and Debian Stretch releases
[...]
>> B. Don't bother and proceed as our calendar says

>>  - Option A forces us to integrate Tor Browser 7.0 into Tails 2.x:
>>this work has been based on the Tails 3.x codebase so far. I don't
>>know if rebasing it onto the stable branch would be trivial, or
>>a lot of work. anonym, what's your feeling?

> Cherry-picking these commits will not result in any difficult conflicts (it's 
> mostly
> about s/32/64/, and some jessie vs stretch test suite images). But there 
> could be
> issues with running 7.0a4 on Tails Jessie/i386 -- we haven't tested the 7.x 
> series at
> all on that platform. Still I definitely believe it quite a bit more likely 
> to Just
> Work rather than introduce issues we don't see on Tails Stretch/amd64. So my 
> feeling
> is that this should be an hour of work.

OK, thanks for the insight!

>>  - Option B is less work, therefore it increases the chances that we
>>manage to make 3.0 build reproducibly, which gives us good
>>communication opportunities. So:
>> 
>>[...]
>>
>> * anonym (who is our lead developer on the reproducibility front):
>>   if we go with option B, how confident are you that 3.0 can
>>   build reproducibly? #12608, #12567 and #12566 should be good
>>   starting points.

> At least for me, locally, the only problem I see (after applying all unmerged 
> fixes)
> is that Chris' patch for #12567 seems to miss some case. I've asked for an 
> ETA of
> a fix. So assuming Chris is available, or I manage to identify and fix the 
> issue,
> it's looking really good. :)

Great :)

>> Other pros/cons or thoughts?

> A con for option A:

>  * Users will be prompted to do two updates within four days, which
>is a bit much both in terms of nagging frequency, bandwidth
>usage, and pure inconvenience.

Absolutely. This will be particularly painful for those who will have
to do a manual upgrade to 2.12.1, as everyone will have to do a manual
upgrade to 3.0 anyway.

On the other hand, if 2.12.1 is a thing, we give users almost two
months to upgrade to 3.0 (vs. 0 days if we don't release 2.12.1),
which is nice as they're often scared by such drastic change; also,
anyone affected by a serious regression can temporarily downgrade to
2.12.1 until Tails 3.1 fixes their problem.

So all in all it's not clear cut to me which option provides the
greater UX (once considering dozens of thousands of real-world users,
and not only some theoretical, ideal one who would immediately upgrade
to 3.0 and not have any big problem with it).

> I'd also like to stress (pun intended!) the fact that option A's "more work" 
> (as in
> an extra release, 2.12.1) is not so suitable at this time. I think we're 
> collectively
> exhausted, and should try to take whatever breaks we can.

OK, thanks for sharing, I want to take this into account.

I'm committed to be the RM for 3.0 already; I understand you don't
feel like taking care of 2.12.1 so let's assume I would handle both
releases myself (if I convince myself that option A is the way to go).
And then the additional work is only on my shoulders (I don't feel
exhausted personally) and manual testers' (no idea how they feel about
it, but we had no problem getting manual testers recently, did we?).

In passing: we have 4 emergency releases budgeted this year, and we
did none of them yet. Given this data + the feelings you're sharing,
I think we should acknowledge that we probably won't do more than
2 emergency releases this year. If you agree, I'll update our
accounting accordingly, so nobody counts on (paid) RM work that's
unlikely to happen in practice, first because there's no need for it,
second because our RMs are not exactly thrilled at the idea of doing
this work. Fair enough?

> Yup, I'm quite a lot in favor of option B.

Got it.

>> The decision algorithm I intend to use is:
>> 
>>  - If the reproducible builds people tell me they can make 3.0
>>reproducible and communicate about it _only_ if we pick option B,
>>then I'll go this way.

[...]

> [I might consider sabotaging option A by pretending, as
> a reproducible buids person, that "Tails 3.0 will only be
> reproducible if we pick option B". Will I have to? :)]

I'm sorry I even asked this question, as it doesn't make any sense:
the only work option A adds to our reproducible builds 

Re: [Tails-dev] Changing Tails 3.0 release date? [Was: Planned release of stretch on 2017-06-17 and the last weeks up to the release]

[anonym]

intrigeri:
> Hi,
> 
> ni...@thykier.net:
>> Release date
>> 
> 
>> We plan to release on 2017-06-17.
> 
>> […]
> 
> Yeah! I'm relieved this is now public info and we don't have to
> discuss our plans privately within a tiny Tails release managers
> cabal anymore.
> 
> So, what should we do about it? I'll make the call as the 3.0 release
> manager if no consensus emerges, but I first need some input from
> a few people (at least anonym, Ulrike, and sajolida) to make up my
> mind, so please read on :)
> 
> I see two options:
> 
> A. Coordinate Tails 3.0 and Debian Stretch releases
> 
>We can prepare two releases at the same time: 2.12.1 and 3.0.
>Both should be ready (including release notes, uploading ISO,
>manual testing) on June 13. But on June 13 we release 2.12.1 only
>(we have to release _something_ on that day anyway due to the
>Firefox security updates), and we wait until June 17 to publish
>Tails 3.0, at the same time as Debian Stretch.
> 
> B. Don't bother and proceed as our calendar says
> 
>I.e. simply release Tails 3.0 on June 13.

I agree these are the only reasonable options we have.

> Pros and cons:
> 
>  - Option A costs us one more "Emergency releases" i.e. 2.25 days
>of work (release management + manual testing).

Ouch.

>  - Option A forces us to integrate Tor Browser 7.0 into Tails 2.x:
>this work has been based on the Tails 3.x codebase so far. I don't
>know if rebasing it onto the stable branch would be trivial, or
>a lot of work. anonym, what's your feeling?

Cherry-picking these commits will not result in any difficult conflicts (it's 
mostly about s/32/64/, and some jessie vs stretch test suite images). But there 
could be issues with running 7.0a4 on Tails Jessie/i386 -- we haven't tested 
the 7.x series at all on that platform. Still I definitely believe it quite a 
bit more likely to Just Work rather than introduce issues we don't see on Tails 
Stretch/amd64. So my feeling is that this should be an hour of work.

>  - Option B is less work, therefore it increases the chances that we
>manage to make 3.0 build reproducibly, which gives us good
>communication opportunities. So:
> 
>[...]
>
> * anonym (who is our lead developer on the reproducibility front):
>   if we go with option B, how confident are you that 3.0 can
>   build reproducibly? #12608, #12567 and #12566 should be good
>   starting points.

At least for me, locally, the only problem I see (after applying all unmerged 
fixes) is that Chris' patch for #12567 seems to miss some case. I've asked for 
an ETA of a fix. So assuming Chris is available, or I manage to identify and 
fix the issue, it's looking really good. :)

>  - Option A gives good opportunities for communication:
> 
> * On Tails' side: we can point out that we're releasing on the
>   exact same day as Debian (which is a stronger symbol than 4 days
>   earlier); I would love to see this happen as a way to re-affirm
>   our strong relationship with Debian, which has been very
>   important so far in terms of how we fit into the Debian
>   community and the broader FOSS world.
> 
> * On Debian's side: they can mention our release in
>   their communication. But TBH they can probably do it anyway
>   even if Tails based on Stretch is out earlier than June 17.
> 
> Other pros/cons or thoughts?

A con for option A:

 * Users will be prompted to do two updates within four days, which is a bit 
much both in terms of nagging frequency, bandwidth usage, and pure 
inconvenience.

I'd also like to stress (pun intended!) the fact that option A's "more work" 
(as in an extra release, 2.12.1) is not so suitable at this time. I think we're 
collectively exhausted, and should try to take whatever breaks we can.

Yup, I'm quite a lot in favor of option B.

> The decision algorithm I intend to use is:
> 
>  - If the reproducible builds people tell me they can make 3.0
>reproducible and communicate about it _only_ if we pick option B,
>then I'll go this way.
> 
>  - Otherwise, if the reproducible builds plans are less clear, then:
> 
> if it's not too hard to integrate Tor Browser 7.0 into Tails 2.x,
>and anonym+I find a way to share the additional RM'ing work,
>then I'll pick option A
> 
> else, I'll fallback to option B.

[I might consider sabotaging option A by pretending, as a reproducible buids 
person, that "Tails 3.0 will only be reproducible if we pick option B". Will I 
have to? :)]

>> The final weeks up to the release
>> =
> 
> [...]
> 
>> In the last week prior to the freeze, testing will be completely
>> frozen and only emergency bug fixes will be considered in this period.
>> Please consider Friday the 2017-06-09 at 13:00 UTC the absolute last
>> moment for changes to stretch.
> 
> So I plan to bump our APT snapshots serials on 2017-06-09: #12609.

Huh, I thought we would stick 

Re: [Tails-dev] Changing Tails 3.0 release date? [Was: Planned release of stretch on 2017-06-17 and the last weeks up to the release]

[u]

Hi!

intrigeri:
> ni...@thykier.net:
>> Release date
>> 
> 
>> We plan to release on 2017-06-17.
> 
> I see two options:
> 
> A. Coordinate Tails 3.0 and Debian Stretch releases
> 
>We can prepare two releases at the same time: 2.12.1 and 3.0.
>Both should be ready (including release notes, uploading ISO,
>manual testing) on June 13. But on June 13 we release 2.12.1 only
>(we have to release _something_ on that day anyway due to the
>Firefox security updates), and we wait until June 17 to publish
>Tails 3.0, at the same time as Debian Stretch.
> 
> B. Don't bother and proceed as our calendar says
> 
>I.e. simply release Tails 3.0 on June 13.
> 
> Pros and cons:
> 
>  - Option A costs us one more "Emergency releases" i.e. 2.25 days
>of work (release management + manual testing).
> 
>  - Option A forces us to integrate Tor Browser 7.0 into Tails 2.x:
>this work has been based on the Tails 3.x codebase so far. I don't
>know if rebasing it onto the stable branch would be trivial, or
>a lot of work. anonym, what's your feeling?
> 
>  - Option B is less work, therefore it increases the chances that we
>manage to make 3.0 build reproducibly, which gives us good
>communication opportunities. So:
> 
> * Ulrike (who committed to handle such communication) and sajolida
>   (who'll likely be needed to review it), do you think you can
>   realistically take advantage of this opportunity?

I think option B being less work in general, for all of us, so IMO we
should go this way instead. I can absolutely take the time to prepare
communication next week so that sajolida would have enough time to
review it.

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.

Re: [Tails-dev] Changing Tails 3.0 release date? [Was: Planned release of stretch on 2017-06-17 and the last weeks up to the release]

[sajolida]

intrigeri:
> ni...@thykier.net:
>> Release date
>> 
> 
>> We plan to release on 2017-06-17.
> 
>> […]
> 
> Yeah! I'm relieved this is now public info and we don't have to
> discuss our plans privately within a tiny Tails release managers
> cabal anymore.
> 
> So, what should we do about it? I'll make the call as the 3.0 release
> manager if no consensus emerges, but I first need some input from
> a few people (at least anonym, Ulrike, and sajolida) to make up my
> mind, so please read on :)

I'm sorry but I have no opinion about this. I think it's a cool idea and
I'm happy that it motivates you so do whatever option you like best and
I'll have the release notes ready by then.

Also, don't count on my for time communicating about this release
outside of writing the release notes (and I will mention the sync with
Debian in there of course).

And yes, I know I should start writing these notes early because they
are going to be long and complex and require a couple of round trips of
reviews :)
___
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] Testing Tails 3.0~rc1

[anonym]

[Sorry if this is a ~repost -- my MUA crashed while sending the email.]
anonym:
> During mine and intrigeri's upcoming Stretch sprint we plan to build and 
> upload Tails 3.0~rc1 on 2017-05-19 and release it on 2017-05-20. Testers, 
> please let me and intrigeri know:
> 
> * if you are available on 2017-05-19, late CEST
> 
> * if you are available on 2017-05-20, morning to afternoon, CEST.

We have bumped these dates with +1 day, so:

We plan to build and upload Tails 3.0~rc1 on 2017-05-20 and release it on 
2017-05-21.

Testers, please let me and intrigeri know:
 
* if you are available on 2017-05-20, late CEST

* if you are available on 2017-05-21, morning to afternoon, CEST.

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] Testing Tails 3.0~rc1

[anonym]

anonym:
> Hi,
> 
> During mine and intrigeri's upcoming Stretch sprint we plan to build and 
> upload Tails 3.0~rc1 on 2017-05-19 and release it on 2017-05-20. Testers, 
> please let me and intrigeri know:
> 
> * if you are available on 2017-05-19, late CEST
> 
> * if you are available on 2017-05-20, morning to afternoon, CEST.

We have bumped these dates with +1 day, so:

We plan to build and upload Tails 3.0~rc1 on 2017-05-20 and release it on 
2017-05-21.

Testers, please let me and intrigeri know:
 
* if you are available on 2017-05-20, late CEST

* if you are available on 2017-05-21, morning to afternoon, CEST.

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] Testing Tails 3.0~rc1

[anonym]

anonym:
> Hi,
> 
> During mine and intrigeri's upcoming Stretch sprint we plan to build and 
> upload Tails 3.0~rc1 on 2017-05-19 and release it on 2017-05-20. Testers, 
> please let me and intrigeri know:
> 
> * if you are available on 2017-05-19, late CEST
> 
> * if you are available on 2017-05-20, morning to afternoon, CEST.

These dates have been bumped +1 day, so:

We will build and upload Tails on 2017-05-20 and release it on 2017-05-21.

Testers, please let me and intrigeri know:

* if you are available on 2017-05-20, late CEST

* if you are available on 2017-05-21, morning to afternoon, CEST.

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] Porting Tails to Debian Stretch

[intrigeri]

intrigeri:
>  * late August: 1st sprint, only relevant for anonym and intrigeri
>  * November 14-18th: second sprint (in-person, organized by intrigeri)

These did happen! A report will be included in the November monthly report.

>  * late December: third sprint (remotely attended for everybody except
>two of us)

This will happen on December 20-23. Please consider joining!
There will be ways to help regardless of your skills.

>  * January 30 - Febuary 3: fourth sprint (remotely attended)
>  * March 13-17th: fifth sprint (in-person, organized by sajolida)

Some of these dates will likely change, stay tuned.

Cheers,
-- 
intrigeri
___
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] Modifying Tails-greeter to work outside of Tails

[adrian15]

El 07/10/16 a las 20:43, intrigeri escribió:

Hi adrian15!

adrian15:

   So, what I have been trying to do is to tweak minimally tails-greeter so 
that it
meets my needs. The final purpose of these tweaks is to convince you that some 
of
them are useful for tails-greeter so that you include into its
upstream code.


TL;DR: Next time I'll check this work I'll ask you for the right git 
branch to use as a base. And I will try to apply all the advice you give 
me in this reply.




OK, great. It would be nice if we could share one single codebase
indeed. Of course, for it to not be cause problems to us this must be
done in a super nice way, that does not make the code harder to
maintain on our side (e.g. using polymorphism and specialized classes
when doable rather than if/then conditionals, etc., the usual design
patterns to achieve such results).

I see.



   My tweaks are not perfect and thus there are some doubts which I need to 
clarify
with you. Let's start.


I'm sorry it took me so long to reply. I was trying to find time to do
it as well as I wanted, and obviously I won't have enough time soon,
so I'll at least answer whatever I can quickly.

No problem. I guess we are all busy.



1. tails-greeter Rescatux branch



The branch can be found here:



https://github.com/rescatux/tails-greeter/tree/rescatux_0.40b8


First of all: as told IRL last time we met, we have a WIP branch for
a totally revamped greeter, that rewrites most of the code and totally
changes the GUI. I think you'd better base your work on that one.

I'm not sure which one is the most up-to-date, I'll let you check
freshness of:

   feature/5464-revamp-ui
   feature/7550-revamp-phase1-prototype
   feature/revamp_phase1
   feature/revamp_phase1_user_strings


I used your stable branch for jessie so that I knew it worked.
Next time I'll check this work I'll ask you for the right branch to use.


2. Configuration files for enabling / disabling features. (Python)



When I talked to Intrigeri he pointed me to:
https://git-tails.immerda.ch/whisperback/tree/whisperBack/whisperback.py?h=feature/jessie
which used in turn config.py which was loaded from different places.



As I have noticed that tails-greeter now has config.py I have just modified it 
as you
can see in:
https://github.com/rescatux/tails-greeter/commit/863b13b7378b21af70783d36b61d5a8254a74675
.


I think the "if not" construction is OK for now as a tracer bullet
approach, but at some point that'll need to be refactored IMO.


I will ask for a OOP example in the future so that I can apply it.
I guess the problem it's in the gdm's Postlogin script which it's based 
on bash. I ask myself if it can be switched to python or not.



So I have added these boolean variables:



* tails_persistence_support
* tails_show_welcome_message



which are self explanatory.



2.1. Are those names correct or do you prefer them to be written in another way?
Or with another name?


Sounds good enough and easy to rename later while refactoring if needed.

Ok.



2.2. I guess I should add more Tails specific features such as the one about
physical security.


Your call obviously.

Ok.



2.3. I personally only use the Keyboard feature. Do you think there are other 
options
which could be useful for Debian by default?


No idea (but thanks for asking :)

Perhaps the "administration password" one? Also see the ones added or
planned in our new/future Greeter, such as local time & timezone.

Ok.



3. user user instead of amnesia user .



https://github.com/rescatux/tails-greeter/commit/f04280192440db280d53414e7cde99bc3017e52d
Debian Live default user is 'user', not 'amnesia'.
So that's a clear setting that should be set by Tails.


I certainly don't mind changing the default, as long as our own use
case is still supported. And we want to switch to "user" anyway:
https://labs.riseup.net/code/issues/5655 :)

That would simplify things indeed. That way I don't have to modify the user.



4. Configuration files for enabling / disabling features. (Bash)



4.1. One important part of tails-greeter is the PostLogin script from gdm3 
which it's
written in bash.




4.2. So as I was advised by intrigeri I rewrote the different tasks into 
functions.
I modified the code so that these functions were run conditioned to some
boolean variables.


Cool. These functions need a verb in their name, given their main
responsibility implies having side-effects.

I see. I could rename them. That's not a problem.


Looks like inter-dependencies between tasks are not handled, e.g.
some bits require GATHER_GENERAL_CONFIGURATION_ENABLED=yes to work.

Not sure what you mean but I'll take a look at it when I do.



4.4. I guess you would want another bash file to be sourced if someone wants to
config / modify it to suit their needs. But which filename path exactly?


Maybe /etc/tails-greeter/PostLogin.conf or similar?


Yeah, that might do it.



5. Apart from the tails-greeter branch with my changes, the fact that 

Re: [Tails-dev] Update Tails Documentation: JonDo Live-DVD discontinued

[intrigeri]

Hi,

lenn...@spambog.de:
> Correspondingly, JonDo Live DVD should be moved to the
> "Discontinued, abandoned or sleeping projects" section.

Done, thanks!

Cheers,
-- 
intrigeri
___
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] Modifying Tails-greeter to work outside of Tails

[intrigeri]

Hi adrian15!

adrian15:
>   So, what I have been trying to do is to tweak minimally tails-greeter so 
> that it
> meets my needs. The final purpose of these tweaks is to convince you that 
> some of
> them are useful for tails-greeter so that you include into its
> upstream code.

OK, great. It would be nice if we could share one single codebase
indeed. Of course, for it to not be cause problems to us this must be
done in a super nice way, that does not make the code harder to
maintain on our side (e.g. using polymorphism and specialized classes
when doable rather than if/then conditionals, etc., the usual design
patterns to achieve such results).

>   My tweaks are not perfect and thus there are some doubts which I need to 
> clarify
> with you. Let's start.

I'm sorry it took me so long to reply. I was trying to find time to do
it as well as I wanted, and obviously I won't have enough time soon,
so I'll at least answer whatever I can quickly.

> 1. tails-greeter Rescatux branch

> The branch can be found here:

> https://github.com/rescatux/tails-greeter/tree/rescatux_0.40b8

First of all: as told IRL last time we met, we have a WIP branch for
a totally revamped greeter, that rewrites most of the code and totally
changes the GUI. I think you'd better base your work on that one.

I'm not sure which one is the most up-to-date, I'll let you check
freshness of:

  feature/5464-revamp-ui
  feature/7550-revamp-phase1-prototype
  feature/revamp_phase1
  feature/revamp_phase1_user_strings

> 2. Configuration files for enabling / disabling features. (Python)

> When I talked to Intrigeri he pointed me to:
> https://git-tails.immerda.ch/whisperback/tree/whisperBack/whisperback.py?h=feature/jessie
> which used in turn config.py which was loaded from different places.

> As I have noticed that tails-greeter now has config.py I have just modified 
> it as you
> can see in:
> https://github.com/rescatux/tails-greeter/commit/863b13b7378b21af70783d36b61d5a8254a74675
> .

I think the "if not" construction is OK for now as a tracer bullet
approach, but at some point that'll need to be refactored IMO.

> So I have added these boolean variables:

> * tails_persistence_support
> * tails_show_welcome_message

> which are self explanatory.

> 2.1. Are those names correct or do you prefer them to be written in another 
> way?
> Or with another name?

Sounds good enough and easy to rename later while refactoring if needed.

> 2.2. I guess I should add more Tails specific features such as the one about
> physical security.

Your call obviously.

> 2.3. I personally only use the Keyboard feature. Do you think there are other 
> options
> which could be useful for Debian by default?

No idea (but thanks for asking :)

Perhaps the "administration password" one? Also see the ones added or
planned in our new/future Greeter, such as local time & timezone.

> 3. user user instead of amnesia user .

> https://github.com/rescatux/tails-greeter/commit/f04280192440db280d53414e7cde99bc3017e52d
> Debian Live default user is 'user', not 'amnesia'.
> So that's a clear setting that should be set by Tails.

I certainly don't mind changing the default, as long as our own use
case is still supported. And we want to switch to "user" anyway:
https://labs.riseup.net/code/issues/5655 :)

> 4. Configuration files for enabling / disabling features. (Bash)

> 4.1. One important part of tails-greeter is the PostLogin script from gdm3 
> which it's
> written in bash.


> 4.2. So as I was advised by intrigeri I rewrote the different tasks into 
> functions.
> I modified the code so that these functions were run conditioned to some
> boolean variables.

Cool. These functions need a verb in their name, given their main
responsibility implies having side-effects.

Looks like inter-dependencies between tasks are not handled, e.g.
some bits require GATHER_GENERAL_CONFIGURATION_ENABLED=yes to work.

> 4.4. I guess you would want another bash file to be sourced if someone wants 
> to
> config / modify it to suit their needs. But which filename path exactly?

Maybe /etc/tails-greeter/PostLogin.conf or similar?

> 5. Apart from the tails-greeter branch with my changes, the fact that 
> tails-greeter
> was changed from (Jessie - 1) to Jessie I also had to modify some files from 
> the
> Debian Live project itself.

> 5.1.
> https://github.com/rescatux/rescatux/commit/f073ad5cd60fa6e85fe71d7f75f4c494c8dd8c68

I guess we should really include this in the tails-greeter package.
I don't know why we don't. Any clue?

> 5.2. And add some new packages:

> https://github.com/rescatux/rescatux/commit/e38cc70fa8cd3ddf7701137d1e4c5f28d971b928

> which increase the CD size by 60 or 70 MB.

> (This is more a Rescatux question than focusing to try to 'port' 
> tails-greeter into
> Debian)

> Do you know by any chance if there are any specific packages asked by 
> tails-greeter
> dependencies which might not be needed if you only want localisation support ?

> 5.3. You seem to 

Re: [Tails-dev] Does Tails' Connectivity Depend On One OpenDNS server?

[intrigeri]

Anonymous:
> According to /etc/ttdnsd.conf:

> # OpenDNS
> 208.67.222.222

ttdnsd is not used by default. It can be used explicitly by the user
(and will go away in Tails 3.0).

See https://tails.boum.org/contribute/design/Tor_enforcement/DNS/

Cheers,
-- 
intrigeri
___
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] [Was: Tails]

[intrigeri]

anonym:
> Of course, the IM landscape is a bit crazy, with tons of protocols and
> accompanying single-protocol clients popping up and disappearing. I'm
> wondering a bit if some improvement over XMPP/IRC + OTR will be the
> preferred way to do secure IM after the dust settles, and whether Tor
> Messenger will add support for such new solutions. That would be ideal
> -- One Client To Rule Them All! :)

Right. In particular, we starting seeing quite some requests to
include OMEMO support. And now I see that
https://trac.torproject.org/projects/tor/ticket/17457 hints that OTRv4
might be the future wrt. axolotl-based protocols.

Cheers!
-- 
intrigeri
___
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 +, 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?

[Joanna Rutkowska]

On Sat, Aug 27, 2016 at 06:54:10PM +, segfault wrote:
> 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).
> 

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

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. 

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?

Cheers,
joanna.


signature.asc
Description: PGP 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.

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.

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

[Random User]

On Mon, Aug 8, 2016, at 03:32 PM, Joanna Rutkowska wrote:
> Hello,
> 
> Is there any special reason why the partition where Tails installs itself
> is
> non-deterministic? It is thanks to differing timestamps on the
> filesystem.

What you have asked about sounds at least similar to an issue I had
reported on this list a while back. I had reported that the checksums
(sha256, sha1, md5, etc.) of the Tails partition (on USB, created by dd)
no longer matched that of the Tails ISO from which said partition was
written. I say "no longer" because there had been a time when these
values did match. That changed at some point with one of the releases
and the change remained for an extended period, through a number of
releases. Then, I believe with the latest release, Tails 2.5, the hashes
for the ISO and the partition of the installation written from the ISO
(via dd, on USB) once again were the same.

The cause of these changes remains a mystery to me.

> This posses a problem for a prudent user who would like to be able to
> verify
> Tails integrity, e.g. by typing:
> 
> dd if=/dev/sda1 | sha1sum

How is that different from "sha1sum /dev/sdX*"?

Isn't your version just a lengthier and less simple means of achieving
the identical end: obtaining the checksum of a given partition (in this
case, the sha1 of the partition that Tails installed itself on). Perhaps
I am missing something?

*X for the specific device value, which will obviously change

> This might be especially useful if one uses the stick on various
> computers and
> would like to verify if her USB stick holding Tails installs hasn't been
> modified (e.g. by a malicious BIOS). 

Or (and this is obviously applicable even when one always uses his Tails
device on the same computer) that the Tails partition itself was not
altered by a remote attacker (such as while one was online using Tails)
or even a local attacker (such as while one's Tails stick was left
unattended-- even if within a secured space, unless one can somehow be
sure that no one unauthorized entered said space). 

Now, of course, this means of verification is still possible even when
the hash of the (verified) ISO does /not/ match that of the partition
created from same ISO-- providing that one made sure to record the hash
of the Tails partition right after creating it (before using it for the
first time and before leaving the device it is contained-on unattended).
But when the checksums of the Tails partition match those of the ISO
that said partition was created from, then one has the additional
advantage of knowing that the actual writing/installation itself was
completed without error or corruption.   

>Yes, I'm aware that the first sector
> of the
> disk (/dev/sda) would still differ thanks to different partition sizes.

Right, meaning that an attacker in whatever form (including a
compromised BIOS or other hardware component) could leave the Tails
partition itself untouched, yet alter another section of the device.
 
What I therefore do, in addition to recording the checksum of the Tails
partition that I created from the ISO (/dev/sdX), is to /also/ record
the checksum of the /entire device/ (USB stick). In this way, I can
presumably be reasonably certain that my stick has not been tampered
with by verifying, at any given time (such as after using it or after
leaving it unattended) that the checksum for the full-device (/dev/sdX)
still matches the one I recorded just after installing Tails on it.

/Persistence/, of course, presents an exception to this; obviously, one
cannot expect the checksum for the persistence partition not to change
with each and every change, no matter how small and insignificant, that
the user makes to said partition. 

Having noted that, however, I must /also/ mention an experience I recall
with a USB stick that I had created, with a persistence partition, using
Tails Installer. If I recall correctly, I had found that after each use
of this USB stick to boot and run Tails, the hash for the persistence
partition would change-- /even when I had NOT enabled persistence (or
otherwise consciously accessed the persistence partition) for that
session. Although I do not know the reason for this behavior, I suspect
that it somehow may be very much related to the topic that Ms. Rutkowska
created this thread about.
___
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] Porting Tails to Debian Stretch

[intrigeri]

Hi,

anonym:
> Me and intrigeri have deviced a plan for how we will deal with
> the migration to Debian Stretch, with the details being available
> in this blueprint:

> https://tails.boum.org/blueprint/Debian_Stretch/

We will kick-start this effort next week, and we have scheduled a few
sprints:

 * late August: 1st sprint, only relevant for anonym and intrigeri
 * November 14-18th: second sprint (in-person, organized by intrigeri)
 * late December: third sprint (remotely attended for everybody except
   two of us)
 * January 30 - Febuary 3: fourth sprint (remotely attended)
 * March 13-17th: fifth sprint (in-person, organized by sajolida)

We will need all kinds of skills, including for example testing our
documentation to identify regressions.

If you want to attend some of the sprints, be it remotely or
potentially in-person, please talk to me and we'll see how we can make
it work in a way that suits everyone involved.

Cheers,
-- 
intrigeri
___
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?

[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.

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

Cheers,
-- 
intrigeri
___
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?

[sajolida]

bertagaz:
> [ Ignoring some kind of private answer sent here although it doesn't
> belong to this list. ]
> 
> On Mon, Aug 08, 2016 at 09:32:17PM +0200, Joanna Rutkowska wrote:
>> Is there any special reason why the partition where Tails installs itself is
>> non-deterministic? It is thanks to differing timestamps on the filesystem.
>>
>> This posses a problem for a prudent user who would like to be able to verify
>> Tails integrity, e.g. by typing:
>>
>> dd if=/dev/sda1 | sha1sum
>>
>> This might be especially useful if one uses the stick on various computers 
>> and
>> would like to verify if her USB stick holding Tails installs hasn't been
>> modified (e.g. by a malicious BIOS). Yes, I'm aware that the first sector of 
>> the
>> disk (/dev/sda) would still differ thanks to different partition sizes.
> 
> Good question. Did you try and found out that only timestamps were
> different? If it is, good news, means it may not be so hard to fix.
> Would be nice if you could post your data on our bug tracker
> (https://labs.riseup.net/code/projects/tails).
> 
> So far we've been focusing on tails-verifier (ticket #7496, waiting for
> review...) for people to check their install, so I don't remember if we
> explored this.

Exactly. The technicalities of this are way over my head but I think
that segfault  already investigated all of this
while working on Tails Verifier [1] so he should be the one to talk to.

But if I remember correctly, he's super busy with other things right now
so maybe don't expect a quick answer (in the meantime, looking at the
code might help).

[1]: https://labs.riseup.net/code/issues/7496
___
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?

[bertagaz]

Hi,

[ Ignoring some kind of private answer sent here although it doesn't
belong to this list. ]

On Mon, Aug 08, 2016 at 09:32:17PM +0200, Joanna Rutkowska wrote:
> Is there any special reason why the partition where Tails installs itself is
> non-deterministic? It is thanks to differing timestamps on the filesystem.
>
> This posses a problem for a prudent user who would like to be able to verify
> Tails integrity, e.g. by typing:
> 
> dd if=/dev/sda1 | sha1sum
>
> This might be especially useful if one uses the stick on various computers and
> would like to verify if her USB stick holding Tails installs hasn't been
> modified (e.g. by a malicious BIOS). Yes, I'm aware that the first sector of 
> the
> disk (/dev/sda) would still differ thanks to different partition sizes.

Good question. Did you try and found out that only timestamps were
different? If it is, good news, means it may not be so hard to fix.
Would be nice if you could post your data on our bug tracker
(https://labs.riseup.net/code/projects/tails).

So far we've been focusing on tails-verifier (ticket #7496, waiting for
review...) for people to check their install, so I don't remember if we
explored this.

Bert.
___
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?

[Spencer]

Hi,



drwhax:
sexual attention.



It is very hurtful to have my intentions decided for me ):

If the snip of code wasn't enough context: I am a fan of dd hacks (:

And as was said to emmapeel privately, love is for everybody XD

I love you, too.

Wordlife,
Spencer



___
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?

[drwhax]

> Hi,

>>//>>/Joanna Rutkowska: />>/dd if=/dev/sda1 | sha1sum />>//
> I love you XD

> Wordlife,
> Spencer


Spencer,

I'll do this publicly, this is against our code of conduct, see
https://tails.boum.org/contribute/working_together/code_of_conduct/

Please refrain from unwanted sexual attention.

Sorry Joanna :(

Best,
Jurre
___
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?

[Spencer]

Hi,



Joanna Rutkowska:
dd if=/dev/sda1 | sha1sum



I love you XD

Wordlife,
Spencer



___
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

[intrigeri]

segfault wrote (19 Jul 2016 11:06:49 GMT) :
> 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

See refresh-translations and po/POTFILES.in :)
___
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.

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

[sajolida]

segfault:
> Hi everyone,

Hi!

> Other things I did in the last two weeks:
> 
> - Fix and improve the "clickable label"-widget I implemented
> 
> - Implement the autostart feature
> 
> - Write documentation

Where can I see this?

> - 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.
___
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.

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

[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?

> 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?
___
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] Making Tails 2.4 more accessible

[Spencer]

Hi,



Nathan Hale:
It would be nice if the next Tails were distributed
more like the previous versions



This is true and would make for a wonderful experience (:



There's a discussion on USENET



I will try to find it (:



u:
meantime: https://tails.boum.org/install/download.



Forced compliance by threat of the clearnet; this is broken ):

Wordlife,
Spencer



___
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] Making Tails 2.4 more accessible

[u]

Hi,

Nathan Hale:
> It would be nice if the next Tails were distributed more like the
> previous versions, not the way that Tails 2.3 was done.
> 
> There's a discussion on USENET that might be good for Tails
> developers to look at in alt.privacy.anon-server. Subject: Next
> Tails is scheduled to go live on June 7.
> 
> If anyone would like to comment on USENET that would be
> appreciated. Thanks for all that you do.

this issue has been raised multiple times, see
https://labs.riseup.net/code/issues/11269.

You might want to bookmark this easier link for future reference in the
meantime: https://tails.boum.org/install/download.

It has nothing to do with releasing Tails 2.4 though. Changes like that,
made to the website, can be done independently from a ISO relase.

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.

Re: [Tails-dev] Improve Tails Installer UX

[kurono]

Hi intirgeri

intrigeri:
> hi,
> 
> kurono wrote (18 May 2016 16:22:45 GMT) :
>> Regarding https://labs.riseup.net/code/issues/9005 and several related
>> tickets: #8861, #8860, #8859, #9006, I think its time to ask for
>> feedback
> 
> What kind of feedback do you want? (It's not obvious to me given the
> cross-post.)
> 
> Do you want code reviews, or shall we wait for the GUI design bits to
> be reviewed first?

Since these tickets are very related, and mostly about GUI improvement,
then I would like feedback on the GUI design first.

Let me now if I can make it easier (Screen shots, package installer, etc)

> 
> Cheers,
> 

Cheers,
kurono



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.

Re: [Tails-dev] Improve Tails Installer UX

[intrigeri]

hi,

kurono wrote (18 May 2016 16:22:45 GMT) :
> Regarding https://labs.riseup.net/code/issues/9005 and several related
> tickets: #8861, #8860, #8859, #9006, I think its time to ask for
> feedback

What kind of feedback do you want? (It's not obvious to me given the
cross-post.)

Do you want code reviews, or shall we wait for the GUI design bits to
be reviewed first?

Cheers,
-- 
intrigeri
___
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] Porting Tails to Debian Stretch

[sajolida]

intrigeri:
> sajolida wrote (09 Mar 2016 12:19:48 GMT) :
>>> We are in particular looking for one person to be
>>> responsible for the documentation-side of things, since we feel
>>> keeping it sort-of up-to-date will help us identify regressions
>>> early.
> 
>> I can be this person.
> 
> Excellent! I've updated the blueprint accordingly.
> 
>>> Regarding timelines, the freeze for Debian Stretch will be in
>>> early December, so the work has to start early enough so issues
>>> can be identified and fixed before that (post-freeze fixes are
>>> generally much harder). Due to other committments me and
>>> intrigeri will not be able to start this until some time early
>>> August, which will give us almost four months for this work
>>> before the Stretch freeze. We intend to kickstart this effort
>>> with a sprint where we meet face to face, and other participants
>>> will of course be welcome.
> 
>> Now the Stretch freeze has been postponed to 2017-02-05.
> 
>> I don't know what my calendar for the summer and fall will be but I
>> can't guarantee right now that I can also jump from "intrigeri will not
>> be able to start this until some time early August" to "kickstart this
>> effort with a sprint [in August]" (implicit in your email).
> 
> Please let us know when you know more when you can start, then :)

I'd prefer setting the dates of the summit first.

> Note that the very first sprint (that we would like to have in August
> 2016) might not be very exciting to doc people, given what we expect
> to be the goals there. Quoting the blueprint:
> 
> * August 2016 — start working on Tails 3.0 (1 week sprint with
>   all involved people) :intrigeri:anonym:kytv:
>   - get feature/stretch to build and boot
>   - update the automated test suite to test Tails/Stretch ISO images
> 
> … so it's no big deal if you join us for the 2nd sprint only.

Right. Then it might be better for me if I can skip this one :)
And until there's an ISO image it might be hard for me to be helpful.
___
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] Porting Tails to Debian Stretch

[intrigeri]

hey,

sajolida wrote (09 Mar 2016 12:19:48 GMT) :
>> We are in particular looking for one person to be
>> responsible for the documentation-side of things, since we feel
>> keeping it sort-of up-to-date will help us identify regressions
>> early.

> I can be this person.

Excellent! I've updated the blueprint accordingly.

>> Regarding timelines, the freeze for Debian Stretch will be in
>> early December, so the work has to start early enough so issues
>> can be identified and fixed before that (post-freeze fixes are
>> generally much harder). Due to other committments me and
>> intrigeri will not be able to start this until some time early
>> August, which will give us almost four months for this work
>> before the Stretch freeze. We intend to kickstart this effort
>> with a sprint where we meet face to face, and other participants
>> will of course be welcome.

> Now the Stretch freeze has been postponed to 2017-02-05.

> I don't know what my calendar for the summer and fall will be but I
> can't guarantee right now that I can also jump from "intrigeri will not
> be able to start this until some time early August" to "kickstart this
> effort with a sprint [in August]" (implicit in your email).

Please let us know when you know more when you can start, then :)

Note that the very first sprint (that we would like to have in August
2016) might not be very exciting to doc people, given what we expect
to be the goals there. Quoting the blueprint:

* August 2016 — start working on Tails 3.0 (1 week sprint with
  all involved people) :intrigeri:anonym:kytv:
  - get feature/stretch to build and boot
  - update the automated test suite to test Tails/Stretch ISO images

… so it's no big deal if you join us for the 2nd sprint only.

Cheers,
-- 
intrigeri
___
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] Porting Tails to Debian Stretch

[sajolida]

anonym:
> Me and intrigeri have deviced a plan for how we will deal with
> the migration to Debian Stretch, with the details being available
> in this blueprint:
> 
> https://tails.boum.org/blueprint/Debian_Stretch/
> 
> In short, we do not want to repeat the way we did Jessie
> migration -- we think we can do better! The idea is to leverage
> our up-coming freezable APT repo [0] to take snapshots of Debian
> Testing (= Stretch) and have sprints to put Tails into shape
> around these snapshots regularly, without the delta growing too
> big neither against Debian Stretch or Tails/Jessie. We will also
> use this experiment as a benchmark for the idea to make Tails
> into a semi-rolling release based on Debian Testing, which is
> pretty exciting!

All of this sounds good.

> This is an early notice for this plan draft. Our hopes is that
> more people will get involved this time, for a more collective
> effort. We are in particular looking for one person to be
> responsible for the documentation-side of things, since we feel
> keeping it sort-of up-to-date will help us identify regressions
> early.

I can be this person.

> Regarding timelines, the freeze for Debian Stretch will be in
> early December, so the work has to start early enough so issues
> can be identified and fixed before that (post-freeze fixes are
> generally much harder). Due to other committments me and
> intrigeri will not be able to start this until some time early
> August, which will give us almost four months for this work
> before the Stretch freeze. We intend to kickstart this effort
> with a sprint where we meet face to face, and other participants
> will of course be welcome.

Now the Stretch freeze has been postponed to 2017-02-05.

I don't know what my calendar for the summer and fall will be but I
can't guarantee right now that I can also jump from "intrigeri will not
be able to start this until some time early August" to "kickstart this
effort with a sprint [in August]" (implicit in your email).
___
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] Is Tails affected by the CVE-2015-7547 glibc getaddrinfo() vulnerability?

[Jurre van Bergen]

Hi,

This is an on-going investigation. Indeed, applications using the Tor
socks port for name resolution are not vulnerable for this attack.

An automated test was ran trying to determine (using the public proof of
concept) whether any application was vulnerable, so far, we're on the
safe side but were investigating a couple of applications which returned
an error.

Even if there was an evil exit node, it should be fine since
getaddrinfo() in torsocks resolves it through Tor on the SocksPort. In
addition, applications which are configured to use socks don't use
getaddrinfo() in this case since the resolving will go through Tor's
DNSPort.

We'll keep the mailinglist up-to-date on any progress regarding this matter.

Best,
Jurre

On 02/18/2016 11:34 AM, intrigeri wrote:
> Hi,
>
> my understanding is that clients that use Tor SOCKS port for name
> resolution are fine.
>
> For clients who use the DNSPort, it's not clear to me if an
> attacker-controlled payload can make it's way from the exit node being
> used for the name resolution to the client. Has anyone looked
> into this?
>
> 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] Is Tails affected by the CVE-2015-7547 glibc getaddrinfo() vulnerability?

[intrigeri]

Hi,

my understanding is that clients that use Tor SOCKS port for name
resolution are fine.

For clients who use the DNSPort, it's not clear to me if an
attacker-controlled payload can make it's way from the exit node being
used for the name resolution to the client. Has anyone looked
into this?

Cheers,
-- 
intrigeri
___
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] Upgrade Tails Bitcoin donation address

[sajolida]

Michael English:
> Electrum version 2.0 and higher supports the creation of
> multi-signature wallet types. I recommend that Tails upgrade their
> Bitcoin donation address to a multi-signature address for increased
> security and redundancy. A multi-signature address requires m of n
> signatures from separate wallets in order to spend the corresponding
> Bitcoins. A partially signed transaction is created and sent to one of
> the cosigners for completion. You can setup a 2 of 3 multi-signature
> wallet to protect against one of the cosigners' wallets being lost or
> destroyed. In order to set it up, you need the master public keys of
> the cosigners' wallets. The cosigners are usually other leaders of the
> project or it can be an offline wallet. The resulting multi-signature
> addresses begin with a  3 instead of a 1.
> 
> Please read the Electrum documentation on multisig at
> http://docs.electrum.org/en/latest/multisig.html . If you have any
> further questions, email me.

Hi Michael,

Thanks for the info. I'm forwarding this to our accounting team who's
managing our Bitcoin wallet.
___
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] Démarrage Tails

[intrigeri]

Hi,

[French] tails-dev@ est une liste de discussions dédiée au
 *développement* de Tails. Pour le support utilisateur, cf.
 https://tails.boum.org/support/

[English] tails-dev@ is a mailing-list for Tails *development*.
  For user support, see https://tails.boum.org/support/

Cheers,
-- 
intrigeri
___
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] Testing tails-greeter in Wheezy's Debian Live

[adrian15]

Do you think I should stay subscribed?
Or do I just wait for e.g. two months so that you are not so busy and I 
try again? I guess you are trying to release an stable Tails.


Thank you for pinging back.

adrian15

El 07/02/15 a las 12:49, intrigeri escribió:

adrian15 wrote (07 Feb 2015 11:11:36 GMT) :

(I am sending this message again. The first time I sent it I received no 
response
whatsoever from tails-greeter people. [...])


Sorry for the delay, we're super busy.

Cheers,


--
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

___
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] Testing tails-greeter in Wheezy's Debian Live

[intrigeri]

Hi Adrian,

adrian15 wrote (26 Nov 2014 01:38:14 GMT) :
 How to test tails-greeter
 --
 (This is not needed because you can test it in Rescatux 0.32b3. I still reuse 
 it from
 Debian Live mailing list original email so that you see what the problems 
 when you
 want to use your greeter as-is in Wheezy Debian Live).

   So, here there are the needed steps for making tails-greeter to work in a 
 Wheezy
 LXDE's Debian Live CD (Rescatux 0.32b2 specifically). As it's LXDE based you 
 might
 need to adapt the lightdm stop of another dm.

 [...]

Thanks. Do you expect us to do something specific about this?

 Questions about tails-greeter
 -

 1) Both:

 Supported language codes: /usr/share/tails-greeter/language_codes
 Default language code: /usr/share/tails-greeter/default_languagecodes

 are saved at Tails build time (according to:
 /usr/lib/python2.7/dist-packages/tailsgreeter/config.py file).

 As I see these files are being generated when tails-greeter package is built.

 What I am to focus right now is in language_codes (all the possible ones).
 According to:
 https://git-tails.immerda.ch/greeter/tree/debian/rules?id=tails-greeter_0.8.5#n16
 you seem to build your list based on:
 /usr/share/i18n/SUPPORTED
 .

 My questions about language_codes are:

 1.1) Are you excluding some keyboards on purpose or not ? If so, why? (Sorry 
 I'm not
 very good at perl).

Assuming you're talking of:

perl -n -E 'next unless m{_}xms;\
next if m{\@}xms;   \
say $$1 if m{(.*?) [. ]}xms' \
   /usr/share/i18n/SUPPORTED \
   | uniq\
$(DESTDIR)/usr/share/tails-greeter/language_codes

... then:

  * We're dropping anything that contains no _ char. On my current
sid system, that's eo.UTF-8 UTF-8 and eo ISO-8859-3. I don't
remember why exactly, but git log -p or git blame may remember.
  * We're dropping anything that contains a @ char.

 1.2) Do the tails-greeter buil-dependencies ensure that all the packages that
 fullfill the different keyboard layouts at: /usr/share/i18n/SUPPORTED/ are 
 installed
 previous to the build?

/usr/share/i18n/SUPPORTED is shipped by the locales package.
tails-greeter build-depends on that package. Should be enough.

 My questions about default langcodes are:

 1.3)

 https://git-tails.immerda.ch/greeter/tree/default_langcodes?id=tails-greeter_0.8.5

 Is there any rationale for choosing these ones over the rest of them?

The message for the commit that introduces this file explains where it
comes from :)

 About my fork and more questions about tails-greeter
 

 So I have made a tails-greeter fork so that it could work adapt and use it 
 right now
 in Rescatux.

 1) You can find the fork at:

 https://github.com/adrian15/tails-greeter/tree/rescatux_0.32

 2) You can try the fork by testing the latest Rescatux 0.32 beta 3 here:

 http://www.supergrubdisk.org/2014/11/24/rescatux-0-32-beta-3-released/

 3) How do you want to share source code?
 3.1) At runtime thanks to a variable that depends on finding exclusive files 
 found at
 Tails live cd? (Kind of what I draft on my fork).
 3.2) With a build time variable that generates one type of package or antoher?
 3.3) Trying to split the greeter into two parts, two packages (backend + 
 frontend) so
 that I only have to code my own frontend different than ours but share the 
 languages,
 country and keyboard layout algorithms?
 3.4) Maybe another approach?

I've had a look at your changes, and it seems to me that making these
bits configurable at runtime (3.1) is the best way to go.

 4) While doing my tests I have noticed an error similar to this one (I would 
 have to
 reproduce it to give you the exact error):

 locale: Cannot Set LC_ALL to default locale: No such file or directory.

 if try to run gparted from a root console.

 If I checked with locale I saw that locale was something like:

 en_US.ansi_x3

 That's why I added the two commands for forcing the generation of the used 
 locale.

We ship locales-all in Tails, so we have the guarantee that the chosen
locale is generated already. I'm afraid that dynamically generating
locales at PostLogin time will introduce a large waiting time without
any feedback to the user. Maybe we should simply make tails-greeter
depend on locales-all. What do you think?

 5) Is there a way in your glade translation to replace Tails with a variable 
 so that
 when the distro is not Tails you do not have to translate it all over again 
 but just
 change the variable value ?

The two strings that contain Tails in po/tails-greeter.pot could
indeed have the OS name as a placeholder that the code could replace
at runtime. Patches welcome :)

 6) I would like to rewrite the greeter in QT but I don't have time and I don't
 it's worth.

This looks like a technical solution that's looking for a 

Re: [Tails-dev] Testing tails-greeter in Wheezy's Debian Live

[intrigeri]

adrian15 wrote (07 Feb 2015 11:11:36 GMT) :
 (I am sending this message again. The first time I sent it I received no 
 response
 whatsoever from tails-greeter people. [...])

Sorry for the delay, we're super busy.

Cheers,
-- 
intrigeri
___
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] #5594: tails-greeter: better administration password UI

[intrigeri]

hi,

intrigeri wrote (11 Dec 2014 17:19:37 GMT) :
 anonym wrote (08 Dec 2014 09:16:06 GMT) :
 I guess what you want is that whenever one of the password fields
 are modified we do something like:

 if len(auth_password) == 0 and len(test_password) == 0:
 self.warning_area_pw_mismatch.hide()
 self.warning_area_pw_match.hide()
 elif auth_password == test_password:
 self.warning_area_pw_mismatch.hide()
 self.warning_area_pw_match.show()
 elif auth_password != test_password:
 self.warning_area_pw_mismatch.show()
 self.warning_area_pw_match.hide()

 Ok?

 ENOTIME to check this right now, but the example implementation I've
 been refering to lives in the update_passphrase_ui sub, in
 lib/Tails/Persistence/Step/Bootstrap.pm, in our
 persistence-setup repo.

I'm calling this a UX design issue, and flagged the ticket as such.
In the revamped Greeter mockups, I see a green checked/valid icon,
and a red cancel/invalid one, so I'll assume that the people working
on that front have this topic in mind, and have reparented this ticket
to be on their radar. Same for the caps lock thing (#5917).

Cheers!
-- 
intrigeri
___
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] Join Tails project - Dmitry Korzhevin

[intrigeri]

Hi,

Dmitriy Korzhevin wrote (22 Dec 2014 12:27:26 GMT) :
 I'm looking for a way to join Tails project and be helpful.

Great!

Your next step will then be: https://tails.boum.org/contribute/ :)

 I can help with:

 1.   Maintaining packages

https://tails.boum.org/contribute/how/debian/

 2.   Writing documentation

https://tails.boum.org/contribute/how/documentation/

 3.   Writing reviews

Not sure what you mean here.

 4.   Translation of docs/review to Ukrainian/Russian languages

https://tails.boum.org/contribute/how/translate/

 5.   Infrastructure administration

https://tails.boum.org/contribute/how/sysadmin/

Cheers,
-- 
intrigeri
___
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] #5594: tails-greeter: better administration password UI

[intrigeri]

anonym wrote (08 Dec 2014 09:16:06 GMT) :
 I guess what you want is that whenever one of the password fields
 are modified we do something like:

 if len(auth_password) == 0 and len(test_password) == 0:
 self.warning_area_pw_mismatch.hide()
 self.warning_area_pw_match.hide()
 elif auth_password == test_password:
 self.warning_area_pw_mismatch.hide()
 self.warning_area_pw_match.show()
 elif auth_password != test_password:
 self.warning_area_pw_mismatch.show()
 self.warning_area_pw_match.hide()

 Ok?

ENOTIME to check this right now, but the example implementation I've
been refering to lives in the update_passphrase_ui sub, in
lib/Tails/Persistence/Step/Bootstrap.pm, in our
persistence-setup repo.

Cheers!
-- 
intrigeri
___
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] #5594: tails-greeter: better administration password UI

[anonym]

On 06/12/14 12:33, intrigeri wrote:
 Given that the semantics of the fields are pretty different in the
 Greeter compared to in t-p-s, please provide a detailed description of
 how you think the Greeter should be changed in case you still think it's
 desirable.
 
 What I had in mind is:
 
   a. I click More options
   b. I see the more options screen
   c. I type an admin password
   d. I type it again in the Confirm field
   e. while I'm typing it, and then while I'm wondering whether I want
  to select other options, I'm told if I didn't type the same
  password twice

Yeah this much was pretty obvious; I need details for exactly how e
works. I guess what you want is that whenever one of the password fields
are modified we do something like:

if len(auth_password) == 0 and len(test_password) == 0:
self.warning_area_pw_mismatch.hide()
self.warning_area_pw_match.hide()
elif auth_password == test_password:
self.warning_area_pw_mismatch.hide()
self.warning_area_pw_match.show()
elif auth_password != test_password:
self.warning_area_pw_mismatch.show()
self.warning_area_pw_match.hide()

Ok?

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] #5594: tails-greeter: better administration password UI

[intrigeri]

Hi,

[sorry it took me so long to come back to this..]

anonym wrote (13 May 2014 09:45:43 GMT) :
 12/05/14 17:41, intrigeri wrote:
 The rest of the suggested changes make sense to me. The t-p-s UI is
 way nicer, with a nice little warning dynamically updated as long as
 entered password confirmation does not match. And I stole it from
 GNOME Disks, iirc, which makes the UX more consistent.

 Note that we have some form of dynamic behaviour for the error (from
 commit c96200f [1]) but that it's not exactly the same as in t-p-s; the
 mis-match error is only shown after trying to login when the fields
 differ, and the error is immediately removed when one of the fields
 change.

That's not what I call dynamic: the idea behind this ticket was
indeed to provide feedback *before* clicking on the Log in button,
just like many forms on the web these days validate input with JS
as they're being filled.

 IMHO this is a better behaviour than always showing it, at least
 in the Greeter's context where we do not have a default error to show
 (like passphrase can't be empty in t-p-s).

I'm curious why :)

 Given that the semantics of the fields are pretty different in the
 Greeter compared to in t-p-s, please provide a detailed description of
 how you think the Greeter should be changed in case you still think it's
 desirable.

What I had in mind is:

  a. I click More options
  b. I see the more options screen
  c. I type an admin password
  d. I type it again in the Confirm field
  e. while I'm typing it, and then while I'm wondering whether I want
 to select other options, I'm told if I didn't type the same
 password twice

I'll add this discussion's conclusions to the ticket once we
reach any.

Cheers!
-- 
intrigeri
___
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] I2P Tails 1.2 (0.9.15, browser, network-manager)

[Kill Your TV]

On Thu, 18 Sep 2014 22:21:00 + (UTC)
intrigeri intrig...@boum.org wrote:

 It just appeared (feature/tor-browser-bundle) 

Mr. BurnsExcellent/Mr. Burns

 *but* please don't base
 stuff on it yet, as its history will be rewritten (hopefully shortly,
 as I'd like to be able to push minor improvements on top of it).

All right. I quickly updated my browser branch; I won't be surprised
if I did it *too quickly* and will have to fix things.

(My branch will need the feature/tor-browser-bundle branch, of
course, but I won't rebase it onto mine).

I've not investigated yet but the build's currently failing with:
-
Install the Tor Browser
Fetching 
http://www.torproject.org/dist/torbrowser/3.6.5//tor-browser-linux32-3.6.5_ar.tar.xz
 ...
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100   182  100   1820 0 35  0  0:00:05  0:00:05 --:--:--44
SHA256 mismatch for tor-browser-linux32-3.6.5_ar.tar.xz
E: config/chroot_local-hooks/10-tbb failed (exit non-zero). You should check 
for errors.
P: Begin unmounting filesystems...





-- 
GPG ID: 0x5BF72F42D0952C5A
Fingerprint: BD12 65FD 4954 C40A EBCB  F5D7 5BF7 2F42 D095 2C5A


signature.asc
Description: PGP 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.

Re: [Tails-dev] I2P Tails 1.2 (0.9.15, browser, network-manager)

[anonym]

19/09/14 04:16, Kill Your TV wrote:
 I've not investigated yet but the build's currently failing with:
 -
 Install the Tor Browser
 Fetching 
 http://www.torproject.org/dist/torbrowser/3.6.5//tor-browser-linux32-3.6.5_ar.tar.xz
  ...
   % Total% Received % Xferd  Average Speed   TimeTime Time  
 Current
  Dload  Upload   Total   SpentLeft  Speed
 100   182  100   1820 0 35  0  0:00:05  0:00:05 --:--:--44
 SHA256 mismatch for tor-browser-linux32-3.6.5_ar.tar.xz
 E: config/chroot_local-hooks/10-tbb failed (exit non-zero). You should check 
 for errors.
 P: Begin unmounting filesystems...
 

You are using Vagrant, right? As you can see, the downloaded tarball
is just 182 bytes, which happens to be an error page served by
apt-cacher-ng since it cannot handle http - https redirection, as used
by torproject.org. This is due to a bug in Wheezy's a-c-ng, so you need
to install it from Wheezy backports, which this branch actually will do
for you if you first run:

rake vm:provision

Hope that 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] I2P Tails 1.2 (0.9.15, browser, network-manager)

[Kill Your TV]

On Fri, 19 Sep 2014 11:26:41 + (UTC)
anonym ano...@riseup.net wrote:

 You are using Vagrant, right? 

Yes.

 As you can see, the downloaded tarball
 is just 182 bytes, which happens to be an error page served by

I didn't notice it before posting. After a night of sleep it jumped out
at me. D'oh!

 apt-cacher-ng since it cannot handle http - https redirection, as
 used by torproject.org. This is due to a bug in Wheezy's a-c-ng, so
 you need to install it from Wheezy backports, which this branch
 actually will do for you if you first run:
 
 rake vm:provision
 
 Hope that helps!

It almost certainly will. Cheers. :)



-- 
GPG ID: 0x5BF72F42D0952C5A
Fingerprint: BD12 65FD 4954 C40A EBCB  F5D7 5BF7 2F42 D095 2C5A


signature.asc
Description: PGP 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.

Re: [Tails-dev] I2P Tails 1.2 (0.9.15, browser, network-manager)

[anonym]

19/09/14 04:16, Kill Your TV wrote:
 On Thu, 18 Sep 2014 22:21:00 + (UTC)
 intrigeri intrig...@boum.org wrote:
 
 It just appeared (feature/tor-browser-bundle) 
 
 Mr. BurnsExcellent/Mr. Burns
 
 *but* please don't base
 stuff on it yet, as its history will be rewritten (hopefully shortly,
 as I'd like to be able to push minor improvements on top of it).
 
 All right. I quickly updated my browser branch; I won't be surprised
 if I did it *too quickly* and will have to fix things.

As far as I'm concerned, you may base your work on
feature/tor-browser-bundle now.

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] I2P Tails 1.2 (0.9.15, browser, network-manager)

[intrigeri]

Hi

first, thanks a lot for the status update!

Kill Your TV wrote (17 Sep 2014 19:24:56 GMT) :
 0.9.15
 ==

 The last day for checkins for I2P 0.9.15 is tomorrow, which means a new
 release is around the corner. Once the 0.9.15 packages are available
 I'll make a request to have these updated packages pulled into the Tails
 debian repo.

Woohoo :)

 I2P-browser
 ===

 I got a bit of work done for the separate browser for use with I2P,
 based upon the unsafe-browser script. I haven't pushed it anywhere yet,
 but will do once I do a bit more testing with it. (ticket #7725)

Great! Note that this code probably depends on what browser we happen
to ship in Tails 1.2. There are chances that we ship something based
on the TBB tarball, so some paths etc. will likely need to be adapted.
Sorry that most of the discussion about that happened privately behind
anonym and I, so you couldn't know.

Once anonym pushed his initial branch that pulls the TBB in (scheduled
for today), and you push your own, then we can have a clearer idea of
if/how they conflict, and what's the best path to resolution.
Note that anonym's work includes adjusting the unsafe-browser code, so
given yours is based on it, adjusting your code shouldn't be
too painful.

 Network-Manager
 ===

 Beginning with Tails 1.1.1, users need to explicitly ask for I2P at the
 boot prompt. Users still need to start I2P from the menu. Since a user
 that enters i2p as a boot option is clearly interested in running I2P,
 it was suggested that I2P be started, e.g., via  a nm hook. This will
 also be pushed after I'm able to do a bit more testing. (ticket #7732)

I'm starting to be concerned that we're relying too much on NM hooks,
but for the time being it'll have to do. Once we migrate our stuff to
systemd, we can refactor all these NM hooks to make the whole thing
clearer and more robust.

Cheers,
-- 
intrigeri
___
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] I2P Tails 1.2 (0.9.15, browser, network-manager)

[Patrick Schleizer]

 I2P-browser
 ===
 
 I got a bit of work done for the separate browser for use with I2P,
 based upon the unsafe-browser script. I haven't pushed it anywhere yet,
 but will do once I do a bit more testing with it. (ticket #7725)
 
 Great! Note that this code probably depends on what browser we happen
 to ship in Tails 1.2. There are chances that we ship something based
 on the TBB tarball, so some paths etc. will likely need to be adapted.

Glad to hear you are working on this!

Wondering, wouldn't it anonymity wise be a good idea to also use (a
separate) Tor Browser for browsing i2p?

___
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] I2P Tails 1.2 (0.9.15, browser, network-manager)

[intrigeri]

Hi,

Patrick Schleizer wrote (18 Sep 2014 18:39:32 GMT) :
 Wondering, wouldn't it anonymity wise be a good idea to also use (a
 separate) Tor Browser for browsing i2p?

If I got your point right, that's what we have always been doing
(modulo it wasn't separate, but that's what Kill Your TV is working
on), and I don't know of any plans to change that. (I've had and heard
vague ideas of using a totally different browser for the Unsafe
Browser and for LAN browsing, but this has only been mere speculation
to this date, and probably doesn't apply to I2P browsing.)

Cheers,
-- 
intrigeri
___
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] I2P Tails 1.2 (0.9.15, browser, network-manager)

[Kill Your TV]

On Thu, 18 Sep 2014 16:40:29 + (UTC)
intrigeri intrig...@boum.org wrote:

  Great! Note that this code probably depends on what browser we
  happen to ship in Tails 1.2. There are chances that we ship
  something based on the TBB tarball, so some paths etc. will likely
  need to be adapted.  

Porting it should be pretty straightforward. Once I see the new branch
appear I'll rebase my i2pbrowser stuff on top of it to make the diffs
easier to review and to make the porting easier to manage.




On Thu, 18 Sep 2014 18:41:37 + (UTC)
Patrick Schleizer patrick-mailingli...@whonix.org wrote:

 Glad to hear you are working on this!
 
 Wondering, wouldn't it anonymity wise be a good idea to also use (a
 separate) Tor Browser for browsing i2p?

As I see it:

1) Tor Browser for Tor. There will be no I2P or I2P router console
   access because the I2P rules will be removed from FoxyProxy.
2) Tor Browser for I2P but themed a bit differently just as the
   'unsafe-browser' is.. Only I2P eepsites (http proxy
   127.0.0.1:), the router console (127.0.0.1:7657), and the
   local eepsite (127.0.0.1:7658) will be accessible from within
   it. The I2P outproxies will remain disabled. Anything not explicitly
   enabled (proxy on , http on 7657  7658) will be dropped.


-- 
GPG ID: 0x5BF72F42D0952C5A
Fingerprint: BD12 65FD 4954 C40A EBCB  F5D7 5BF7 2F42 D095 2C5A


signature.asc
Description: PGP 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.

Re: [Tails-dev] I2P Tails 1.2 (0.9.15, browser, network-manager)

[intrigeri]

Hi,

Kill Your TV wrote (18 Sep 2014 21:18:15 GMT) :
 Once I see the new branch appear I'll rebase my i2pbrowser stuff on
 top of it to make the diffs easier to review and to make the
 porting easier to manage.

It just appeared (feature/tor-browser-bundle) *but* please don't base
stuff on it yet, as its history will be rewritten (hopefully shortly,
as I'd like to be able to push minor improvements on top of it).

 1) Tor Browser for Tor. There will be no I2P or I2P router console
access because the I2P rules will be removed from FoxyProxy.
 2) Tor Browser for I2P but themed a bit differently just as the
'unsafe-browser' is.. Only I2P eepsites (http proxy
127.0.0.1:), the router console (127.0.0.1:7657), and the
local eepsite (127.0.0.1:7658) will be accessible from within
it. The I2P outproxies will remain disabled. Anything not explicitly
enabled (proxy on , http on 7657  7658) will be dropped.

Makes sense to me! ... and this summary will be useful when you update
the design doc :)

Cheers,
-- 
intrigeri
___
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] OnionMail's TAILS wizard in .deb package

[intrigeri]

Hi,

lists...@tramacci.org wrote (18 Aug 2014 15:44:45 GMT) :
 This is the new experimental package of OnionMail wizard for Claws-Mail.
 Is designed for TAILS:
 http://onionmail.info/network/onionmtails_1.0-1.deb

Great to see progress on this front!

I could not find the corresponding source package, though.

Cheers,
-- 
intrigeri
___
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] hacking tails to autologin with winxp camouflage

[intrigeri]

Hi,

sajol...@pimienta.org wrote (24 May 2014 09:01:56 GMT) :
 In order to have the Windows camouflage enabled by default, I think the
 way forward would be to create a new persistence feature to remember
 that setting.

That's https://labs.riseup.net/code/issues/6639, by the way :)

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
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] #5594: tails-greeter: better administration password UI

[anonym]

14/05/14 11:00, Andres Gomez Ramirez wrote:
 But the patch is compound of two parts: one for obligatory password
 and other that checks for admin password matching. I think this last
 part could be keep.

Sorry, but I don't get it. I've looked as best I can on the patch, and
the only other thing it does is to renaming the old warning stuff to
warning_match, to be more consistent with the new warning_empty. No
new functionality as far as I can see.

Am I mistaken?

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] #5594: tails-greeter: better administration password UI

[Andres Gomez Ramirez]

oh yes you are right, ok drop it all.

cheers.

From: Tails-dev [tails-dev-boun...@boum.org] on behalf of anonym 
[ano...@riseup.net]
Sent: 14 May 2014 13:01
To: The Tails public development discussion list
Subject: Re: [Tails-dev] #5594: tails-greeter: better administration
password UI

14/05/14 11:00, Andres Gomez Ramirez wrote:
 But the patch is compound of two parts: one for obligatory password
 and other that checks for admin password matching. I think this last
 part could be keep.

Sorry, but I don't get it. I've looked as best I can on the patch, and
the only other thing it does is to renaming the old warning stuff to
warning_match, to be more consistent with the new warning_empty. No
new functionality as far as I can see.

Am I mistaken?

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 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] #5594: tails-greeter: better administration password UI

[intrigeri]

anonym wrote (13 May 2014 09:45:43 GMT) :
 Given that the semantics of the fields are pretty different in the
 Greeter compared to in t-p-s, please provide a detailed description of
 how you think the Greeter should be changed in case you still think it's
 desirable.

I'll do this when I'm back, around May 24. So, I've dropped the 1.1
milestone from the ticket, reassigned to me, and marked as needing
more info.


___
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] #5594: tails-greeter: better administration password UI

[anonym]

30/03/14 19:22, Andres Gomez Ramirez wrote:
 Hi, 
 
 Do you think you could rebase your patch on top of the wheezy branch
 of the greeter, and test it in an (experimental) Wheezy-based ISO?
 You can download such an ISO on
 http://nightly.tails.boum.org/build_Tails_ISO_feature-wheezy/
 
 yes, done.

I've reviewed and tested the patch, and it implements what we have asked
for in the ticket, but I leaves the following now false statement in the
`password_header` label:

Otherwise it will be disabled for better security.

That part should be removed, since your patch makes it impossible to
leave these fields empty. However, after actually testing that new
behaviour, I'm not so sure what we ask for in the ticket is anything good.

Let me quote the ticket:

 Hook tails-persistence-setup's update_passphrase_ui dynamic warning
 system in.
 
 That is, add to the greeter's admin password and confirmation entry
 process the same kind of UX than the one used in t-p-s to choose a
 passphrase: can't be empty, must enter twice the same passphrase, etc.

Comparing t-p-s' update_passphrase_ui with what we currently have in the
Greeter (before Andres' patch), we see the only missing thing is the
[password] can't be empty check. (As for the etc part, there's a
TODO about checking the password's strength, nothing more.)

That makes a lot of sense in t-p-s since we *force* the persistent
container to be encrypted with a password. But for the Greeter's
*optional* admin password I'm note sure it makes sense. Previously,
leaving the fields empty meant that the admin password was left as-is,
i.e. disabled. What we (perhaps unknowingly) ask for in the ticket is to
instead *force* the user to set an admin password whenever s/he clicks
more options, even if s/he is only interested in some of the *other*
options, or just wanted to look at what's available and actually would
like to boot with the defaults.

IMHO this change is a severe loss of functionality, and either:

1. we have to admit that requesting this was a mistake, and keep the
   current behaviour.

2. we have to add a checkbox (Enable an administration password), and
   show the password fields if and only if it's checked. Then the
   [password] can't be empty check makes sense.

3. I've completely misunderstand what the ticket asks for. I believe it
   was you, intrigeri, who filed the ticket (before it was imported to
   redmine). Could you please elaborate on the purpose and arguments
   for this change, if this is what you actually intended?

As an argument for 1, overloading the fields' semantics with empty =
disabled is a pretty convenient and elegant solution.

As an argument for 2, having the fields hidden unclutters the UI a bit
and perhaps makes it clearer that entering a password is not mandatory
(for users that don't read or understand the text above the fields).
Using a checkbox also makes it more consistent with the other options, FWIW.

I personally think I'm in favour of going with 1. Does any one have any
other good arguments for 2? Does any one with user testing experience
have anything to say about the arguments for 2 I proposed (I've seen no
evidence that there's much confusion with the current UI)? If we end up
going with 2 I'd be happy to implement it on top of Andres' patch.

I for one at least admit that I've made a huge mistake in not realising
this earlier... I guess my brain shut off when it saw [password] can't
be empty since that generally is a great idea, and I just accepted it
uncritically. No matter the outcome, I'm really sorry about all this,
Andres!

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] #5594: tails-greeter: better administration password UI

[intrigeri]

anonym wrote (12 May 2014 15:02:45 GMT) :
 That makes a lot of sense in t-p-s since we *force* the persistent
 container to be encrypted with a password. But for the Greeter's
 *optional* admin password I'm note sure it makes sense.

I don't think it makes any sense. Sorry, I'm probably the one who
wrote a misleading (not to say: stupid) description on this ticket.

 IMHO this change is a severe loss of functionality, and either:

 1. we have to admit that requesting this was a mistake, and keep the
current behaviour.

As far as can't be empty is concerned, right, we should keep the
current behaviour.

 3. I've completely misunderstand what the ticket asks for. I believe it
was you, intrigeri, who filed the ticket (before it was imported to
redmine). Could you please elaborate on the purpose and arguments
for this change, if this is what you actually intended?

The rest of the suggested changes make sense to me. The t-p-s UI is
way nicer, with a nice little warning dynamically updated as long as
entered password confirmation does not match. And I stole it from
GNOME Disks, iirc, which makes the UX more consistent.

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
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] #5594: tails-greeter: better administration password UI

[Andres Gomez Ramirez]

Hi, I attached a new patch for Feature #5594 tails-greeter: better 
administration password UI.

Sorry for the huge delay, i had some days off.

Cheers.

From: tails-dev [tails-dev-boun...@boum.org] on behalf of intrigeri 
[intrig...@boum.org]
Sent: 04 March 2014 12:05
To: The Tails public development discussion list
Subject: Re: [Tails-dev] #5594: tails-greeter: better administration
password UI

Andres Gomez Ramirez wrote (22 Feb 2014 18:10:41 GMT) :
 In the patch you use at least one untranslated string in

 +self.warning_label.set_markup(iPassword must not be 
 empty./i)

 but possibly also in

 +self.warning_label.set_markup(iPasswords do not match./i)

 In the latter case you actually set it to the default text for
`warning_label` as defined in the glade file, so maybe it works.

 I'm no glade expert, but I think the way you'll have to go is to create
 two `warning_label`, one for each warning, and `show()`/`hide()` them
 appropriately. I'd be glad if someone more familiar with glade could
 chime in if there's a better approach.

 so the idea is to add translatable string to the labels, ok.

Any news on this? The feature freeze for Tails 0.23 is coming real
soon now.

 btw I'm having problems to access labs.riseup.net with firefox
 27.0.1, there is an error with the certificate (?):

labs.riseup.net uses a commercial certificate again, so this should
be fixed.

Cheers,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
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 8d6d0a20f37f463172b10f039aa60f7450ab91e2 Mon Sep 17 00:00:00 2001
From: kurono andres.go...@cern.ch
Date: Sun, 30 Mar 2014 14:57:55 +0200
Subject: [PATCH] Fix for 5594: tails-greeter: better administration password
 UI

---
 GdmGreeter/optionswindow.py |   21 +++
 glade/optionswindow.glade   |   47 ---
 2 files changed, 57 insertions(+), 11 deletions(-)

diff --git a/GdmGreeter/optionswindow.py b/GdmGreeter/optionswindow.py
index 5a2459b..15eec80 100644
--- a/GdmGreeter/optionswindow.py
+++ b/GdmGreeter/optionswindow.py
@@ -20,7 +20,8 @@
 
 
 
-import logging, gtk, os
+import logging, gtk, gettext, os
+_ = gettext.gettext
 import GdmGreeter
 from GdmGreeter.language import TranslatableWindow
 from helpwindow import HelpWindow
@@ -37,8 +38,8 @@ class OptionsWindow(TranslatableWindow):
 builder.connect_signals(self)
 self.entry_password = builder.get_object(password_entry)
 self.entry_password2 = builder.get_object(password_entry2)
-self.warning_label = builder.get_object(warning_label)
-self.warning_area = builder.get_object(warning_area)
+self.warning_area_empty = builder.get_object(warning_area_empty)
+self.warning_area_match = builder.get_object(warning_area_match)
 self.camouflage_checkbox = builder.get_object(camouflage_checkbox)
 self.macspoof_checkbox = builder.get_object(macspoof_checkbox)
 self.macspoof_checkbox.set_active(True)
@@ -53,7 +54,8 @@ class OptionsWindow(TranslatableWindow):
 self.entry_password2.set_visibility(False)
 
 def cb_pw_changed(*args):
-self.warning_area.hide()
+self.warning_area_empty.hide()
+self.warning_area_match.hide()
 # compact the window
 self.window.resize(1, 1)
 
@@ -114,10 +116,13 @@ class OptionsWindow(TranslatableWindow):
 Validate the selected options
 auth_password = self.entry_password.get_text()
 test_password = self.entry_password2.get_text()
-passwords_match = test_password == auth_password
-if not passwords_match:
-self.warning_area.show()
-return passwords_match
+if len(auth_password) == 0 or len(test_password) == 0:
+self.warning_area_empty.show()
+return False
+elif not auth_password == test_password:
+self.warning_area_match.show()
+return False
+return True
 
 def set_options_and_login(self):
 Activate the selected options if they are valid
diff --git a/glade/optionswindow.glade b/glade/optionswindow.glade
index 1632b62..a3ad0ea 100644
--- a/glade/optionswindow.glade
+++ b/glade/optionswindow.glade
@@ -227,12 +227,12 @@ Otherwise it will be disabled for better security./property
   /packing
 /child
 child
-  object class=GtkHBox id=warning_area
+  object class=GtkHBox id=warning_area_empty
 property name

Re: [Tails-dev] #5594: tails-greeter: better administration password UI

[intrigeri]

Hi,

Andres Gomez Ramirez wrote (30 Mar 2014 13:26:46 GMT) :
 Hi, I attached a new patch for Feature #5594 tails-greeter: better
 administration password UI.

Thanks! The next release (1.0) will be a point-release, and I don't
think this qualifies as a bugfix worth including in it, so I'll assume
this is targetted at 1.1, based on Wheezy.

Do you think you could rebase your patch on top of the wheezy branch
of the greeter, and test it in an (experimental) Wheezy-based ISO?
You can download such an ISO on
http://nightly.tails.boum.org/build_Tails_ISO_feature-wheezy/

Once this is done, please reassign to anonym (acting as the release
manager for 1.1) and set the milestone field to 1.1.

Thanks in advance!

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
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 (tails-dev@boum.org)

[intrigeri]

Hi,

Juan Christian (Google Drive) wrote (30 Mar 2014 19:45:07 GMT) :
 I've shared an item with you:
 Tails
 https://drive.google.com/folderview?id=0B-xFHveOVEfUMC1iWEViOWI0WDgusp=sharinginvite=CLG_wtYK

Thanks! Unfortunately, when following this link, I'm asked to Sign in
to continue to Google Drive. Could you please share your material in
a public place instead?

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
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] Dr.BiT : Tails logo submission update

[sajolida]

Dr.BiT:
 Raccon  Skunks versions updated with font (ALBA compatible with your
 requirements)
 
 https://mega.co.nz/#!QBsVFRia!ICsV57QagkqPg5Xhnjh6okR4ncKmvEDqXQw2dCSjT1c
 
 https://mega.co.nz/#!kA0FCaDR!qhHv6q1fQNm9AXxQdQJyokG6IeH8cg4HjvnE2aVDkO4
 
 https://mega.co.nz/#!kNVy0IwY!p-VoB1GRoSCLrUHc5__sXBsVeBf_bDrJ8df10WJlSNE
 
 https://mega.co.nz/#!cMcmGKYa!Jktxp7AFMiV5MM6VdU1HCngZ8AU9L9svkEI-GgQ_Eg8

Nice, thanks. But I still have to clarification to ask:

1. Is Alba this font:

http://www.dafont.com/alba.font
http://www.fontbros.com/families/alba/styles/regular

Because in that case I think it's free, as in free beer, for personal
use. But it is not free, as in free software, as you can see in the
license terms and conditions from that foundry:

http://www.fontbros.com/support/license-agreement-modal?bare=true

2. Can you render the fonts? In you file the text is still presented as
text. You need to render the letters and a vector drawing so we can view
them correctly even if we don't have the original font software.

-- 
sajolida




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.

Re: [Tails-dev] Dr.BiT: Tails Logo submission

[sajolida]

Dr.BiT:
 Here is a logo submission
 this is just draft for the moment, I can modify if you have some
 propositions.
 
 https://mega.co.nz/#!sBEyBJqC!8r8x7RglVhxTLKS9cYmm7GubAYQZdi3Fud4C0JXxF_I
 
 https://mega.co.nz/#!EIVRGTRK!pXdd3Pu-nWATxxZD5kl_hTFRF_g74nFos8v8u7W17Mg
 
 https://mega.co.nz/#!dZkyxZaT!3LGgoaPS29xsQyGmqvDGPBUY1w8rE0ISRWL2qsNzxyM

Cool, thanks a lot for your proposal. I added it to the logo contest:

https://tails.boum.org/blueprint/logo/#index11h1

 The idea is a Racoon or Skunk head in its rounded tail (with Tor colors)
 The Racoon is nice because it's like it's wearing a mask
 But I like the skunk more, though I'm still thinking on how to integrate it
 better in the logo.

Ok, so don't hesitate to submit an updated version before the deadline
if you want. But the racoon version looked pretty much ready already.

And also, to make your proposal stronger, you think about a typography
for the Tails word as well.

-- 
sajolida




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.

Re: [Tails-dev] Improving Tails' usability, making it more attractive: got a plan!

[sajolida]

Claudio Vandi:
 Hi,
 thanks Intrigeri for the task list!
 I've booked a room for 21 and 28 mai afternoon/evening for the tests.

Cool, so I added the dates to our calendar:

https://tails.boum.org/contribute/calendar/

If the event is announced publicly, don't hesitate to forward it to us.

Regarding the content of the session, we started brainstorming on a list
of possible exercises, see:

https://tails.boum.org/blueprint/usability_testing/

But we never did that before, so if you think they are too long, too
strong, or badly focused, don't hesitate to give us more indications.

Plus, since there will be two different sessions, do you think it make
sense to prepare only the first one now, and then prepare the second one
according to the outcome of the first one?

-- 
sajolida




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.

Re: [Tails-dev] Improving Tails' usability, making it more attractive: got a plan!

[Claudio Vandi]

Hi,
thanks Intrigeri for the task list!
I've booked a room for 21 and 28 mai afternoon/evening for the tests.
Do you think Tails would be ready for testing by then ?
C

@vandicla https://twitter.com/vandicla ::
Linkedinhttp://www.linkedin.com/in/vandicla


*Téléchargez le Book Silicon Xperience*
  http://bit.ly/sxbook



On Sat, Mar 8, 2014 at 12:28 PM, intrigeri intrig...@boum.org wrote:

 Hi,

 [Please keep the Cc list intact for anything on this topic that's not
 purely about what we at Tails should do internally.]

 Following-up on Zack's initiative to have us meet some designers
 interested in working on FOSS projects, some of us have recently met
 Claudio and Mael.

 The starting point is the obvious fact that FOSS projects too often
 have poor usability, and are not attractive enough to potential users.
 Claudio and Mael want to play a role in improving this situation, by
 building a bridge between the designers / graphics artists / UI
 experts community on the one hand, and the FOSS people on the other
 hand. This seems to be a great idea, and for a number of reasons,
 Tails would be a good candidate to try it :)

 Here is the plan and timeline we've drawn together:

   1. $NOW--late May

  - make Tails/Wheezy ready for usability testing [[Tails folks]]
  * https://labs.riseup.net/code/issues/6862

  - brainstorm a list of exercises (practical goals to achieve)
that match the intended Tails use cases, and could be handed
out to the people who'll participate in the usability testing
session(s). Send the results to Claudio  Mael.
  * https://labs.riseup.net/code/issues/6864
  * https://tails.boum.org/blueprint/usability_testing/

  - think about who we want to participate in the usability testing
session; e.g. having good diversity seems important to me, to
avoid the developers with a specific cultural background and
social position optimize software for their peers trap.
There's also the question of optimizing for first-time use, or
for daily users, which are conflicting goals sometimes.

  - design, plan and organize a usability testing session [[Claudio
 Mael, based on the input we will have provided]]

   2. late May: conduct a usability testing session in Paris [[Claudio
   Mael, but it would be useful if some Tails people were there]]

   3. late May--late June: draw conclusions from #2, identify a set of
  3-5 major usability and/or design problems (it's unclear to me if
  we'll focus on low-hanging fruits or critical problems to start
  with, we'll see) [[Claudio  Mael, most likely with some
  {communication with,participation from} Tails folks]]

   4. late June: possibly present a talk about the ongoing process and
  current results at PSES (Pas Sages en Seine, a hacker conference
  in Paris) [[Claudio, Mael]]

   5. mid-July: have a few teams of designers and UI experts at the
  Tails hackfest in Paris; give each team one of the previously
  identified problem, and half a day or two to find and propose
  a solution to it [[everybody involved + guests!]]

   6. Implement the designed solutions. Build long-term collaboration
  with designers / UX experts / graphics artists upon this
  experience, wooo :)

 Claudio, Mael: please correct any misunderstanding and add missing
 bits as needed.

 Cheers,
 --
   intrigeri
   | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
   | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc

___
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] Getting Tails to boot on a Mac from usb

[sajolida]

Sherif Mansour:
 Have you guys used this?
 https://github.com/SevenBits/Mac-Linux-USB-Loader
 I'm going to start with the Mac version of Ubuntu, work my way to Kali then
 finally try Tails (it didn't work the first time).
 Failing that I'll try to install the tails packages on a supported
 Mac-friendly Linux and see how that goes!

We contacted the developer a while ago and he told us his tool doesn't
work with Tails at the moment. But that was a frequent request so he was
working on fixing this.

-- 
sajolida




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.

Re: [Tails-dev] Announcing tails-testers

[intrigeri]

sajol...@pimienta.org wrote (07 Mar 2014 00:12:44 GMT) :
 And merge if you are happy with it.

Pushed a few fixes to the topic-branch, feel free to merge into master
if you like it.

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
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] #5594: tails-greeter: better administration password UI

[intrigeri]

Andres Gomez Ramirez wrote (22 Feb 2014 18:10:41 GMT) :
 In the patch you use at least one untranslated string in

 +self.warning_label.set_markup(iPassword must not be 
 empty./i)

 but possibly also in

 +self.warning_label.set_markup(iPasswords do not match./i)

 In the latter case you actually set it to the default text for
`warning_label` as defined in the glade file, so maybe it works.

 I'm no glade expert, but I think the way you'll have to go is to create
 two `warning_label`, one for each warning, and `show()`/`hide()` them
 appropriately. I'd be glad if someone more familiar with glade could
 chime in if there's a better approach.

 so the idea is to add translatable string to the labels, ok.

Any news on this? The feature freeze for Tails 0.23 is coming real
soon now.

 btw I'm having problems to access labs.riseup.net with firefox
 27.0.1, there is an error with the certificate (?):

labs.riseup.net uses a commercial certificate again, so this should
be fixed.

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
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] #5594: tails-greeter: better administration password UI

[anonym]

06/02/14 00:31, Andres Gomez Ramirez wrote:
 I attached a patch for #5594: tails-greeter: better administration password 
 UI 
 https://labs.riseup.net/code/issues/5594

Thanks for the patch!

In the patch you use at least one untranslated string in

 +self.warning_label.set_markup(iPassword must not be 
 empty./i)

but possibly also in

 +self.warning_label.set_markup(iPasswords do not match./i)

In the latter case you actually set it to the default text for
`warning_label` as defined in the glade file, so maybe it works.

I'm no glade expert, but I think the way you'll have to go is to create
two `warning_label`, one for each warning, and `show()`/`hide()` them
appropriately. I'd be glad if someone more familiar with glade could
chime in if there's a better approach.

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.