Re: [Tails-dev] tails plymouth theme

[intrigeri]

Ague Mill wrote (01 Jun 2012 18:20:31 GMT) :
> On Fri, Jun 01, 2012 at 07:53:25PM +0200, intrigeri wrote:
>> How about implementing and proposing it as a patch against the
>> plymouth hook that adds the other gfx modules to the initramfs
>> (/usr/share/initramfs-tools/hooks/plymouth) instead?

> It is in my todo list.

:)

> In any cases, I'd rather add this small hook for now in Tails and
> remove it once we switch to Wheezy and a hopefully updated plymouth.

Sure!
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] tails plymouth theme

[Ague Mill]

On Fri, Jun 01, 2012 at 07:53:25PM +0200, intrigeri wrote:
> Ague Mill wrote (01 Jun 2012 08:32:00 GMT) :
> > I have pushed one more commit to `feature/tails-plymouth-theme` which
> > adds the nouveau driver. I have splendidly tested it on a system with
> > some NVidia adapter.
> 
> Looks great.
> 
> How about implementing and proposing it as a patch against the
> plymouth hook that adds the other gfx modules to the initramfs
> (/usr/share/initramfs-tools/hooks/plymouth) instead?

It is in my todo list.

One thing that have not made me do it directly was related to how the
hook could cope with a module that is not shipped in linux-image
packages (e.g. vboxvideo, as its built through dkms). But maybe we will
add an extra hook in the dkms package.

In any cases, I'd rather add this small hook for now in Tails and remove
it once we switch to Wheezy and a hopefully updated plymouth.

-- 
Ague


pgpmLNpD2kc63.pgp
Description: PGP signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Has Tails joined Open Invention Network?

[intrigeri]

Hi,

Maxim Kammerer wrote (31 May 2012 22:10:23 GMT) :
> People from OIN [1] continue to send me requests to join (I think
> I mentioned it on #tails-dev a year ago), and today they mentioned
> that Tails has recently joined the network.

This is correct.

> Could you perhaps expand on the rationale?

We have not seen any downsides in joining the Open Invention Network,
but it has some (small) advantages.

> To me joining OIN seems like surrendering part of project's
> independence for some vague American thing in return.

What kind of independence do you think we've surrendered?

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

Re: [Tails-dev] tails plymouth theme

[intrigeri]

anonym wrote (about 4 hours ago) :
> I any case, I think the current state of tnat branch is an over-all
> improvement. I'll merge this into devel for the 0.12 release unless
> someone objects.

I'm happy with the merging, and I would have been happy to see it done
without asking first, given this code has been sitting in experimental
for a while (modulo the nouveau / KMS changes that were announced
today).

But seriously, what does "unless someone objects" *practically* means,
when the actual merge is done half an hour after this email, and the
push is done less than 4 hours after this? Acting like this may
communicate a "if you want to have your word in Tails, you must be
online 24/7" message to potential contributors, which worries me.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] tails plymouth theme

[intrigeri]

Ague Mill wrote (01 Jun 2012 08:32:00 GMT) :
> I have pushed one more commit to `feature/tails-plymouth-theme` which
> adds the nouveau driver. I have splendidly tested it on a system with
> some NVidia adapter.

Looks great.

How about implementing and proposing it as a patch against the
plymouth hook that adds the other gfx modules to the initramfs
(/usr/share/initramfs-tools/hooks/plymouth) instead?
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] tails plymouth theme

[intrigeri]

Ague Mill wrote (01 Jun 2012 14:15:25 GMT) :
>> In Tails the text only theme diplays "Debian 6.0.x" after some time (I
>> can only see this when booting from DVD). For some additional
>> consistency we could try to change this to "Booting Tails".
>> Unfortunately that seems to be hardcoded in the plymouth text theme, so
>> we'd have to make a new 'tails-text' theme. Hmm.

> I have some patches ready to fix that, but I think we will have to wait
> for upstream to merge them before getting that in Tails. I don't think
> having yet another binary packages is worth the effort for such minor
> detail.

Agreed.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Tails 0.12 release plan

[intrigeri]

hi,

anonym wrote (30 May 2012 14:22:04 GMT) :
>> New releases of tails-persistence-setup and perhaps liveusb-creator
>> may be needed.
>> I'd like to push mat 0.3.2 into Tails 0.12 too, should be
>> pretty trivial.

> Should I take this as that you are going to take care of these?

I'm taking care of the MAT but not of the other bits.

> To be honest I haven't paid much attention to how the translations
> has integrated into our release plans previously so I don't really
> know what's possible and not. Please tell me if you have a more
> realistic proposal according to your experience.

Our only experience with a release that was carefully synchronized
between developers, doc writers and translators was Tails 0.11.
It worked pretty well. The initial release schedule can be found
there:
https://mailman.boum.org/pipermail/tails-dev/2012-January/000805.html
Eventually, some translations were merged a bit later than expected,
and this was made possible by the actual release date being postponed.
This schedule was proposed more than two months before the time
translators had to start working.

All in all, I think we can probably have a much tighter working
schedule. But moving from "notice sent two months in advance + one
month to do the work" to "notice sent two weeks in advance + 5 days to
do the work" looks, well, pretty optimistic to me (even if some of the
doc writting was done already, and the amount of new docs and programs
is much smaller this time).

> If necessary I could push the actual release to the 15th, and so the
> deadline for translations to the 13th. What do you think?

I doubt this is about +/- 2 days, but well, I'll stop now talking in
place of the translators. Hopefully it will work! :)

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

Re: [Tails-dev] Getting the Icedove patches merged upstream

[intrigeri]

Hi,

I'm glad to see this moving forward!

anonym wrote (01 Jun 2012 16:13:29 GMT) :
> # 1. Rebase patches against current Debian packaging.

> The patches apply cleanly against current git [3]. However, its
> latest included version is icedove 10.0.3-2, but 11.0-1 has been
> released (in experimental) since then [...]

Yes, it does look like a forgotten push of a new branch. Just ping
Christoph Goehre  who did the 11.0-1 upload. By the
way, they'll probably be happy to see people testing the stuff they
push to experimental.

> # 4. Send a draft of the upstream merge proposal here for feedback.

> I'll write something up once the issues in 1 and 2 are resolved.
> Any pointers on how to do this with maximum chance of success is
> highly welcome (we all know that getting patches accepted is pretty
> hard when dealing with Mozilla).

Only simple advices from me for now:

1. Keep it short. If you don't manage to, perhaps pass it through me,
   I may want to act as a compressor occasionally :)
2. Mention the following usecases:
   - to deploy Thunderbird in ways that satisfy the existing, set in
 stone, enterprise security policy that says no password in the
 clear, ever
   - places where Internet connections can, and are, sniffed and
 actively tampered with (that includes about everywhere, but we
 don't need to tell them right now)

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

Re: [Tails-dev] memlockd stopped too soon

[intrigeri]

hi,

Ague Mill wrote (01 Jun 2012 14:38:06 GMT) :
> Please have a look at the `bugfix/dont_stop_memlockd` branch. It is
> a candidate for 0.12.

Looks great!

A few minor comments, that may be related, and may be not, you tell
me:

* The commit message reads "In addition, we fix initscript ordering
  related to tails-sdmem-on-media-removal." -- why and how?
* Why are the tails-reconfigure-kexec and tails-reconfigure-memlockd
  initscripts moved to by-hand numbering?
* It's not clear why the tails-sdmem-on-media-removal start order
  changes. Both, given nothing in the commit message talks of
  initscripts startup.

To end with, I think the explanations found in the commit message
would be worth pushing to the memory wipe design doc. I think this is
the kind of knowledge we really don't want to have to dig in the Git
history when we need it.

> +   rm -f /lib/init/rw/sendsigs.omit.d/memlockd
> +   ln -s /var/run/memlockd.pid /lib/init/rw/sendsigs.omit.d/memlockd

Why not using "ln -sf" instead?
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

[Tails-dev] Getting the Icedove patches merged upstream

[anonym]

Hi,

I'm gonna use this thread as my personal TODO list, and as a general
report on my progress so all interested parties can follow it. Note that
I've CC:ed the TorBirdy people (hopefully I didn't forget anyone), who
may have some interest in this effort.

So the plan to get the secure autoconfig patches [1] merged upstream is
as follows:

1. Rebase patches against current Debian packaging.
2. Check that patches applies on upstream mercurial.
3. Test against upstream mercurial.
4. Send a draft of the upstream merge proposal here for feedback.
5. Send proposal to upstream, possibly in Mozilla bug #664633 [2].

In this thread I'm gonna work towards 4, and ultimately 5, but first I'm
gonna talk about about 1-3 which I've already done.

[1] https://tails.boum.org/todo/Return_of_Icedove__63__/#index6h2 and
https://lists.torproject.org/pipermail/tor-talk/2012-May/024163.html
(patches are posted in the latter for your convenience since the git
repo doesn't have gitweb)
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=664633

# 1. Rebase patches against current Debian packaging.

The patches apply cleanly against current git [3]. However, its latest
included version is icedove 10.0.3-2, but 11.0-1 has been released (in
experimental) since then. Is this just a forgotten git push by the
package maintainer, or have I missed something? I thought I should ask
you Debian pros before I bother him.

[3] http://git.debian.org/?p=pkg-mozilla/icedove.git;a=summary

# 2. Check that patches applies on upstream mercurial.

[First of all, I'm happy we're not using mercurial..]

The patches kinda apply cleanly to current trunk [4]. The only relevant
change I made was to make autoconfig not try SSL/TLS for POP/IMAP/SMTP,
something which upstream did in changeset 69177e1f55f4 [5] supposedly
due to Mozilla bug #721369 [6]. Just to be clear: now the prober only
tries STARTTLS among the secure protocols, not SSL/TLS. What makes this
even more baffling than it is in itself is that some lines up they have
a //TODO about preferring SSL/TLS over STARTTLS. WTF? I have to inquire
about this because I don't get it. The patch that was attached to the
bug did not include this change, but it slipped through in the commit
any way. Hopefully it's a mistake because the merger was testing something.

One good thing is that current trunk has a fix for certificate errors
(now you can discard or add an exception) that I had to patch around
(previously it just failed), so now I can drop one of the patches (the
most dubious one! :)).

[4] http://hg.mozilla.org/comm-central/
[5] http://hg.mozilla.org/comm-central/rev/69177e1f55f4
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=721369

# 3. Test against upstream mercurial.

Works just as intended (modulo SSL/TLS probing). For those interested,
here's a screenshot of how the GUI looks:

http://oi49.tinypic.com/35iavew.jpg

The only added control is the "Only use secure protocols" checkbox.

# 4. Send a draft of the upstream merge proposal here for feedback.

I'll write something up once the issues in 1 and 2 are resolved. Any
pointers on how to do this with maximum chance of success is highly
welcome (we all know that getting patches accepted is pretty hard when
dealing with Mozilla).

Cheers!



signature.asc
Description: OpenPGP digital signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

[Tails-dev] memlockd stopped too soon (was: Improvement of the shutdown sequence)

[Ague Mill]

On Tue, May 29, 2012 at 11:02:27AM +0200, intrigeri wrote:
> Ague Mill wrote (20 May 2012 17:55:03 GMT) :
> >  * memlockd
> >Stop memlockd. Memwipe files will not kept in memory after that.
> >Better let sendsigs kill it, or even, add its PID to
> >/var/run/sendsigs.omit. **Remove**
> 
> Something has to be done in this area to fix what looks like a serious
> bug, independently of the optimization of the shutdown sequence speed.
> The sendsigs.omit way looks right: we really don't want these files
> unmapped from memory until tails-kexec has had a chance to do its
> work. Are you taking care of that one?

Please have a look at the `bugfix/dont_stop_memlockd` branch. It is a
candidate for 0.12.

-- 
Ague


pgpQzSqdwbZEx.pgp
Description: PGP signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] tails plymouth theme

[Ague Mill]

> > Initially, I also wanted to add video drivers for virtualization
> > software. Unfortunately, no drivers happen to support Kernel Mode
> > Setting at the moment:
> [...]
> >  * VirtualBox: code is written and it should be shipped in 4.2,
> >according to 
> > .
> 
> But will this help? The VirtualBox guest modules are loaded pretty late
> during boot.

It will, as long as the module is present in the initrd. That exactly is
why I have left commented out it in that new initramfs hook.
 
> In Tails the text only theme diplays "Debian 6.0.x" after some time (I
> can only see this when booting from DVD). For some additional
> consistency we could try to change this to "Booting Tails".
> Unfortunately that seems to be hardcoded in the plymouth text theme, so
> we'd have to make a new 'tails-text' theme. Hmm.

I have some patches ready to fix that, but I think we will have to wait
for upstream to merge them before getting that in Tails. I don't think
having yet another binary packages is worth the effort for such minor
detail.

> I any case, I think the current state of tnat branch is an over-all
> improvement. I'll merge this into devel for the 0.12 release unless
> someone objects.

I don't. I have tested it on a dozen computers I could get my hands on,
and I have not seen any issues.

-- 
Ague


pgpPtNN3oarBm.pgp
Description: PGP signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] tails plymouth theme

[anonym]

06/01/2012 10:32 AM, Ague Mill:
> On Tue, May 29, 2012 at 07:25:52PM +0200, intrigeri wrote:
>> anonym wrote (29 May 2012 13:17:16 GMT) :
>>> I have tested it on three different (real metal) systems and in
>>> virtualbox successfully. Unless someone actually experienced any issues
>>> I'd say we merge this ASAP so it can hit Tails 0.12.
>>
>> Agreed.
> 
> I have pushed one more commit to `feature/tails-plymouth-theme` which
> adds the nouveau driver. I have splendidly tested it on a system with
> some NVidia adapter.

Great!

> Initially, I also wanted to add video drivers for virtualization
> software. Unfortunately, no drivers happen to support Kernel Mode
> Setting at the moment:
[...]
>  * VirtualBox: code is written and it should be shipped in 4.2,
>according to .

But will this help? The VirtualBox guest modules are loaded pretty late
during boot.

> It looks like things are moving because of Wayland. Good, but a little
> annoying at the moment.

Annoying but not really worse than before. The only drawback of merging
this is the inconsistency users may experience when booting the same
Tails on different hardware. On systems with a KMS/DRM enabled drivers
s/he gets the new, flashy theme, but on systems without s/he gets text
only theme.

In Tails the text only theme diplays "Debian 6.0.x" after some time (I
can only see this when booting from DVD). For some additional
consistency we could try to change this to "Booting Tails".
Unfortunately that seems to be hardcoded in the plymouth text theme, so
we'd have to make a new 'tails-text' theme. Hmm.

I any case, I think the current state of tnat branch is an over-all
improvement. I'll merge this into devel for the 0.12 release unless
someone objects.

Cheers!



signature.asc
Description: OpenPGP digital signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] tails plymouth theme

[Ague Mill]

On Tue, May 29, 2012 at 07:25:52PM +0200, intrigeri wrote:
> anonym wrote (29 May 2012 13:17:16 GMT) :
> > I have tested it on three different (real metal) systems and in
> > virtualbox successfully. Unless someone actually experienced any issues
> > I'd say we merge this ASAP so it can hit Tails 0.12.
> 
> Agreed.

I have pushed one more commit to `feature/tails-plymouth-theme` which
adds the nouveau driver. I have splendidly tested it on a system with
some NVidia adapter.


Initially, I also wanted to add video drivers for virtualization
software. Unfortunately, no drivers happen to support Kernel Mode
Setting at the moment:

 * qemu/kvm: Matthew Garrett worked on a modified Cirrus driver
   ,
   but his patch never got merged. KMS support for SPICE/QXL is in
   the work according to .
 * VirtualBox: code is written and it should be shipped in 4.2,
   according to .
 * VMWare: Support for KMS is planed according to
   

It looks like things are moving because of Wayland. Good, but a little
annoying at the moment.

-- 
Ague
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev