[Tails-dev] Update: Porting tails bash scripts to python

[GoodCrypto Support]

Early .py versions of the following scripts are available at 
https://goodcrypto.com/special-downloads/bash2py-2016-03-24.tgz:

   config/chroot_local-hooks/19-install-tor-browser-AppArmor-profile
   config/chroot_local-includes/usr/local/lib/tails-shell-library/tor-browser.sh
   config/chroot_local-includes/usr/local/bin
  electrum
  icedove
  tails-boot-to-kexec
  tails-get-bootinfo
  tails-upgrade-frontend-wrapper
  tor-browser
  tor-launcher

We'll add tests and port more scripts when time is available. Bug reports (and 
tests) are very welcome.

Where bash uses commands and there is an equivalent python standard library, we 
chose based on security and 
readability. Standard commands are often better tested and maintained. 
Otherwise the more readable python equivalent 
is the right choice.

Import statement style is somewhat inconsistent. If python internally imports 
everything from a module when you 
import anything from that module, it's not clear that there's a security 
advantage to "from MODULE import ELEMENT".

With  python 3 the sh module handles some things differently. For example, the 
_in keyword can cause locks up 
(i.e., when used with sed). The only python 2 feature in these scripts should 
be "from __future__ import print_function". 
Seeing the usual py2-vs-py3 str-vs-bytestring errors.

Pylint has some spurious complaints. Not changed: Script names including 
dashes, filenames longer than 32 characters, 
long gettext lines. The sh module actually does import commands. Constants 
local to a function should be in that 
function. The doctests module is imported locally to minimize unused imports.


GoodCrypto Warning: Anyone could have read this message. Use encryption, it 
works.
___
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] w32codecs [Was: dconf-editor dropped, gedit-plugins, systemd, w32codecs]

[Austin English]

On Sat, Mar 12, 2016 at 12:20 PM, intrigeri  wrote:
> Hi,
>
> (splitting into a dedicated subthread, and reordering top-posted reply.)
>
> Austin English wrote:
>> On Mon, Mar 7, 2016 at 4:38 AM, intrigeri  wrote:
>>> Austin English wrote (07 Mar 2016 03:05:46 GMT) :
 That said, including win32 codecs is probably worthwhile.
>>>
>>> Don't hesitate elaborating if you think it's worth it :)
>
>> Well, as emmapeel said when libdvdcss originally was discussed:
>> "I think access to culture is a very important right for people, and I
>> would be happy that Tails helps to make access to restricted/corporate
>> culture more easy, providing a framework to criticize it and create
>> their own."
>
> I see a bunch of .dll files in the w32codecs tarball I got (there
> seems to be various flavours of it, so it might be that we're not
> talking of the same thing; in which case it would be nice to specify
> more clearly what exactly is being proposed for inclusion).

I hadn't seen that before. This is a low priority for me, my concern
is that .wmv / .wma files may not be usable under tails currently
(unverified), and if that were the case, I'd like to see if that's
fixable. I have not had a chance to see if that is the case, and if it
is, what packages fixes it, but I'll be sure to check that they aren't
running windows binaries.

> I am sensitive to the "access to culture" argument up to a point, but
> including closed-source binary code that runs on the main CPU is quite
> far beyond that point; to be clear, it's in veto-land for me.

Ack.

-- 
-Austin
___
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] Detecting hidden partitions?

[Austin English]

On Sat, Mar 12, 2016 at 4:45 PM, intrigeri  wrote:
> Hi,
>
> (reordered due to top-posting)
>
> Austin English wrote:
>>> I would try to help, but I don't know what you mean with "hidden
>>> partitions" exactly. Could you please clarify how this translates into
>>> non-ambiguous technical concepts?
>
>> This is for https://labs.riseup.net/code/issues/11137, trying to any
>> partitions that are listed in the partition table.
>
> Missing word?

Yes, 'detect':
This is for https://labs.riseup.net/code/issues/11137, trying to
detect any partitions that are listed in the partition table.

> IMO for #11137, checking the content of the Tails system partition
> is enough, so no need to check for "hidden" partitions. But if you
> want to:
>
>> I used a hidden FAT32 partition for testing:
>> 1g.img2 206848  227327   20480   10M 1b Hidden W95 FAT32
>
>> my other thought was checking the Partition ID, unless someone knows a
>> better way.
>
> OK.
>
> Is this about detecting partitions whose type is "Hidden W95 FAT32"?
>
> Or is it any broader?

It was not my original idea, it was originally proposed here:
https://mailman.boum.org/pipermail/tails-dev/2016-February/010303.html

Though I'm considering dropping that portion of the idea because there
is a lot of confusion about it. I'm not sure what exactly is
desired/requested, or how to find the information needed to detect
these partitions properly and being put in a position to defend those
decisions is not a place I like being.

-- 
-Austin
___
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] Link type in persistence.conf, WAS: Tails Server: updated plan and GSoC!

[Andrew Gallagher]

On 24/03/16 13:40, sajolida wrote:
>
> in
> #10543#note-6 [1] you'll find my snippet to add custom files to
> /etc/apt/sources.list.d/.
> 
> [1]: https://labs.riseup.net/code/issues/10543#note-6

This is *exactly* my use case. Thank you!

A



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] [RFC] Design of our freezable APT repository

[intrigeri]

Hi,

anonym wrote (17 Mar 2016 17:18:11 GMT) :
> intrigeri:
>> anonym wrote (10 Mar 2016 20:06:31 GMT) :
 Freeze exceptions
> [...]
>>> BTW, it would be great to have a linting tool that compared the current
>>> APT pinnings vs what is available in the current Debian branches used
>>> given some Tails source checkout.
>> 
>> I'm open to adding ideas of helpful tools to the blueprint.
>> 
>> I'll need help to specify more clearly what problem we want desired
>> tools to solve, and how.
>> 
>> If I got it right, you want to know something like "what would happen
>> if we dropped our APT pinning", right? Do we want to know that for the
>> case when we remove APT pinning we have set up to grant freeze
>> exceptions only, or all APT pinning? The former, I guess, right?

> Well, I'm not sure how it would be determined if a pinning was added for
> a freeze exception exactly, and not some other purpose.

We could for example have a filename pattern, for snippets dropped in
/etc/apt/preferences.d/, that is specific to those added for
freeze exceptions.

> Any way, this
> tool seems to be useful in the latter case you talk about too, to keep
> our pinnings trimmed, especially if we become a rolling distro, and may
> have to frequently pin stuff (security updates) from Debian Unstable.
> Furthermore, I expect this latter case to be easier to solve, and I
> think I'd be happy enough with that one solved -- with informative
> enough output it will be easy enough to use it for the first case too.

OK. To be clear, I won't move forward on it until it's clarified what
problem this would help solve in the current state of things (we're
not a rolling distro), as this is not obvious to me yet. Besides, I'm
not sure it's feasible to easily solve any such interesting problem we
would have in real world situations.

And of course, I'll prioritize higher designing and implementing
a solution to the problems raised in the "Freeze exceptions" section,
that have to face somehow.

 Garbage collection
>>> [...]
>>> but my point is that the garbage collector will have to
>>> chech each branch, right?
>> 
>> I think this would be over-engineering it a lot, given what our actual
>> use cases are.

> Indeed, some minor manual work can work around this, as you point out.

> [...]
>> Speaking of which, I see two main ways to handle the garbage
>> collection process:
>> 
>> a. use a manually maintained list of snapshots that need to be
>>kept around, as the blueprint currently suggests;
>> 
>> b. rely on Valid-Until; i.e. the way to express "I want to keep
>>a given snapshot around" would be to postpone its expiration date;
>>I see no reason to differenciate "keep a given snapshot around"
>>from "keep a given snapshot usable".
>> 
>> I think we should do (b), _and_ have some cronjob warn us if we're
>> going to have serious problems, e.g. if the snapshot used by a frozen
>> testing branch is going to expire (and be deleted); this avoids the
>> need to maintain a list of exceptions.

> This sounds reasonable.

>> Let's discuss separately the two main cases:
>> 
>>  * frozen testing branch: we rarely freeze for more than 10 days, so
>>in the general case there's no problem; and the cronjob check
>>mentioned above should help us deal with corner cases.

> Sure, but it *does* happen. Let's just make it explicit in the freeze
> section of the release docs to explicitly set the snapshot expiry to the
> expected release date + 5 days to account for release delays.

Right, thanks. feature/5926-freezable-APT-repository had something
that was too vague about it, now clarified with e51c9aa.

>>> However, I see nothing about how to deal with Debian packages that
>>> fetches something external at install time (firmwares, sources illegal
>>> in some jurisdictions). This sounds like a non-trivial problem, and I
>>> really wonder what your thoughts on solutions are.
>> 
>> Indeed, that's outside of the scope of the current "freezable APT
>> repository" project.

> I see. This implies that there is no explicit goal (yet) to make each
> Tails release buildable "forever", correct?

Correct. Even the "tagged APT snapshots" feature we are working on is
a bonus, that is not part of the formal goals of the deliverable this
is part of.

>> My current best solution for that is to package
>> all these things as .deb's somewhere (possibly in a very ad-hoc way in
>> our own overlay APT repo), so we get them handled (snapshotted etc.)
>> for free just like any other package. What do you think?

> Isn̈́'t the problem that some of these Debian packages fetch these blobs
> from static URLs during package installation? How would a .deb
> containing the blobs help, then? Is there some Debian packaging
> mechanism that all of these use that looks for files in some cache first
> where you intend to place them?

I've not put much thought into it yet, and will skip it for now.
But yes, probably something like that.

>>> Crazy idea: along with the 

Re: [Tails-dev] About the future of the OpenPGP verification instructions

[sajolida]

sajolida:
> As a reminder, I initially submitted a branch for 2.0 which removes the
> current OpenPGP verification instructions. We ended up not doing this
> and, for the time being, pointing to the Installation Assistant by
> default, pointing to the old installation instructions as a fallback,
> pointing to the old OpenPGP instructions from the "Learn how to do this"
> link after a successful verification through the browser extension, but
> we didn't decide yet about the future of these old pages.
> 
> The ticket is #11027.

^ Ping six weeks later. This is on the agenda for the next monthly
meeting and I'd really like to move this forward to be able to wrap up
the IA release. So let me set a deadline on April 3 (the next monthly
meeting) to agree on something. If we don't I'll submit something very
similar to what I did for 2.0, ask tchou to review it, and do the merge.
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Tails Server service template format and UI [Was: Tails Server: updated plan and GSoC!]

[sajolida]

anonym:
>   - allow-lan-connections:

I haven't read anonym's email in detail but this option might be
relevant for many (all?) services (like "Auto-start" as I suggested
yesterday).
___
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] Link type in persistence.conf, WAS: Tails Server: updated plan and GSoC!

[sajolida]

Andrew Gallagher:
> On 23/03/16 18:30, sajolida wrote:
>> You can use the "link" type in persistence.conf. I've done similar
>> things already while playing with #10543.
> 
> Could you point to a doc/howto for doing that? It might save me some
> grief in something else I'm playing with...

#10543 is about writing the doc, so I don't have it yet. But in
#10543#note-6 [1] you'll find my snippet to add custom files to
/etc/apt/sources.list.d/.

[1]: https://labs.riseup.net/code/issues/10543#note-6
___
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] Link type in persistence.conf, WAS: Tails Server: updated plan and GSoC!

[anonym]

Andrew Gallagher:
> On 23/03/16 18:30, sajolida wrote:
>>
>> You can use the "link" type in persistence.conf. I've done similar
>> things already while playing with #10543.
> 
> Could you point to a doc/howto for doing that? It might save me some
> grief in something else I'm playing with...

You'll find some helpful examples for our existing "Dotfiles"
persistence feature which uses the "link" feature on /home/amnesia:


https://tails.boum.org/doc/first_steps/persistence/configure/index.en.html#index13h2

I also recommend the persistence.conf man-page.

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.