[Tails-dev] Release schedule for Tails 2.4

[anonym]

Hi,

I'll be the release manager for Tails 2.4, which is a major release
scheduled on 2016-06-06. The list of tickets targeting Tails 2.4 can be
found here:

https://labs.riseup.net/code/projects/tails/issues?query_id=193

Here's the preliminary release schedule for Tails 2.4:

* 2016-05-25:
   - Feature Freeze: All feature branches targeting Tails 2.4 should
 be merged into the `devel` branch by noon, CET. I'm open to make
 exceptions if you can be online and responsive during that
 afternoon, but ask me first!
   - Build and upload Tails 2.4~rc1.
   - Start testing Tails 2.4~rc1 during late CET if building the image
 went smoothly.

* 2016-05-26:
   - Finish testing Tails 2.4~rc1 by the afternoon, CET.
   - Release Tails 2.4~rc1.

* 2016-06-06:
  - All branches targeting Tails 2.4 *must* be merged into the `testing`
branch by noon, CEST.
  - The upcoming Tor Browser is hopefully out so we can import it.
  - Build and upload Tails 2.4 ISO image and IUKs.
  - Hopefully start testing Tails 2.4.

* 2016-06-07:
  - Finish testing Tails 2.4 by the afternoon, CEST.
  - Release Tails 2.4 during late CEST.

Testers, please let me know:

* if you are available on 2016-05-25, late CEST

* if you are available on 2016-05-26, morning to afternoon, CEST.

* if you are available on 2016-06-06, late CEST

* if you are available on 2016-06-07, 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 more scripts from bash to python

[anonym]

sajolida:
> GoodCrypto Support:
>> We are about to have some time to port more scripts from bash to
>> python.
> 
> Nice!

Awesome!

>> Sajolida kindly let us know the git part looked right. We'd prefer to
>> know these scripts are what you're looking for before we do more. If
>> delays in feedback are normal, just let us know.
> 
> Two days ago I mentioned your work on the ticket [1] and marked it for
> review by anonym. Until he does that I cannot tell you more.

I have been following this, but due to several unexpected pieces of work
that has ended up on my plate I'm finding it very hard to take the time
to review this.

I'm really sorry about this, GoodCrypto folks. I'll try to schedule time
for it next month, but honestly I cannot promise anything (especially
now that I became a GSoC mentor too). But, rest assured, it *will*
happen eventually, definitely no later than mid-summer.

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-0.9.25~Tails-2.3

[anonym]

anonym:
> pr0ng:

>> I believe I've repackaged the 0.9.25 to 'conform' to the Tails layout
>> correctly and will be rebuilding the Tails dev branch with 0.9.25
>> over the next couple of days when I get another block of time, likely
>> mid-week ~ 20, 21st?
>>
>> [...]
>>
>> Although I am able to explode the .deb from i2p (.25) and repack as
>> required I am not yet fully up-to-speed with how I 'release' this after
>> testing, so I will refer to zzz for some advice on that matter and if
>> you have any pointers on this, please do shout! :)
> 
> [...]
> 
> However, now it seems we'll have a non-official package for Tails. I
> wonder, why can we not use the Debian Jessie ones? That makes me think
> that Tails, rather, should adapted so the normal deb8 packages can be
> installed. Could you please elaborate?

So, I have built a Tails image with the 0.9.25-1~deb8u+1 packages from
deb.i2p2.no and it seems to work just fine. So what is the purpose of
repackaging them into 0.9.25~Tails-2.3 to "conform" to Tails? It doesn't
seem necessary on first glance.

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-0.9.25~Tails-2.3

[anonym]

pr0ng:
> 
> Hi Tails!
> 
>>> We have named pr0ng the new maintainer for I2P in Tails.
>>> Pr0ng has I2P, Tails, and some Debian packaging knowledge,  
> 
> pr0ng here. I was last contacted via zzz(@i2p) who forwarded me the
> mail from anonym. Nice to be aboard, looking forwards to maintaining
> the i2p system as part of the Tails distribution. :)

I can only repeat (now in public) the following:

>>> Woo! \o/ Welcome aboard, pr0ng!  

:)

>>>> and has already gotten far enough to be testing I2P 0.9.25
>>>> on Tails.  
> 
>>> Does this mean,  
> 
>>> 1. install the i2p .deb in a running Tails session, or  
> 
>>> 2. build a Tails image that have i2p 0.9.25 installed from scratch
>>> [0]?  
> 
> 1) I was originally testing the .deb running in a Tails session from
> the Ubuntu release I had knocking around, to (a) look at the
> differences between an 'ordinary' installation and one from within
> Tails itself and (b) make sure functionality was as expected.
> 
> Since then I have moved onto building Tails from the [0]
> https://tails.boum.org/contribute/build/
> 
> Had a few issues with manual build of Tails initially, mostly due to my
> immediate ignorance, but this gave me the opportunity to understand the
> process for a live-build from scratch and correct some of the issues as
> I went along which was a good learning process.
> 
> Now I'm happily building Tails 2.2.1 using the Puppet/Vagrant setup you
> documented. I needed to go through these steps initially to feel
> comfortable with the tools, requirements etc.

Cool! Do not be afraid to ask before spending too much time trying to
figure these things out. The current state of the vagrant build setup is
a bit crap, but we're in the process of migrating it from VirtualBox to
libvirt/KVM and will from them on maintain it better so things will
likely get easier.

> I believe I've repackaged the 0.9.25 to 'conform' to the Tails layout
> correctly and will be rebuilding the Tails dev branch with 0.9.25 over
> the next couple of days when I get another block of time, likely
> mid-week ~ 20, 21st?
> 
> I've (just today) subscribed to the tails-dev@boum.org mailing list and
> expect I'll be able to continue updates via this going forward.

You might also want to register an account on our bug tracker:

https://labs.riseup.net/code/projects/tails

> Although I am able to explode the .deb from i2p (.25) and repack as
> required I am not yet fully up-to-speed with how I 'release' this after
> testing, so I will refer to zzz for some advice on that matter and if
> you have any pointers on this, please do shout! :)

Previously this is how it worked: the I2P package maintainer uploads the
official i2p Debian packages to deb.i2p2.no. S/he builds a Tails with
the package for the Debian version Tails is based on (so Jessie at the
moment). If all is ok, s/he creates a ticket ("Import I2P x.y.z") on our
bug tracker, and assigns the ticket to the Release Manager (me,
generally, see our calendar [0]) with "QA Status = Ready for QA". Then I
take over. Makes sense?

[0] https://tails.boum.org/contribute/calendar/ -- essentially, unless
otherwise specified, I'm the RM.

However, now it seems we'll have a non-official package for Tails. I
wonder, why can we not use the Debian Jessie ones? That makes me think
that Tails, rather, should adapted so the normal deb8 packages can be
installed. Could you please elaborate?

>>> Since the 0.9.25 packages are up on deb.i2p2.no already I think we'll
>>> get it into Tails 2.3 (note that it has been delayed until 2016-04-26
>>> due to Mozilla delaying the next Firefox ESR until then). pr0ng, if
>>> you please send an email with your current progress to tails-dev@ and
>>> I'll detail what remains to make that happen -- if you hit a
>>> stumbling block (e.g. building Tails is not so easy at the moment)
>>> I'm sure I can help or even take over parts.  
> 
> Basically, I just need to read a little more methinx. I will do the
> repack and rebuild mid-week and then come back to you with a request
> for assistance at that point - should this also be directed to the
> mailing list? Happy to do things out in the open, just not sure of
> protocol etc! Will check my mail on i2p now to see if my
> subscription is 'active' and such.

Like I said above, the preferred way to notify us that we should import
some packages are via a new ticket in our bug tracker.

> Pleased to be involved - I'm a big Tails evangelist (as well of course
> of i2p :)) ~ speak shortly

Yay, we'll happy to have you! :)

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] [NEW SCHEDULE] Release schedule for Tails 2.3

[anonym]

Hi,

Due to Mozilla delaying the Firefox releases by a week, the next Tor
Browser and (hence) Tails releases will be delayed as well. So, the new
release date for Tails 2.3 is 2016-04-26. Below I'll post an updated
schedule and testing dates:

Here's the preliminary release schedule for Tails 2.3:

* 2016-04-25:
  - All branches targeting Tails 2.3 *must* be merged into the `stable`
branch by noon, CEST.
  - The upcoming Tor Browser is hopefully out so we can import it.
  - Build and upload Tails 2.3 ISO image and IUKs.
  - Hopefully start testing Tails 2.3.

* 2016-04-26:
  - Finish testing Tails 2.3 by the afternoon, CEST.
  - Release Tails 2.3 during late CEST.

Testers, please let me know:

* if you are available on 2016-04-25, late CEST

* if you are available on 2016-04-26, 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.

[Tails-dev] Release schedule for Tails 2.3

[anonym]

Hi,

[Meta: sorry for sending this late! OTOH, it's so formulaic, that any
one paying attention probably could have guessed the schedule below. :)]

I'll be the release manager for Tails 2.3, which is a minor release
scheduled for 2016-04-19. The list of tickets targeting Tails 2.3 can be
found here:

https://labs.riseup.net/code/projects/tails/issues?query_id=192

Here's the preliminary release schedule for Tails 2.3:

* 2016-04-18:
  - All branches targeting Tails 2.3 *must* be merged into the `stable`
branch by noon, CEST.
  - The upcoming Tor Browser is hopefully out so we can import it.
  - Build and upload Tails 2.3 ISO image and IUKs.
  - Hopefully start testing Tails 2.3.

* 2016-04-19:
  - Finish testing Tails 2.3 by the afternoon, CEST.
  - Release Tails 2.3 during late CEST.

Testers, please let me know:

* if you are available on 2016-04-18, late CEST

* if you are available on 2016-04-19, 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] 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.

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

[anonym]

anonym:
> segfault:
>>> - We know have a script to run a Mumble server from Tails [4] and are
>>> considering adding it to Tails [5].
>>>
>>> [4]: https://labs.riseup.net/code/issues/9993
>>> [5]: https://labs.riseup.net/code/issues/11241
>> Yes, that's great! And the current version is really nice. I already
>> have some scripts written on my own to start other services, but the
>> mumble server one definitely does some things nicer than I do - it will
>> be very helpful during this project. Although it's a shell script and I
>> will implement the server in python3.

One idea to have a consistent UX between the CLI and GUI is to make the
CLI output simple and parsable (YAML!) so that the GUI simply populates
its view according to it. Here follows a pretty detailed example for how
this can be designed, with quite some hints of the implementation [note,
all this is of course up for heavy discussion, and by no means will I
require you to strictly follow this -- but I want the final design to
have some of the properties of this e.g. the GUI/CLI duality, and the (I
expect) ease of maintenance and creating new templates due to modular
design and easy code sharing]:

Let's start from the CLI perspective, with an imagined `tails-service`
command. The following lists the services we have enabled:

$ tails-service --list-enabled


i.e. none currently (the "<...>" part is not part of the commands
output!). The following lists all services we gave templates for:

$ tails-service --list-all
- docuwiki
- gobby
- lighttpd
- mumble-server
- owncloud
- prosody
- securedrop
- sshd
- unrealircd

In fact, this should just be the directory listing of all executable
files in some directory, e.g. `/usr/local/lib/tails-services`. The point
here is that each service is a self-contained script, and once we
specify one to `tails-service` it is just a wrapper around it,
forwarding all arguments.

Let's check a single service's status:

$ tails-service mumble-server
- status: not enabled

or, equivalently:

$ /usr/local/lib/tails-services/mumble-server
- status: not enabled

The --description option doubles as both --help (so let's make it an
alias?) on the CLI, and as a way for the GUI to learn everything it
needs to know about a service template. For user options we may try to
keep it simple and allow two data types for values:

* 'simple' which is just a string (since these things generally are to
be inserted into configuration files, that's all we need), and
corresponds to an text field in the GUI.

* 'simple-options' which is a static list of predefined 'simple'
strings, and corresponds to a drop-down menu (or radio buttons?) in the GUI.

$ tails-service mumble-server --description
- description: A VoIP-enabled chat server
- documentation:
/usr/share/doc/tails/website/doc/tails-server/mumble-server/
- icon: /path/...
- user-options:
  - motd
- description: Set a message displayed to users upon logging in
- type: simple
- default:
  - allow-lan-connections:
- description: Allow connections from the local network
- type: simple-options
- values:
  - yes
  - no
- default: no

If we feel this output is too ugly for CLI users, the source for the
--description output can also be used to generate a nicer --help output
as well. Any way, the point here is that the GUI can bootstrap by
running `tails-service --list-all` and then for each $service it runs
`tails-service $service --description` to learn all it must know for
generating the GUI.

Here's a mockup of a possible GUI, with the point not being that U
expect it to be the final GUI, but rather that it's an example that
would be fairly simple to generate programmatically given the YAML
output I suggest for the various `tails-service` commands above:

 
|  Tails Server configuration   X|
||
| [... other services ... ]  |
||
| R mumble-server ? - A VoIP-enabled chat server |
| [ Enable ] |
||
| [... other services ... ]  |
|_ __|

* The above "R" is a red indicator meaning that the service is not
enabled. Alternatively, perhaps it can be the icon, which is greyed out
when disabled?

* The "?" is a link that will open the local documentation of the
service, probably in Tor Browser via the `tails-documentation` helper
script.

* When clicking the "[ Enable ]" bu

Re: [Tails-dev] Tails Server: updated plan and GSoC!

[anonym]

segfault:
>> - The integration of OnionShare is moving forward [2] with some patches
>> proposed to our tor-controlport-filter to support creating ephemeral
>> onion services.
>>
>> [2]: https://labs.riseup.net/code/issues/7870#note-15
> I took note of this, but as I understand it, this will only enable
> _ephemeral_ onion services, not reuse a key and onion address generated
> previously, right? I plan to support both, persistent and ephemeral
> onion services. Currently I think I will have to bind mount the hidden
> service directory and reload Tor, just like it in the mumble server script.

You can restore an old onion key with the `add_onion` command (see [0],
section 3.27) so it is no only for ephemeral services. If stem makes
this extremely easy we may consider using it, but since we'll need admin
rights for other parts of setting up services, the point of using
`add_onion` is sort of lost (it's use case is: "you are non-root _but_
have access to Tor's control port"). I'm leaning towards a more KISS
approach of adding/deleting the corresponding two lines in torrc +
`systemdctl reload tor` (i.e. what we do in the mumble-server script).
That approach will turn even more elegant once we have torrc.d
functionality [1].

[0] https://gitweb.torproject.org/torspec.git/tree/control-spec.txt
[1] https://trac.torproject.org/projects/tor/ticket/1922

>> - We know have a script to run a Mumble server from Tails [4] and are
>> considering adding it to Tails [5].
>>
>> [4]: https://labs.riseup.net/code/issues/9993
>> [5]: https://labs.riseup.net/code/issues/11241
> Yes, that's great! And the current version is really nice. I already
> have some scripts written on my own to start other services, but the
> mumble server one definitely does some things nicer than I do - it will
> be very helpful during this project. Although it's a shell script and I
> will implement the server in python3.

I think there are a few lessons to take home from the mumble-server
script regarding configuration:

* The scripts configuration bits should be idempotent and always ensure
that the full expected configuration is in place: this simplifies things
a lot and generally results in more robustness by making sure we don't
end up in "half-configured" broken states that we cannot automatically
recover from, and by making many assumptions explicit and handled.

* It's pretty nice to use Debian's default configuration as templates
since they generally set sane and secure settings by default, and are
maintained. Since this implies that we have to patch an existing
configuration, I expect us to end up using ugly regex-based solutions,
but I think it provides so many advantages that it is worth it.
Otherwise we could provide our own template configurations and use ERB,
but then we need to maintain these ourselves (e.g. sync with Debian's
configurations regularly) and I expect it will make user modifications
to configurations much harder to support.

* The script is oblivious to whether persistence is used or not, which
reduces script complexity. It just puts the service's data files in the
directory that would be made persistent, and then it's up to that
feature to make it so, if the user so chooses. Other configurations
(e.g. in /etc) are handled by the idempotent configuration mentioned
above, and is applied in full each time to the expected state. The
problem here is we probably want to support arbitrary user configuration
so if we take mumble-server as an example we'd then need to make
/etc/mumble-server.ini persistent too, some how.

One thing to note about the mumble-server script is the "little
bind-mount trick" used to workaround Tor's AppArmor confinement. We
won't have that problem, I think. I did that so that all things we want
to make persistent for mumble-server lives in the same directory on the
persistent media, i.e. both Tor's HS bits, and mumble-server's data. We
certainly can do better by making these two separate, e.g. we make
/var/lib/tor/hs persistent and store all HS bits there, and then make
another directory outside of this persistent for the service
configuration/data bits.

- We have some very rough instructions to serve HTTP requests from Tails
>> [6] and segfault has been working on making this available even when no
>> administration password is set in Tails Greeter [7].
>>
>> [6]: https://labs.riseup.net/code/issues/10970
>> [7]: https://labs.riseup.net/code/issues/7879
> 
> I think this is a misunderstanding - actually my scripts need to be
> executed as root and were never supposed to work without root. That
> would definitely be a nice feature, but I don't think I will make this a
> requirement for the GSoC project, because I think it won't be easy to
> realize.

Agreed.

>> - In [9] the blueprint seems to not take into account that we already
>> have the Additional Software persistence feature.
>>
>> [9]: https://tails.boum.org/blueprint/server_edition#index11h2
> We could use the Additional Software persistenc

Re: [Tails-dev] [RFC] Design of our freezable APT repository

[anonym]

intrigeri:
> Hi,
> 
> anonym wrote (10 Mar 2016 20:06:31 GMT) :
>>> Upgrading to a new snapshot
> 
>> I expect it to be quite rare that we need to encode a particular
>> snapshot in a topic branch, which is both good and bad. Good, because we
>> then do not have to deal with the problems it may cause very often; bad,
>> because it happens rarely enough that one might not look for the
>> problems all the time, and hence let them slip through. :)
> 
>> Specifically, I fear that we may have problems with merging topic
>> branches that encode some snapshot into a base branch, and then forget
>> to remove the encoding (or otherwise deal with it in a sane way) so it
>> messes up the base branch.
> 
>> Have I missed/misunderstood something?
> 
> First of all, such encoding of snapshots is an integral part of
> proposed changes in such a topic branch; it's something one needs to
> carefully review when merging, just like any other code change. In the
> general case, merging a topic branch that encodes some snapshot into
> a base branch means "I want that base branch to use that snapshot",
> and most of the time the purpose of such a topic branch will precisely
> be to bump snapshot references to newer versions, so in general
> we should be good.

Ack, fair enough.

> Let's look at the scope of potential problems though:
> 
> * The devel branch is not affected since it "always uses the freshest
>   set of APT repository snapshots available" (I'm not 100% sure yet
>   but I think this will simply be fully automatic so one can't mess up
>   with it by mistake).

In the future, if we become a rolling distro based on Debian Testing,
we'll have to reconsider this, but the design indeed allows us to change
this behaviour easily, so let's forget about it for now.

> * The testing branch can be affected by this problem, between the time
>   the faulty merge is done, and the time we release something based on
>   testing (since "the RM encodes in the `testing` Git branch the fact
>   that it is not frozen anymore"), that is our code freeze period.
>   That's the time during which the snapshot references encoded in Git
>   are most important, and we'll be frozen, so I expect we'll be
>   careful about how we deal with such information on the
>   testing branch.
> 
> * The handling of the stable branch in this respect is less clearly
>   specified, but I suspect it'll be quite close to the
>   testing branch's.

Agreed. And for the stable branch we also need to be extra careful since
this is the type of issue one does not have to spend brain power on
resolving in case of an emergency release.

> ⇒ I'm not too concerned about this problem :)

Now I'm not either any more, thanks!

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

>>> Another option, instead of adding/removing temporary APT pinning,
>>> would be to backport the package we want to upgrade, and make it so it
>>> has a version greater than the one in the time-based snapshot used by
>>> the frozen release branch, and lower than the one in more recent
>>> time-based snapshots.
> 
>> This makes me really unenthusiastic. Please do not underestimate the
>> added overhead of having to rebuild packages for trivialities like this.
>> I stronly object to this approach.
> 
> Agreed ⇒ made it clear on the blueprint that this approach is NACK'ed.

\o/

>>> Number of distributions
>>>

Re: [Tails-dev] Tail 2.2 Ugly as HELL

[anonym]

sajolida:
> freedom-m...@sigaint.org:
>> There is any chance of Tails OS see other version that looks like the 1.6?
>> The 2.2 version is UGLY AS HELL.
> 
> I agree :)
> 
> We switched to GNOME Shell in Classic mode (with the grey menus) because
> we wanted to continue providing the top-left Applications and Places
> menus and the bottom windows list. But this can be achieve equally in
> GNOME Shell without the Classic mode by enabling these extensions.
>
> The thing is that changing the appearance of the desktop implies
> updating many things in our automated test suite which is based on
> screenshots of the desktop. So I understand that our test suite
> engineers are not really happy to do additional work just for aesthetic
> (not that aesthetic is not important but they are overloaded already).

If the automated test suite's images is the only "blocker", I think we
could do the switch. Feel free to prepare a branch, and we'll see.

Are you sure there would be no other changes? IIRC pure GNOME Shell deal
with switching between applications (think: alt+tab) in a "novel" way.

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] Post-2.2 Readmine follow-ups

[anonym]

Hi,

I would like everyone to take a careful look at their own Redmine view,
grouped and ordered by Target version:

https://labs.riseup.net/code/projects/tails/issues?query_id=128

Tails 2.2 was released a week ago, but there are still 48 tickets
targeting it. Please take care of those that are assigned to you, and
also make sure that your resulting view for 2.3 (and forward) looks sane.

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 bash to python

[anonym]

Nan:
> Hi!

Hey!

> We'd like to help convert Tails bash scripts to python. We've done
> that a lot with GoodCrypto.

Great! We're looking forward to your pull requests. :)

Please let us know if there is anything else you need for starting not
covered in our general coding contribution guidelines [0] and what's
already on the blueprint [1].

> If anyone wants a few pages of notes on some quirks of the sh module,
> just let us know.

This sounds like a great resource to add to our blueprint [1] perhaps in
the "Guidelines" or "Tips and tricks" sections. Note that our blueprints
are open for edits via the web interface, and you are very welcome to
influence the direction of this effort by editing it (bigger changes are
of course encouraged to first be discussed on this mailing list).

Cheers!

[0] https://tails.boum.org/contribute/how/code/
[1] https://tails.boum.org/blueprint/Port_shell_scripts_to_Python/

___
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] Review our list of SSH ciphers and MACs

[anonym]

intrigeri:
> I hereby propose that we:

I fully ack your conclusions and plan.

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

[anonym]

intrigeri:
> We need input from people who are into release management

I am! :)

First off, awesome work, intrigeri and kibi! I'm really looking forward
to the time when this is available. We have such grand ideas based on it!

I have read through the topic branch's changes to the release steps, to
get a feel for how it would change things for our Dear Eternal Release
Manager, and it all makes sense to me and looks like it will add little
to not extra burden at release time, which is great. I do not, however,
particularly like the part where we "build the almost-final image" to
generate the package manifest. I get why we need it, and it sort of
shows one thing: determining which packages a given Tails build will use
is still a very hard problem. Oh well. :)

Next quotes from the blueprint, commit 9256153:

> Upgrading to a new snapshot

I expect it to be quite rare that we need to encode a particular
snapshot in a topic branch, which is both good and bad. Good, because we
then do not have to deal with the problems it may cause very often; bad,
because it happens rarely enough that one might not look for the
problems all the time, and hence let them slip through. :)

Specifically, I fear that we may have problems with merging topic
branches that encode some snapshot into a base branch, and then forget
to remove the encoding (or otherwise deal with it in a sane way) so it
messes up the base branch.

Have I missed/misunderstood something?

> Freeze exceptions
[...]
> 2. Pin, in config/chroot_apt/preferences, the upgraded package we
> have just imported. The aforementioned tool can do this as well.
> 
> [Our current default APT pinning ranks Tails overlay APT suites over
any other APT source, so why the need to add an APT pinning entry? The
problem is that it's hard to do the next step (clean up) with this APT
pinning, combined with the fact that we can't easily delete a package
from an APT suite and see this deletion propagated over suite merges. I
(intrigeri) was not able to find a good solution to that problem under
these constraints, so [...] this document assumes that we change this,
and pin our overlay APT suites at the same level as the APT sources
corresponding to the Debian release Tails is currently based on. This
implies that we manually pin, in Git, the packages from our overlay APT
suites, that we want to override the ones found in other repositories
regardless of version numbers.]

I actually think making the packages we want more explicit is a good
thing for transparency, and makes it easier, as a developer, to quickly
see how we diverge from Debian by just looking in Git. In general, I
think I believe it is better to have as much as possible encoded in Git,
as opposed to other external repositories (APT or whatever).

However, the next point:

> 3. Make it so branches stop using the upgraded package once they
> have been unfrozen [...]

indeed exposes the problem. Manually removing the added pinnings feels a
bit error prone and cumbersome. However, this clean-up will only happen
when branches are unfreezed, which is only after releasing, so it
doesn't sound too bad. Right?

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.

> Another option, instead of adding/removing temporary APT pinning,
> would be to backport the package we want to upgrade, and make it so it
> has a version greater than the one in the time-based snapshot used by
> the frozen release branch, and lower than the one in more recent
> time-based snapshots.

This makes me really unenthusiastic. Please do not underestimate the
added overhead of having to rebuild packages for trivialities like this.
I stronly object to this approach.

> Number of distributions
> 
> ... in reprepro's conf/distributions, for the reprepro instance(s)
> dedicated to taking snapshots of the regular Debian archive, assuming
> other mirrored archives such as security.d.o, deb.tpo, etc. each go to
> their own reprepro instance.

This make it sound like the design itself fixes which APT sources are
possible to use, and that it will be a pain to add new ones. Or will
some puppet magic automatically set up a new reprepro instance when a
new source is added in any random branch? If so: crazy! :)

To make the problem a bit more concrete, you later list:

> torproject: 5 (oldstable, stable, testing, unstable, obfs4proxy)

which doesn't include the *-experimental branches. How would we deal
with a Tor-alpha integration branch, for instance? Would we be force to
follow the releases manually, and then upload them ourselves to e.g.
deb.t.b.o?

Something I think we still need to support is adding APT sources (to
{{binary,config}/chroot_sources) that exist outside of the freezable APT
repo system. I imagine this will remain useful for conributors which do
not have the ability to upload packages to any of the already added
ones. Sure, we have c

Re: [Tails-dev] Heads up! Upgrade your ISO build setup to Jessie

[anonym]

Austin English:
> On 02/22/2016 07:02 AM, intrigeri wrote:
>> Hi,
>>
>> anonym just merged the branch for #9262 aka. "Port our ISO build
>> system to Jessie", so if you have an ISO build setup, you need to
>> upgrade it:
>>
>>  * manual build system
>>
>>See the updated doc: https://tails.boum.org/contribute/build/#manual
>>
>>  * Vagrant (untested)
>>
>>rake vm:destroy
>>rm -r vagrant/.vagrant
>>rake vm:up
>>
>> Please report any issues to us :)
>>
>> JFTR, our Jenkins ISO builders have been upgraded yesterday already.
>>
>> Cheers,
> 
> It broke vagrant for me:

Argh!

Spoiler: once we're based on vagrant-libvirt (#6354) the Vagrant build
env should be stable since most (all?) developers will switch to it, and
our Jenkins build slaves as well.

> [default] Waiting for machine to boot. This may take a few minutes...
> rake aborted!

This was also the error you (and me!) got when using Sid's incompatible
version of net-ruby-ssh. Can you please try

sudo apt-get install ruby-net-ssh/jessie

and then remove your current broken instance (execute from the Tails
source root dir):

rake vm:destroy
rm -r vagrant/.vagrant

and then

rake vm:up

If this fixed your issue you may want to pin jessie's version of this
package so this situation won't return every time you update your system.

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] Heads up! Upgrade your ISO build setup to Jessie

[anonym]

Muri Nicanor:
> the 'libeatmydata.so cannot be
> preloaded' warning is still there, but this doesn't break the build process.

It's a harmless warning so just ignore it.

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

[anonym]

Hi,

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!

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.

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.

So please let us know if you are interested in joining this
effort, and please also try to keep your excitment in check so
some of it remains in six months when this work will start for
real! :)

Cheers!

[0] https://tails.boum.org/blueprint/freezable_APT_repository/
___
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 Team looking at Tails

[anonym]

Austin English:
> On Tue, Feb 16, 2016 at 12:25 PM, Spencer  wrote:
>>> Austin English:
>>> write a wrapper for the greeter to detect if those files
>>> are present.
>>
>> It could also detect hidden partitions, correct?
> 
> Possibly, I'm not sure how that would be accomplished myself..

If you are referring to the "hidden partition" flag, then detection is
trivial. This flag is just that, a bit somewhere that if set, software
may *pretend* to not see it, if that has been implemented. :) Yes, a
piece of software not implementing the hiding would see it, just like
any other partition.

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] intrigeri vs. Tails Redmine

[anonym]

intrigeri:
>  * when you need my input on a ticket: assign it to me, ask me the
>question you want me to answer, and state what I should do once
>I've replied (re-assign to you? to someone else? etc.); ideally,
>someone else could also provide this input ⇒ add them as a watcher,
>or consider assigning to them instead :)

Always having to state this seems unnecessary and prone to just add
overhead and verboseness. IMHO the default action after answering to an
"Info needed" is to restore the previous assignee and QA Status => Dev
needed, or similar -- the important thing is that the assignee is
restored, so the "responsibility" for tracking the ticket is transferred.

> I wholeheartedly thank you all in advance! ♥

:)

> That's not all. I'll still need to follow changes to subsets of our
> Redmine. I don't know for sure since I've not clearly identified my
> needs ye, but I guess I'll have to improve our Redmine toolbox to make
> this possible. I suspect that some of you are in the same situation.
> Tell me your needs (privately or on some dedicated blueprint) and I'll
> try to take them into account while looking for solutions to mine.

Could you please clarify what you mean here? Obviously it's not
sustainable to rely on a single person (you) following all of Redmine,
but in order to not have tickets be forgotten or go unnoticed, we need
some processes and tools to deal with it instead. I assume this is what
you are getting at, and that you already has some ideas for it. Please
share!

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] Release schedule for Tails 2.2

[anonym]

Hi,

I'll be the release manager for Tails 2.2, which is a major release
scheduled for 2016-03-08. Note that there will be no Tails 2.1; for the
curious I suggest reading up on our versioning scheme:
https://tails.boum.org/contribute/release_schedule/#index4h1

The list of tickets targeting Tails 2.2 can be found here:

https://labs.riseup.net/code/projects/tails/issues?query_id=191

182 tickets! And there are still ~70 tickets targeting 2.0, so the
number is even higher. Please see my other email with subject "Post-2.0
Readmine follow-ups"!

Without further ado, here's the preliminary release schedule for Tails 2.2:

* 2016-02-24:
   - Feature Freeze: All feature branches targeting Tails 2.2 should
 be merged into the `devel` branch by noon, CET. I'm open to make
 exceptions if you can be online and responsive during that
 afternoon, but ask me first!
   - Build and upload Tails 2.2~rc1.
   - Start testing Tails 2.2~rc1 during late CET if building the image
 went smoothly.

* 2016-02-25:
   - Finish testing Tails 2.2~rc1 by the afternoon, CET.
   - Release Tails 2.2~rc1.

* 2016-03-07:
  - All branches targeting Tails 2.2 *must* be merged into the `testing`
branch by noon, CET.
  - The upcoming Tor Browser is hopefully out so we can import it.
  - Build and upload Tails 2.2 ISO image and IUKs.
  - Hopefully start testing Tails 2.2.

* 2016-03-08:
  - Finish testing Tails 2.2 by the afternoon, CET.
  - Release Tails 2.2 during late CET.

Testers, please let me know:

* if you are available on 2016-02-24, late CET

* if you are available on 2016-02-25, morning to afternoon, CET.

* if you are available on 2016-03-07, late CET

* if you are available on 2016-03-08, morning to afternoon, CET.

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] Post-2.0 Readmine follow-ups

[anonym]

Hi,

Ah, it's that time of the release cycle again! I would like everyone to
take a careful look at their own Redmine view, grouped and ordered by
Target version:

https://labs.riseup.net/code/projects/tails/issues?query_id=128

At the time of writing, there are 82 open tickets still targeting 2.0,
which need to be postponed. Please take care of those that are assigned
to you, and also make sure that your resulting view for 2.2 looks sane.

The following beast of a URL will give you a list of the unassigned
tickets for 2.0 and 2.2 (and probably NoScript will warn you about an
XSS attempt -- trust me, it's safe! :)):


https://labs.riseup.net/code/projects/tails/issues?utf8=%E2%9C%93&set_filter=1&f%5B%5D=fixed_version_id&op%5Bfixed_version_id%5D=%3D&v%5Bfixed_version_id%5D%5B%5D=214&v%5Bfixed_version_id%5D%5B%5D=247&f%5B%5D=status_id&op%5Bstatus_id%5D=%3D&v%5Bstatus_id%5D%5B%5D=1&v%5Bstatus_id%5D%5B%5D=9&v%5Bstatus_id%5D%5B%5D=7&f%5B%5D=assigned_to_id&op%5Bassigned_to_id%5D=%21*&f%5B%5D=&c%5B%5D=priority&c%5B%5D=subject&c%5B%5D=category&c%5B%5D=cf_15&c%5B%5D=cf_9&group_by=fixed_version

The good news are that there are only three of them, but let's try to
make that zero.

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] TAILS camouflage

[anonym]

Christian Medel:
> Hi @anonym
> yes, I'm Elbullazul from riseuplabs
> 
> I'll see the info from integri (hadn't had any time yet) and then I'll head
> over to the thread you just pointed to continue the discussion.

I think you should read what I'm proposing on the ticket first, since it
essentially says that you should skip the stuff intrigeri talked about.
I think it's better that you focus on the theme creation part instead of
spending a lot of time learning how to do these things yourself.

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] TAILS camouflage

[anonym]

Christian Medel:
> Hi,
> 
> Due to the lack of time of the "original" developers, I have come with the
> idea of maybe trying to create code to include the camouflage, hopefully in
> 2.0.

Awesome! And sorry for sort of dropping the ball in our previous
attempt. :/ Any way, time is short for Tails 2.0, so let's say this is
aimed for Tails 2.2 at best. :) That is 2016-03-08, so the theme must be
in a very good shape already in mid-February (or so) for us to have a
chance.

> I have done some research on how Debian loads up the system, but haven't
> found a specific file (or fileS) that starts up the DE.
> 
> Can someone indicate which files are those displaying, for example, the
> advanced options pop-up or the advanced options window BEFORE Gnome loads?

All this is a bit complicated, and I've tried to explain the parts that
should be relevant for you + suggest a strategy for how we can develop
this in a joint effort on the ticket:

https://labs.riseup.net/code/issues/10830#note-4

I would prefer if we could continue any discussion there.

Also, are you using the Elbullazul account on our bug tracker?

Cheer!

___
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] Please test Tails 2.0~rc1

[anonym]

Hi,

[please drop tails-dev@ from the list of recipients when replying --
thanks!]

Please consider answering the call for testing there:

  https://tails.boum.org/news/test_2.0-rc1/

Your help will be very much appreciated :)

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] Feature #5301 - Clone or Backup Persistent Volume

[anonym]

Andrew Gallagher:
> On 07/01/16 19:41, anonym wrote:
>>
>> I haven't tested it, but I did have a look at src/tcp-helper.c since the
>> necessity of memory unsafe code surprised me:
> 
> For the record, I never intended to use C. It was originally written in
> perl (like the GUI wrapper), but setuidperl is no longer supported and I
> needed to drop any requirement for sudo. The perl documentation suggests
> writing a setuid C wrapper that does (more or less)
>   "setreuid(0,0); system(MY_PROGRAM);"
> and then lists all the reasons why you shouldn't.

Ok. I'm not entirely sure why you'd need setuid.

> So I reluctantly rewrote the helper in C, and after getting angry with C
> I gave in and #included  (forgetting to rename the source
> accordingly). Much of my time since has been spent trying to extricate
> myself from the inevitable foot-shooting. ;-)

Ack!

> Rest of your comments fully understood,

:)

> hands in the air bang to rights guv.

What does this mean? I'm not a native English speaker, which possibly
explains it.

>> Best practice is to drop the input sanitation and pick alternatives to
>> `system()`/`popen()` that avoids invoking the shell and calls `exec()`
>> or similar. I'm too ignorant of C/C++ to recommend you anything.
> 
> Yes, these were originally perl system(,,,) and open(,,,) calls, which
> are safe as they don't invoke a shell.

Ok. Still, I'm confused by the need for setuid and going C(++). For the
record, Python's subprocess module would do the same job:

https://docs.python.org/3/library/subprocess.html

> C has no simple equivalent that I
> am aware of,

I guess that'd be a combo of fork() + exec() + IPC to get the results
(return code, stdout/err) back to the parent. :) Or, preferably, using
some existing library which makes this easier.

> so I cheated by adding the overkill input sanitation
> (bearing in mind that in normal use the input parameters will in 99.9%
> of cases be "/live/persistence/TailsData_unlocked" and "/dev/sd[a-z]").

Understood.

> 1. is it worth spending any more time fixing the dodgy C++, or is it
> just throwing good effort after bad?

It's not worth the effort. Sorry, but let's drop the C/C++.

> 2. is the general structure of userspace GUI + setuid helper still the
> way to go?
>
> 3. Since tails-installer-invoker and tails-installer remain distinct
> programs (and tails-installer closely tracks liveusb-creator), is it
> necessary/desirable to merge persistence cloning into either of them, or
> should/could it remain a separate (linked) executable? In other words,
> do I really need to learn Python? ;-)

I mainly threw myself in the discussion to avert us from adding any
C/C++ code. I leave it to sajolida and u to decide on how the backup
tool should integrate into the installer (or if it should be separate),
and for u and intrigeri to clarify the privileges separation situation
in the installer (I think it's run as a normal users, and udisks is used
to partition, format, luksOpen etc without any risky setuid business).
All this will influence the answers to these questions.

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] Electrum wallet does not connect

[anonym]

Meta: note that this mailing list is for discussions about Tails
development, not support; for that we have tails-supp...@boum.org
(Cc:ed). For any further posts on this topic, please drop tails-dev@ and
continue on tails-support@.

Павел О:
> I want to ask if I can do something with Electrum. It usually doesn't want
> to connect. I tried for about 10 times and only once there was a success,
> but it took a lot of time for it to connect, it makes impossible to use it.
> All settings are default, I use 1.8 version of Tails, persistence is on.

This should be fixed in Tails 1.8.1 (in general, when experiencing
issues, please try the latest version before reporting issues). Make
sure to read the extra steps needed to fix your Electrum persistent
configuration:

https://tails.boum.org/news/version_1.8.1/index.en.html#index4h1

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] [Secure Desktops] MAC changer "blend into the crowd" by only using common manufacturer MAC (OUI part) addresses broken by design?

[anonym]

Patrick Schleizer:
> Tails' current implementation...
> 
> only spoof the NIC part: yes [1]
> OUI part unchanged: yes [2]
> 
> quu9ohch [1]:
>> [...] It is not possible to "blend into the crowd" with a
> "typical-looking" mac address when so many users allow themselves to be
> uniquely fingerprinted and tracked.

I'm not sure what this means. Since all "real" MAC addresses around you
can be tracked down, your spoofed one will stand out, arising suspicion?
I'm not sure how that is distinguishable from a new device coming online
for the first time, or similar, which is nothing out of the ordinary.

> The tradeoff of using a weird (or
> never manufactured) mac address is like the tradeoff of using tor. It
> follows from the pigeon hole principle that one cannot hide the fact
> that they are trying to hide (it is up to other users to hide you), but
> the best one can do is become statistically exchangeable with the
> largest possible set of anonymity participants via randomness. [...] [2]

I don't agree with any of this, at least vs the goals stated for MAC
spoofing in Tails. If we spoof with a MAC address that uses an OUI
somewhat common to the area, we have successfully blended into the crowd
and successfully achieved the relevant user goals: AvoidTracking;
AvoidIdTails and AvoidIdMacSpoof. That is clearly superior to blending
in with other anonymity participants in the area, which in the worst
case fails all of the goals; if there are no anonymity participants in
the area, failing AvoidIdTails or AvoidIdMacSpoof implies failing
AvoidTracking too since you'll be the only one doing it.

> An argument of mine... Quote Tails MAC changer design.
> 
>> [MAC OUI] lists do not take into account that some devices are pretty
> much only used in some geographical areas
> 
> I conclude, for someone who traveled far or bought an uncommon notebook,
> by not changing the OUI part, one could stand out more. Because always
> that uncommon OUI shows up that is rare in that geographical area. And
> worse so, the uncommon OUI with an always changed NIC. This would lead
> to AdvGoalIdMacSpoof, AdvGoalIdTails and AdvGoalTracking. That
> particular user with that uncommon OUI would be better off with a fully
> random (OUI part and NIC part) MAC address. It would lead to
> AdvGoalIdMacSpoof, but not to AdvGoalTracking. In my opinion, the better
> compromise.

I'm just gonna rehash the argument I just made above: a fully random MAC
address also implies the adversary achieving AdvGoalTracking if you are
the only Tails (etc) user in the area, which isn't a very inconceivable
situation.

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] [Secure Desktops] Tails: Protect against fingerprinting via active Wi-Fi networks probing implemented?

[anonym]

Patrick Schleizer:
> Active probe fingerprinting
> https://tails.boum.org/contribute/design/MAC_address/#index6h1
> 
> says, No - "No protection against this is implemented yet".

This is still the case.

> but https://labs.riseup.net/code/issues/6453 says "yes", 100 % done.

That's just Redmine's way to show that all subtickets are closed. :) As
you can see, the ticket is still open.

> What happened to
> https://mailman.boum.org/pipermail/tails-dev/2014-January/004690.html

Nothing. :/

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] [Secure Desktops] Avoiding real MAC address in Tails macchanger being harmful?

[anonym]

[Sorry for the delay :S]

Patrick Schleizer:
> Tails does verify, that randomly chosen MAC does not equal the real MAC
> by chance.
> 
> From tails-spoof-mac [1] (code: [A])
> 
>> # There is a 1/2^24 chance macchanger will randomly pick the real MAC
>> # address. We try to making it really unlikely repeating it up to
>> # three times. Theoretically speaking this leaks information about the
>> # real MAC address at each occasion but actually leaking the real MAC
>> # address will be more serious in practice.
> 
> quu9ohch [2] [3]:
>> P.S. Avoiding the "real" mac address is a bogus approach as well. If
> all users were to avoid their real mac addresses all the time then, with
> enough data, a local passive adversary could identify each user by
> estimating which mac address they never pick. [3]

Note that "enough data" here is a ridiculous amount of samples,
something in the order of millions of randomly picked MAC addresses (so,
even more than than amount of Tails boots, since the same one can be
picked). And how can the adversary see that all those belong to the same
device? (Chipset/driver fingerprinting, perhaps)

In short: I think it's reasonable to assume that an adversary will never
be able to collect enough samples for something it reliably can assume
is the same device for this leak to ever be of any use.

> marmarek:
>> If you _randomly_ hit your own MAC address, I think this isn't a
> problem at all. Actually changing that behavior may introduce some bias
> in that randomness. But if you're talking about some error which results
> in not changing the MAC (even if randomly chosen one was different than
> original), that's the problem.

Assuming AdvCapRecords (the adversary has a MAC Address => Real person
mapping), why would you ever want to end up on the adversaries radar?
What if the adversary doesn't assume you are using MAC spoofing?

To change my mind about any of this, I want some actual conceivable
scenarios with hard numbers and statistics to back them up, and that
they reasonably could happen within a device's usage lifetime, and not
hundreds of years of constant rebooting or something ridiculous like that.

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] [Secure Desktops] Tails' MAC 'leak prevention' question

[anonym]

[Sorry for the delay :S]

Patrick Schleizer:
> I understand Tails' MAC 'leak prevention' [1] [2] as this... Without
> 'leak prevention', things would happen like this:
> 
> a)
> 
> 1) system boots
> 2) kernel module loaded
> 3) MAC leaked
> 4) macchanger started
> 5) MAC changed
> 6) NetworkManager started
> 
> So the MAC leaked even before NetworkManager, before the the interface
> has been uped, before macchanger may have had a chance to change it.
> 
> Therefore Tails does as this:
> 
> b)
> 
> 1) system boots with kernel modules blacklisted
> 2) user makes decision [to spoof MAC]
> 3) MAC changed
> 4) kernel module loaded
> 5) NetworkManger started
> 
> But if there hypothesis was true... They still have a small window
> between tails-unblock-network, service network-manager start and macchanger.
> 
> Can the MAC be changed without having the kernel module loaded?
> - if yes -> great
> - if no -> then there would be room for MAC leaks like in a), right?

None of your scenarios really reflect what happens in Tails
implementation, at least. The key thing that prevents this "window" is
that we have an udev hook triggering on added network devices that will
execute the MAC spoofing script. udev won't advertise the device as
finished until all such hooks have exited (or timed out) so
NetworkManager won't touch the device. It is true, though, that the
device is usable, so something else could use the device and leak the
MAC address.

I suppose our design docs are not clear on this point.

> Quote Tails Design
> 
>> It is conceivable that NICs may send packets before the user has made
> a decision about whether to use MAC spoofing or not. In fact, someone on
> tails-dev@ alluded [3] to this being possible for wireless NICs although
> without any references (this may refer to so called "active probing";
> see section below). If this is the case it at the very least implies
> that we must enforce the MAC spoofing setting as early as possible. [...]
> 
> That does not sound very certain.
> 
> Just because of being alluded [3] you done quite some effort to not load
> the kernel modules?

Indeed, that paragraph should be rewritten some how or just dropped. We
know that Intel AMT/vPro can do stuff like this, and that we cannot do
anything about (which we do mention), and I have no idea why we mix
"active probing" there which seems completely unrelated.

The point of that section is just to arrive at the still sound
conclusion that the decision has to be made first.

> Wouldn't it be possible, and simpler, to block all networking with
> iptables to prevent early MAC leaks so kernel module blacklisting could
> be avoided?

I'm not sure it would be simpler. The module blocking approach
definitely makes some other parts of the implementation simpler and
decoupled so the MAC spoofing system more or less can be plugged into
the existing Tails without modifying other parts. For instance, we have
a lot of NetworkManager hooks that run when a device is up:ed. What
should we do during the time they are blocked? Of course, we could make
the very first hook wait until some signal that means that device is
ready. The point is that it becomes harder to reason when we add yet
another state a network device can be in.

Also, it feels safer to rely on the lack of code (i.e. no module loaded)
than more code (iptables (via ferm) and netfilter blocking absolutely
everything for some device, even low-level wireless active probing etc).
Also note that we want to support hotplugging network devices safely
(w.r.t. MAC spoofing) after boot and logging in, so the firewall rules
would have to be updated dynamically upon when a device is added (and
removed!), which seems complex and makes me feel a bit uneasy.

That said, this is certainly open for discussion.

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] Post-1.8 Readmine follow-ups

[anonym]

Hi,

There are more than 40 tickets still on the 1.8 Target version. Now that
Tails 1.8 has been released, please postpone tickets as you see fit.

Among the 1.8 tickets there are 5 unassigned tickets:


https://labs.riseup.net/code/projects/tails/issues?utf8=%E2%9C%93&set_filter=1&f%5B%5D=fixed_version_id&op%5Bfixed_version_id%5D=%3D&v%5Bfixed_version_id%5D%5B%5D=245&f%5B%5D=status_id&op%5Bstatus_id%5D=o&f%5B%5D=assigned_to_id&op%5Bassigned_to_id%5D=%21*&f%5B%5D=&c%5B%5D=priority&c%5B%5D=subject&c%5B%5D=category&c%5B%5D=cf_15&c%5B%5D=assigned_to&c%5B%5D=cf_9&group_by=status

For the next release, Tails 2.0, there are 10 unassigned tickets:


https://labs.riseup.net/code/projects/tails/issues?utf8=%E2%9C%93&set_filter=1&f%5B%5D=fixed_version_id&op%5Bfixed_version_id%5D=%3D&v%5Bfixed_version_id%5D%5B%5D=214&f%5B%5D=assigned_to_id&op%5Bassigned_to_id%5D=%21*&f%5B%5D=status_id&op%5Bstatus_id%5D=o&f%5B%5D=&c%5B%5D=priority&c%5B%5D=subject&c%5B%5D=category&c%5B%5D=cf_15&c%5B%5D=assigned_to&c%5B%5D=cf_9&group_by=status

Do we have any takers for these?

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] Tails as a Qubes VM

[anonym]

sp...@tutanota.com:
> I was trying to get Tails running on Qubes. I used the most recent qubes live 
> cd and afterwards added tails (1.7) as a HVM virtual machine. It booted 
> without problems but when the gui wants to start only a blinking icon is 
> visible and the rest of the screen is black. I'm not sure if this is a tails 
> or qubes issue. A debian jessie xfce live cd worked without problems as well 
> as kali linux. Knoppix didn't go far beyond the boot screen and a ghost bsd 
> iso booted into the gui, though the mouse did not work. Any ideas what could 
> be the problem with tails or what one could do to troubleshoot the problem? 
> Is there some possibility to not start the gui and just boot to the terminal?

I would suggest that you try with a Jessie-based Tails nightly build:


http://nightly.tails.boum.org/build_Tails_ISO_feature-jessie/builds/lastSuccessfulBuild/archive/build-artifacts/

Obviously, since this is not a stable release, do so only for testing
purposes. Please report your results back here!

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] Prioritize onion servers in Electrum

[anonym]

s7r:
> prefnet=tor

Instead of introducing this new pref, would it make sense to add a new
proxy type, 'tor' or whatever (presented as "Tor Proxy"), that implies
socks5 and the behaviour that 'prefnet=tor' otherwise would do? It could
even suggest 'localhost:9050' by default. None of this would matter for
Tails, but it seems like a more helpful UI outside of it.

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] Release versioning

[anonym]

intrigeri:
> Hi,
> 
> intrigeri wrote (18 Aug 2015 11:09:35 GMT) :
>> Please do whatever's needed for the change you proposed in our various
>> repos + Redmine etc., after leaving some time to others to comment
>> further. Perhaps we should make the final decision at the
>> September meeting.
> 
> I can't find a follow-up to this discussion.
> 
> To sum up the options we have:
> 
> A. Keep "odd for major release / even for minor ones" in general but
>call the first Tails/Jessie release 2.0. Call the next one 2.1
>because:
>- it'll likely introduce tons of changes to fix bugs in 2.0 anyway
>- 2.0 will be feature-frozen in 2 weeks, so IMO it makes sense to
>  have a release with new features allowed in March

Just wanted to say that I agree to those two points...

> B. Switch to "even for major releases / odd for minor ones", call the
>first Tails/Jessie release 2.0, and then
>1. find out how to deal with no release with new features allowed
>   between November and April; exceptionally allow new features in
>   2.1?

... but that's easily achievable by skipping 2.1, i.e. we plan 2.2 six
weeks after 2.0 (in March). Both schemes suffer from the potential need
of release skipping like this, as we already have noticed.

>2. adjust whatever is needed for this change

I could do this, if we decide to switch.

> As said already I can live with both, but I'd like to see a decision
> made on this soon, and won't do the work required by B.

I don't care much either. It does make sense that e.g. 2.0 should be a
major release, and that is an even number, so that scheme has that
additional consistency in its favour..

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] Release schedule for Tails 1.8

[anonym]

Hi,

I'll be the release manager for Tails 1.8, which is a minor/stable
release scheduled for 2015-12-15. This is the last *planned* Tails
release based on Debian Wheezy, so except potential emergency releases,
Tails will be based on Debian Jessie after 1.8. :)

The list of tickets targeting Tails 1.8 can be found here:

https://labs.riseup.net/code/projects/tails/issues?query_id=189

172 ticket! Yikes! And that doesn't include 18 tickets I currently see
in the view for Tails 1.7:

https://labs.riseup.net/code/projects/tails/issues?query_id=188

Please postpone tickets ASAP! Also, please sit down and try to make your
plans for 1.8 realistic. Let's not have the current Target Release
degenerate to "the list of things I should prioritize". And yes, I know
I am a hypocrite with my 51 tickets targeting 1.8. :) I'll have such a
sit down myself, soon.

Here's the preliminary release schedule for Tails 1.8:

* 2015-12-14:
  - All branches targeting Tails 1.8 *must* be merged into the `stable`
branch by noon, CET.
  - The upcoming Tor Browser is hopefully out so we can import it.
  - Build and upload Tails 1.8 ISO image and IUKs.
  - Hopefully start testing Tails 1.8.

* 2015-12-15:
  - Finish testing Tails 1.8 by the afternoon, CET.
  - Release Tails 1.8 during late CET.

Testers, please let me know:

* if you are available on 2015-12-14, late CET

* if you are available on 2015-12-15, morning to afternoon, CET.

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] Updated signing key - lack of notice on d/l page for 1.7

[anonym]

kytv:
> On Sat, Nov 07, 2015 at 09:23:40AM +, Anonymous wrote:
>> on your TAILS download page it mentions:
>>
>> "Tails transitioned to a new signing key in Tails 1.3.1."
>>
>> But it fails to mention the new updated signing key for 1.7.
>> I verified the 1.7 ISO with an older version of TAILS and
>> followed this by importing the 1.7 signing key and it too
>> verified the 1.7 ISO.
>>
>> But, you should post somewhere about the new 1.7 signing key
>> and recommend the download of it just in case for some
>> users. TIA
> 
> I believe you are mistaken. If there was a new signing key it would definitely
> have been mentioned. There isn't a new signing key for 1.7.

Indeed. What the "Update the Tails signing key" entry in the changelog
refers to is simply that we bumped the expiry date of two subkeys.

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] Tor Browser 5.0.4 release -- build5?

[anonym]

Georg Koppen:
> Hi,
> 
> we are pondering rebundling for the 5.0.4 release once more to include
> the fix for https://bugs.torproject.org/17473.

Thanks for the heads up!

> As far as I can see Tails is not including meek yet, correct? Thus, your
> release plans should not be affected by a tentative build5 (meaning you
> could just stick with build4 as build5 would only change the meek-amazon
> fingerprint). Am I something missing?

You are correct. If that is exactly the only change, then I believe
there's no problem with us staying with -build4 since we will ship the
same files thanks to reproducible builds.

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] Releasing automated tests

[anonym]

sajolida:
> anonym:
>> sajolida:
>>> anonym:
>>>> [Moving discussion to tails-dev@]
>>>
>>> Meta: I really don't want to understand everything that's in this email
>>> but I felt you would want me to answer this one. But if you think that
>>> you can have this discussion without me I would be super happy as well.
>>
>> I believe you have answered the question that was (mostly) directed to
>> you, but you also added an interesting idea, so... :)
>>
>>>> Given the trimming that has happened, some context may have been lost.
>>>> The discussion is about that we now, in our Jenkins setup, automatically
>>>> test images built from doc/ and web/ branches, which wastes a lot of
>>>> time on our isotesters.
>>>>
>>>>> From: intrigeri 
>>>>> Date: Tue, 20 Oct 2015 13:08:31 +0200
>>>>>
>>>>>> From: bertagaz 
>>>>>> Date: Mon, 19 Oct 2015 12:29:26 +0200
>>>>>
>>>>>>> From: anonym 
>>>>>>
>>>>>>> Still, once we release 1.7, then all doc/ and web/ branches will become
>>>>>>> tested. I suspect we will need a permanent fix for only building (not
>>>>>>> testing) these branches -- it's useless to test them 99.9% of the time,
>>>>>>> and they will block (for ~5 hours) test runs from relevant branches that
>>>>>>> got something pushed to them right after them.
>>>>>
>>>>>> That's something we didn't decide when during the design round. Sounds
>>>>>> doable, but I wonder if there are still some valid points to still test
>>>>>> that branches.
>>>>
>>>> True, but there's an overwhelming amount of them, and their
>>>> modifications are limited to something that is completely isolated from
>>>> most of Tails, the OS, meaning that a huge part of each test run on them
>>>> is just a (possibly out-dated) re-run of master/devel/stable depending
>>>> on which branch it was based on. That is unlike feature/, bugfix/ and
>>>> test/ branches, that need a full run in general. Perhaps you can see
>>>> where I'm going:
>>>>
>>>> As an optimization, we could introduce @web and @doc tags, and run the
>>>> test suite with `--tag @web` or `--tag @doc` for doc/ and web/ branches,
>>>> respectively. Then we could even have automated tests of @web changes
>>>> before deploying them by browsing the local wiki in Tails. :)
>>>>
>>>> Note that I may not have the correct understanding of the doc/ vs web/
>>>> distinction, so I'd like a clarification just in case so we don't design
>>>> something stupid. I suspect that since we don't have any automated tests
>>>> for the *website* (as opposed to the docs) we only care about doc/ and
>>>> only need to test web/ if we want to start testing the website.
>>>>
>>>>> FTR I dislike the idea of blacklisting such branches based on their
>>>>> name. I'm not going to debate it here [...]
>>>
>>> The prefixes doc/ and web/ are used loosely to differentiate work on the
>>> "documentation" (/doc /support) and the "website" in general (structure,
>>> stuff not in /doc, etc.) but the difference is not strict.
>>
>> ACK, as I expected, than.
>>
>>> I also don't think they should be tested. Maybe you could exclude them
>>> from testing by their diff to their base branch. If all the diff is
>>> under wiki/src then don't test that branch.
>>
>> I guess you mean the diff against the base branch (but base branches
>> themselves would *always* build, of course). Hm. Technically we'd have
>> to do something slightly different since a `git diff` would show changes
>> in the base branch since the point they diverged. We'd have to look at
>> all files touches in `git log $base_branch..` or something like that.
>> It's an interesting approach, which I think I like.
> 
> Did you took into account the '...' (THREE DOTS) operator which is
> slightly different than '..' and I *think* might be helpful here to diff
> only the changes that happened on this branch. I'm not sure what it does
> exactly (couldn't understand the man page).

Neat! That's is a very useful Git feature. Thanks for letting me know
about it!

Then I think we can combine the "..." operator with another fancy Git
feature I recently found, namely Git pathspec "magic signatures". So we
could do:

   BASE_BRANCH_DIFF="$(git diff $base_branch...$commit  -- \
   '*' \
   ':!/wiki' \
   ':!/ikiwiki.setup' \
   ':!/ikiwiki-cgi.setup')"
   if [ -z "${BASE_BRANCH_DIFF}" ]; then
   CUCUMBER_ARGS="${CUCUMBER_ARGS} --tag @doc"
   fi

where $commit is the commit we test, before merging the base branch
locally. Interesting!

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] Windows 10 theme for Tails/Jessie

[anonym]

Christian Medel:
> Wow! what an extension, it looks perfect!
> 
> I'll have a try at it right now.

Excellent!

> By the way I had a try at applying the theme in the latest TAILS ISO and
> this is the result :
> 
> Preview of Windows 10 on TAILS latest testing version
> http://imgur.com/a/22nzi
> 
> *note : GNOME-SHELL theme didn't change nothing*

Yeah, I saw this in your other email. Looks like a step in the right
direction, but without some sort of "task-bar" extension, like the one
above, it will not be very convincing.

I'm eagerly anticipating what you'll manage to cook up with that
extension! :)

> Also, Murrine engine is needed for the gtk 2 apps to have a decent look,
> otherwise they look like win95

Right. Like I said before, I think it's most efficient if you focus on
making your theme work on Debian Jessie, and then some Tails developer
make it work in Tails. What do you think?

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] Windows 10 theme for Tails/Jessie

[anonym]

Christian Medel:
> Hi,
> 
> so I tried the Terminal stuff, no result. Maybe I'll have to rewrite some
> code for it to work with SHELL.
> 
> About the taskbar I meant a Window-list applet but with just the app icon,
> no text.

What about this GNOME extension:

https://extensions.gnome.org/extension/898/mmod-panel/

It reportedly works for Debian Jessie's version of GNOME, i.e. 3.14, and
from my 1 minute investigation (mostly looking at the screenshot), it
looks perfect for our needs.

If you can make it work with your theme, we should be able to package it
for Debian so it can be included in Tails.

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] Releasing automated tests

[anonym]

sajolida:
> anonym:
>> [Moving discussion to tails-dev@]
> 
> Meta: I really don't want to understand everything that's in this email
> but I felt you would want me to answer this one. But if you think that
> you can have this discussion without me I would be super happy as well.

I believe you have answered the question that was (mostly) directed to
you, but you also added an interesting idea, so... :)

>> Given the trimming that has happened, some context may have been lost.
>> The discussion is about that we now, in our Jenkins setup, automatically
>> test images built from doc/ and web/ branches, which wastes a lot of
>> time on our isotesters.
>>
>>> From: intrigeri 
>>> Date: Tue, 20 Oct 2015 13:08:31 +0200
>>>
>>>> From: bertagaz 
>>>> Date: Mon, 19 Oct 2015 12:29:26 +0200
>>>
>>>>> From: anonym 
>>>>
>>>>> Still, once we release 1.7, then all doc/ and web/ branches will become
>>>>> tested. I suspect we will need a permanent fix for only building (not
>>>>> testing) these branches -- it's useless to test them 99.9% of the time,
>>>>> and they will block (for ~5 hours) test runs from relevant branches that
>>>>> got something pushed to them right after them.
>>>
>>>> That's something we didn't decide when during the design round. Sounds
>>>> doable, but I wonder if there are still some valid points to still test
>>>> that branches.
>>
>> True, but there's an overwhelming amount of them, and their
>> modifications are limited to something that is completely isolated from
>> most of Tails, the OS, meaning that a huge part of each test run on them
>> is just a (possibly out-dated) re-run of master/devel/stable depending
>> on which branch it was based on. That is unlike feature/, bugfix/ and
>> test/ branches, that need a full run in general. Perhaps you can see
>> where I'm going:
>>
>> As an optimization, we could introduce @web and @doc tags, and run the
>> test suite with `--tag @web` or `--tag @doc` for doc/ and web/ branches,
>> respectively. Then we could even have automated tests of @web changes
>> before deploying them by browsing the local wiki in Tails. :)
>>
>> Note that I may not have the correct understanding of the doc/ vs web/
>> distinction, so I'd like a clarification just in case so we don't design
>> something stupid. I suspect that since we don't have any automated tests
>> for the *website* (as opposed to the docs) we only care about doc/ and
>> only need to test web/ if we want to start testing the website.
>>
>>> FTR I dislike the idea of blacklisting such branches based on their
>>> name. I'm not going to debate it here [...]
> 
> The prefixes doc/ and web/ are used loosely to differentiate work on the
> "documentation" (/doc /support) and the "website" in general (structure,
> stuff not in /doc, etc.) but the difference is not strict.

ACK, as I expected, than.

> I also don't think they should be tested. Maybe you could exclude them
> from testing by their diff to their base branch. If all the diff is
> under wiki/src then don't test that branch.

I guess you mean the diff against the base branch (but base branches
themselves would *always* build, of course). Hm. Technically we'd have
to do something slightly different since a `git diff` would show changes
in the base branch since the point they diverged. We'd have to look at
all files touches in `git log $base_branch..` or something like that.
It's an interesting approach, which I think I like.

>>> [...] making sure that the workaround is not worst than the problem
>>> it fixes
>>
>> The only effect should be that we won't get automated tests of the few
>> scenarios that looks at the wiki shipped inside Tails. [...]
> 
> Agreed. If I understand correctly, these scenarios have a *dependency*
> on what is on the local copy of the website, but they are actually
> testing the Tails software (the "Report an Error" launcher for example).

Correct so far.

> They are not testing the content of the local copy of the website itself.

Actually, they *are* testing the content of the local copy, e.g. that
the support page is properly localized. Hence there could be a subset of
automated tests that would make sense to run for doc/ and web/ branches.

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] Windows 10 theme for Tails/Jessie

[anonym]

Christian Medel:
> Hi,
> 
> I have a question for you. Will you be strictly using GNOME-SHELL or
> will the next TAILS include the Cinnamon panel? If that's the case, that
> could fix the GNOME-Panel extension and bring the DE look even more than
> Windows 10.

If it is packaged in Debian and can be mixed into GNOME Shell, why not?
So is it? Will it pull in *all* of Cinnamon?

> Ex. http://gnome-look.org/CONTENT/content-pre2/171327-2.png

Is this with or without the Cinnamon panel? It would be helpful to have
screenshots to compare with. Like I've said, I'm not really familiar
with Windows 10's exact look.

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] Releasing automated tests

[anonym]

[Moving discussion to tails-dev@]

Given the trimming that has happened, some context may have been lost.
The discussion is about that we now, in our Jenkins setup, automatically
test images built from doc/ and web/ branches, which wastes a lot of
time on our isotesters.

> From: intrigeri 
> Date: Tue, 20 Oct 2015 13:08:31 +0200
> 
>> From: bertagaz 
>> Date: Mon, 19 Oct 2015 12:29:26 +0200
> 
>>> From: anonym 
>> 
>>> Still, once we release 1.7, then all doc/ and web/ branches will become
>>> tested. I suspect we will need a permanent fix for only building (not
>>> testing) these branches -- it's useless to test them 99.9% of the time,
>>> and they will block (for ~5 hours) test runs from relevant branches that
>>> got something pushed to them right after them.
> 
>> That's something we didn't decide when during the design round. Sounds
>> doable, but I wonder if there are still some valid points to still test
>> that branches.

True, but there's an overwhelming amount of them, and their
modifications are limited to something that is completely isolated from
most of Tails, the OS, meaning that a huge part of each test run on them
is just a (possibly out-dated) re-run of master/devel/stable depending
on which branch it was based on. That is unlike feature/, bugfix/ and
test/ branches, that need a full run in general. Perhaps you can see
where I'm going:

As an optimization, we could introduce @web and @doc tags, and run the
test suite with `--tag @web` or `--tag @doc` for doc/ and web/ branches,
respectively. Then we could even have automated tests of @web changes
before deploying them by browsing the local wiki in Tails. :)

Note that I may not have the correct understanding of the doc/ vs web/
distinction, so I'd like a clarification just in case so we don't design
something stupid. I suspect that since we don't have any automated tests
for the *website* (as opposed to the docs) we only care about doc/ and
only need to test web/ if we want to start testing the website.

> FTR I dislike the idea of blacklisting such branches based on their
> name. I'm not going to debate it here [...]

Please do it here, then! :) I guess it's related to that you want at
least doc/ branches to be tested, since our automated test suite
actually depend on the documentation (see two quotes below for more on
this).

I wonder if we could have a configuration filem like
config/jenkins_testing, which has settings controlling how the automated
test suite is invoked on Jenkins. I imagine something like this:

ENABLE = {true,false}

Whether to run the test suite at all. Hence, when merging another base
branch into master as part of the release process, we just make sure to
set this to `false` and we're done. When merging master into a base
branch, it must be set to `true`. So it's similar to config/base_branch,
except that it includes master as a special case. Is this problematic?
Won't merge conflicts save us?


If we prefer it, we could implement my tagging idea with this:

CUCUMBER_ARGUMENTS = 

This makes Jenkins invoke run_test_suite with extra CUCUMBER_ARGUMENTS.
And it could be used for the @web/@doc idea above if we have it set to
`--tag @doc` or whatever in master. We could even test master then, in
the same way. We just have to update the release process in the same way
as for the ENABLE setting, but for CUCUMBER_ARGUMENTS.

Since this affects how Jenkins will invoke a script, there's a security
concern vs the shell that has to be considered. Also arbitrary paths can
be given. Hence we probably may want to have this option *instead*:

RUN_WITH_TAGS = 

So if it's set to ["tag1", "~tag2,tag3"] it would be translated to these
distinct arguments:

['--tag', 'tag1', '--tag', '~tag2,tag3']

in the usual safe (i.e. shell-free) list syntax used for exec in many
programming languages (python, ruby, perl...). This would also improve
the situation for @fragile, and also be subject to the same release
process update as ENABLE above.



Note that ENABLE gives an alternative implementation for the problem
that #10389 wants to solve, i.e. "don't run tests for WIP branches". I
think I prefer this approach, so we avoid excessive branch re-naming.

Also note that with the flexibility from
CUCUMBER_ARGUMENTS/CUCUMBER_TAGS we can remove `--tag ~@fragile` from
the Jenkins wrapper script (#10288) by setting it in the config instead.

Using CUCUMBER_ARGUMENTS/CUCUMBER_TAGS the true power users could even
do "focus" testing of specific features/scenarios via a temporary tag
and then making Jenkins only test that tag -- now the test suite will
not waste time on other scenarios. FWIW. I don't think this will play
nicely with our future ideas about Jenki

Re: [Tails-dev] Desktop Camouflage

[anonym]

intrigeri:
> Spencer wrote (21 Oct 2015 07:21:26 GMT) :
>> I am checking in on the status of the camouflage feature for Jessie; is 
>> anybody
>> porting it?
> 
> No, nobody has started any porting work.

Maybe we are in luck that Windows 10 was released so recently? Generally
such releases seems to motivate themers to make emulation themes, and lo
and behold:

http://gnome-look.org/content/show.php/Windows+10+Theme?content=171327

It is updated very frequently, and the theme seems to match the
screenshots I've seen of Windows 10 quite nicely (better than our
current Windows 8 theme vs the actual thing, imho). This is pretty
promising. I've updated #8064, asking alan for his opinion.

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] Tails fails to run inside Qubes OS

[anonym]

Patrick Schleizer:
> intrigeri:
>> If you really tried Tails 1.6, then I suggest you retry with
>> a Jessie-based experimental build:
>>
>> http://nightly.tails.boum.org/build_Tails_ISO_feature-jessie/lastSuccessful/archive/
> 
> Tried.
> 
> - It's not affected by the X issue. Boots up without `vga=`.
> - Mouse does not work in Tails greeter (very first screen) (tab key works)
> - Probably works, but only with keyboard navigation. Which I don't know
> how to use, since keys like alt + tab are used by the host operating system.

You should be able to login with only the beyboard like this:

TAB + TAB + ENTER

But I recommend:

  SPACE + TAB + TAB + ENTER

which brings you to the "More options" screen, and then:

   + ENTER +  + ENTER

Then you can try to debug the mouse issue with the help of the admin
password, e.g. the systemd journal, /var/log/Xorg.0.log etc.

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] Release schedule for Tails 1.7

[anonym]

Hi,

I'll be the release manager for Tails 1.7, which is a major release
scheduled on 2015-11-03. For the list of tickets targeting Tails 1.7,
have a look at:

https://labs.riseup.net/code/projects/tails/issues?query_id=188

As you can see we have a lot left to do this month so I feel forced to
push the freeze and release candidate to a somewhat later date than I
would like. This means that we barely will have a week for the
translation window, and six days for the release candidate testing.
Developers and doc writers, please try to notify the translators as soon
as your work is merged into devel so the translators can start their
work early!

Also, I have some unfortunate strict AFK/offline time from 2015-10-23 to
2015-10-25 (inclusive!) and therefore I'm extra willing to make freeze
exceptions on 2015-10-26 and do some late reviewing, possibly pushing
the image building into the late night. However, I'm gonna do my best at
reviewing stuff way early during this cycle to avoid my absence becoming
a problem.

BTW, I think we should make an extra CfT on tails-testers@ once Icedove
has been merged (if done early enough vs the freeze) and ask them to
test the Claws -> Icedove migration instructions, and Icedove in general
from some nightly build. That is the biggest user-facing change in 1.7,
and possible the thing that will suffer the most from the short RC period.

Here's the preliminary release schedule:

* 2015-10-26:
   - Freeze Tails 1.7: All feature branches targeting Tails 1.7 should
 be merged into the `devel` branch by noon, CET. I'm open to make
 exceptions if you can be online and responsive during that
 afternoon.
   - Build and upload Tails 1.7~rc1.
   - Start testing Tails 1.7~rc1 during late CET if building the image
 went smoothly.

* 2015-10-27:
   - Finish testing Tails 1.7~rc1 by the afternoon, CET.
   - Release Tails 1.7~rc1.

* 2015-11-02:
   - All new branches targeting Tails 1.7 must be merged into the
`testing` branch by noon CET. I'm open to make exceptions if you
 can be online and responsive during that afternoon.
   - Tor Browser 4.5.x, based on Firefox 38esr, is hopefully out so
 we can import it.
   - Build and upload Tails 1.7 ISO image and IUKs.
   - Start testing Tails 1.7 during late CET if building the image
 went smoothly.

* 2015-11-03:
   - Finish testing Tails 1.7 by the afternoon, CET.
   - Release Tails 1.7 during late CET, earliest when Mozilla
 publishes their MFSAs.

Testers, please let me know:

* if you are available on 2015-10-26, evening, CET.

* if you are available on 2015-10-27, morning to afternoon, CET.

* if you are available on 2015-11-02, evening, CET.

* if you are available on 2015-11-03, morning to afternoon, CET.

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 with openqa?

[anonym]

sajolida:
>>> Not as if we were taking much benefit from Gherkin for
>>> {intra,inter}-team communication yet, but I like it that we're able to;
>>> and I intend to try to use Gherkin more in the future when discussing
>>> changes with UX folks.
>>
>> This sounds interesting.  I have read some negative things about this
>> but the argument made was that the language did exactly as it
>> advertised; making humans still have to talk to other humans, as it
>> didn't magically resolve their socially retarded nature :)
>>
>> I am open to poking around with this sooner than later, even in test
>> communication runs, if not with live designations decisions.
>>
>> I have copied the UX list in case people want to nerd out over there, too.
> 
> Yeap, I'd like to know more about that intrigeri meant but I guess that
> will be done in due time.

I recommend you tails-ux@ people to look at the features/*.feature files
in Tails' Git. Ideally anyone with domain knowledge about *using* Tails
following the steps in those files should be able to reproduce more or
less exactly what our automated test suite does when following them. No
further explanation should be needed, and in particular one shouldn't
have to look at the code == step definitions.

That said, in many cases this is not true in its current state due to
technical limitations/shortcuts (but there will be quite a few nice
improvements soon, with #6094 being solved). But it would be interesting
to get some help with #10329 from "outsiders" like you tails-ux@ people.
I suppose we, as Test Suite Developers, often think a bit too much about
the implementation, resulting in scenarios where steps are split
according to that, contrary to how a user might think. That may actually
be a good thing (to reduce the code complexity for the step definitions)
but it would nonetheless be interesting to see how they would compare.
Perhaps there is a better balance.

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 with openqa?

[anonym]

On 09/15/2015 11:03 AM, intrigeri wrote:
> Alan wrote (23 Aug 2015 13:28:41 GMT) :
>> but I encourage the people working on the test suite to have a look
>> at OpenQA and consider wether it would make sense to use it. It has
>> a nice web interface to update screenshots,

Sorry for not responding earlier!

I looked at OpenQA ~4 years ago, before we started our own thing, but it
seemed to me that it solved quite little of what we actually needed, at
least on the top; it didn't support fine-grained hardware configuration
(and not hotplugging at all), for instance. I felt weary of using
something that we'd have to extend endlessly to make it useful for us,
and while it would have been a potentially better longer-term solution,
I'm not sure we'd have started to benefit from it even now. (Also, perl!)

When bertagaz made the initial version of the cucumber + sikuli +
libvirt based thing we have now, I was blown away at how easily
extensible it was (despite me having no previous experience with Ruby).
I still think that is true, despite some painful surprises (JRuby). We
need so much flexibility to do all the things we want to do, so I'm not
sure if anything else than a solution of our own would work efficiently.

Or maybe I'm just having a case of NIH syndrome. :)

>> and we would share maintenance with other distros.

This I find really sad, however.

> I've had a look during DebConf, and indeed the web interface for
> developers is much better than what Jenkins will give us as-is.
> Perhaps at some point we'll need $something that extracts data from
> Jenkins and presents it to developers, and at that point it may be
> worth looking into OpenQA.

I'm unsure what the "$something that extracts data from Jenkins and
presents it to developers" part refers to. If it refers to Alan's "it
has a nice web interface to update screenshots", then I don't see the
benefit in it. It's quite rare that only pictures need updating when
stuff changes, and when they do, often more than one (used in the same
scenario) needs updating. Our --retry-find option will let us solve that
in (ideally) one babysitted run, while relying on automation + a web gui
to update images could result in some crazy long back and forth, or that
you must run a VM in parallel to take screenshots from. I'm not
convinced we'll have much use of that feature except for trivial cases
where only one image needs updating. And in trivial cases we can just
extract the new image from the test suite failure screenshot.

> Note that tests are written directly in Perl, with no overlay language
> like Gherkin. Not as if we were taking much benefit from Gherkin for
> {intra,inter}-team communication yet, but I like it that we're able to;
> and I intend to try to use Gherkin more in the future when discussing
> changes with UX folks.

I personally like the clarity of what is (well, *should be*) going on
that they provide to me, as a developer, even without the "easier
communication with non-developers" part.

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] [PATCH] Change syslinux menu entries from "Live" to "Boot"

[anonym]

On 09/11/2015 06:28 PM, spencer...@openmailbox.org wrote:
> Hi,
> 
>>>
>>> Chris Lamb wrote:
>>>
>>>> Tails
>>>> Tails (failsafe)
>>>
>>> We really need a verb here as I explain in my original patch. Whilst it
>>> does remove the jargon this isn't much better than "Live" IMHO.
>>
>> anonym:
>> I agree with both points.
>>
> 
> I don't.  User interaction *is* the verb you are looking for :)
>
> For example, in an application list on any OS there isn't a 'Start
> Application X' instruction on every icon, but yet we are all confident
> that when we select any of these icons that the respective application
> will start (boot, to be more or less technical).

Sure, context matters. But verbs do appear frequently in the context you
talk about, e.g. in the right-click context menus for files there's
frequently "Open" or even "Open with gedit Text Editor" as in Tails
currently for a .txt file. I guess you could argue that such menus has a
much larger context, so a verb is necessary there.

> Maybe we need an icon.

I doubt that would make anything clearer, especially when Tails doesn't
have any icon strongly associated with it.

> Also, when in the Boot Menu, 'Live' is ambiguous and doesn't communicate
> the intended task, while 'Tails' clearly does communicate the intended
> task which (with the included Boot Menu label text as a second vector
> confirming that this is a menu and you should select an option).  From
> my armchair, the action to take is hard-coded in the experience of
> knowing you are starting a computer, so all that is needed to move
> forward is an understanding of the options, not what action to take.

If this is an argument against "Start Tails" I do not get it. :/ "Live"
is, of course, a terrible option name. :)

>>> Did you have any specific objections to that? I'm not particularly
>>> bothered about which verb (eg. "Boot" vs "Start"), we just need one.
>>>
>>
>> Or what about verb + noun, i.e. "Start Tails" (and "Start Tails
>> (failsafe)")? Still succinct, to the point, no jargon => hard to cause
>> any confusion or ambiguity. The best of two worlds?
>>
> 
> This is good, but conflicts with actually starting Tails, as 'Start
> Tails' is already in use on the Greeter.

In the current Greeter we actually use "Login", which OTOH may be
suboptimal in itself. It may be an artifact from its GDM heritage.

> However, Bootstrapping is the function here, so:
> 
>  Boot Menu
> 
> Boot Tails
> Boot Tails (failsafe)

Sure, it makes sense for us, but "boot" is computer jargon. For people
unfamiliar with that word/concept, "start" makes more sense. And if you
don't know English at all, chances are still that you know the "start" word.

Perhaps you just used this example to derive your preferred choice, if
so, ignore this part-

> 'Boot' in the verb + noun structure becomes redundant.  However, as an
> alternative, removing 'Boot' from the menu label makes 'Menu' an
> unnecessary label.
> 
> Maybe we need a short descriptive sentence clarifying what action needs
> taken.  In this case we would still have:
> 
> Boot Menu
> 
> Tails
> Tails (failsafe)
> 
> But explain that when presented with options it is suggested that an
> option is selected and that by doing so they will be booting Tails. This
> sentence will need some TLC for sure if we include it.

While I see your point, I still believe that "Start Tails" is what users
will understand best without having to understand any context. Also,
we're discussing a menu that most users won't interact with (since it
auto-picks the default option after 5 seconds) and it really feels like
we're starting to split hairs here (OTOH, I'm not very used to UX
considerations, so perhaps it's just what it looks to me). As long as we
move from "Live" and do not pick anything with "boot" in it I'm in
favour, even though I prefer to include the "start" verb.

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] [Tails-ux] [PATCH] Change syslinux menu entries from "Live" to "Boot"

[anonym]

On 09/11/2015 05:26 PM, Chris Lamb wrote:> Hi,
>
>>  Tails
>>  Tails (failsafe)
>
> We really need a verb here as I explain in my original patch. Whilst it
> does remove the jargon this isn't much better than "Live" IMHO.

I agree with both points.

> Did you have any specific objections to that? I'm not particularly
> bothered about which verb (eg. "Boot" vs "Start"), we just need one.

Or what about verb + noun, i.e. "Start Tails" (and "Start Tails
(failsafe)")? Still succinct, to the point, no jargon => hard to cause
any confusion or ambiguity. The best of two worlds?

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] [PATCH] config/amnesia: use --show-field over sed filtering.

[anonym]

On 09/09/2015 01:37 AM, Chris Lamb wrote:
> Hi,

Hi!

> Attached is the following:
> 
>   commit 6c1c6e20ac22c4c15517d7b231fe0dd1714db8e0
>   Author: Chris Lamb 
>   Date:   Wed Sep 9 00:13:21 2015 +0100
>   
>   config/amnesia: use --show-field over sed filtering.

Unfortunately -S/--show-field isn't available in the dpkg-parsechangelog
available in Debian Wheezy, and we still want to support building Tails
on that target (notably since our Vagrant-based build system still is
stuck on that version). We should naturally do this move once we stop
supporting that target.

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] [PATCH] Change syslinux menu entries from "Live" to "Boot"

[anonym]

On 09/09/2015 01:37 AM, Chris Lamb wrote:
> Hi,

Hi!

Thanks for your interest in Tails!

> Attached is the following:
> 
>   commit 6c331780610f290d495f9c77f16bf7263c4e0f2a
>   Author: Chris Lamb 
>   Date:   Wed Sep 9 00:26:54 2015 +0100
>   
>   Change syslinux menu entries from "Live" to "Boot"
>   
>   Having to explain what "Live" means so early on in the Tails
>   experience
>   (or ever) doesn't seem like the best experience.
>   
>   In addition, choices should typically be verbs - you can "boot" or
>   "delete"
>   things, but to say "live" here is either misleading or just a bit
>   of a
>   non-sequitur.
>   
>   Signed-off-by: Chris Lamb 
>   
>config/binary_local-hooks/10-syslinux_customize | 1 +
>1 file changed, 1 insertion(+)

This seems like something we'd like our UX team to ACK before taking
action. For the record, I'm in favour of this change, and the patch
looks good.

I guess whoever responds to this email should drop tails-dev@ from Cc
and possibly add Chris. Then we can return to tails-dev@ once you've
reached a UX decision.

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] An idea

[anonym]

> - Forwarded Message -
> From: tails-b...@boum.org
> To: "gil guillot" 
> Sent: Thursday, 3 September, 2015 11:01:32 AM
> Subject: Re: Bug report "laptop on battery"
> 
> 
> Hi,
> 
>> I had an other idea for another subject : When you click on the
>> "shutdown immediately" button, it could be "safe" to had a
>> confirmation box telling "Do you really want to shutdown Tails ? Yes
>> or Not" because all data in the session is cleared unlike windows and
>> other OS which people are used to.

The whole point of the *emergency* shutdown applet is that there will be
no verification prompt. That way Tails can be shutdown fast and reliably
when the police kicks your door in. :)

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] Release schedule for Tails 1.6

[anonym]

On 09/03/2015 01:36 PM, bertagaz wrote:
> Hi,
> 
> On Thu, Sep 03, 2015 at 01:03:41PM +0200, anonym wrote:
>>
>> Yes, the "Go wild!" section only. I will have prepared the body for the
>> Tor Blog post an made sure to communicate it to you somehow. I (or
>> BitingBird? :)) can do the "Bug tracker" section too. So, yeah, it
>> should be about 10 minutes of work, really.
> 
> Ok, so let say that I'll do that then. I guess I can also take care of
> this bug tracker stuffs with BitingBird if you wish.

Sure! It's only a few minutes of work any way. :)

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] Release schedule for Tails 1.6

[anonym]

On 09/03/2015 10:53 AM, bertagaz wrote:
> Hi,
> 
> On Fri, Aug 28, 2015 at 12:01:04PM +0200, intrigeri wrote:
>>
>> anonym wrote (27 Aug 2015 14:59:02 GMT) :
>>> Ideally I would like *everything* (including testing, most notably)
>>> but the steps making the release public (announcements on our
>>> website/IRC/twitter/Tor blog) to be done late on 2015-09-21.
>>> If someone with Git commit rights would like to take over that part
>>> (which should be only 5-10 minutes of mindless work, since I will
>>> have prepared everything, + waiting for the Mozilla release
>>> announcement) I would be very happy.
>>
>> I suggest that someone who wanted to get started with RM work (that
>> would be... tadam... bertagaz!) does it. I can assist them on IRC
>> as needed.
> 
> Seems that we had the same idea. :)
> 
> I refrained a bit to reply, as to be honest my plate is already quite
> loaded for this release cycle. So I may need some more information:
> which steps of the release process are we talking about? Is that the "Go
> wild!" one?

Yes, the "Go wild!" section only. I will have prepared the body for the
Tor Blog post an made sure to communicate it to you somehow. I (or
BitingBird? :)) can do the "Bug tracker" section too. So, yeah, it
should be about 10 minutes of work, really.

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] Automated tests specification

[anonym]

On 09/02/2015 11:11 AM, anonym wrote:
> Failing Scenarios:
> cucumber features/time_syncing_bridges.feature:29 # Scenario: Clock way
> in the past in bridge mode
> cucumber features/time_syncing_bridges.feature:45 # Scenario: Clock way
> in the future in bridge mode
> cucumber features/tor_stream_isolation.feature:48 # Scenario: Explicitly
> torify-wrapped applications are using the default SocksPort
> cucumber features/torified_git.feature:22 # Scenario: Cloning git
> repository over SSH
> 
> 186 scenarios (4 failed, 182 passed)
> 1345 steps (4 failed, 5 skipped, 1336 passed)
> 348m33.765s

... and the run without --capture:

Failing Scenarios:
cucumber features/totem.feature:48 # Scenario: Watching a WebM video
over HTTPS, with and without the command-line
cucumber features/totem.feature:58 # Scenario: Copying video files to a
persistence and making sure that they persist

186 scenarios (2 failed, 184 passed)
1345 steps (2 failed, 10 skipped, 1333 passed)
320m10.637s

So there's an 8.9% increase. Of course, due to the failures it's hard to
draw any conclusions with any sort of confidence from 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] Automated tests specification

[anonym]

On 09/02/2015 01:12 PM, intrigeri wrote:
> hi,
> 
> anonym wrote (02 Sep 2015 09:11:43 GMT) :
>> I got a video that was 309 MiB large [...]
> 
> Assuming (very wild guess) that the size gain brought by the proposed
> changes from #10001 can be extrapolated, this could become 117 MiB.
> If that's mostly correct, then with an aggressive enough cleaning
> policy (e.g. delete those that are more than 7 days old), I *guess*
> that we can very well afford storing those. I guess that our existing
> artifacts cleanup script could easily be adjusted to support expiring
> videos as well (note that we may need different expiration policies
> for videos and for other test suite artifacts, that we may want to
> keep longer; not sure yet; needs to be refined).

Great!

>> It's interesting to note that this runtime is not different from what I
>> normally get when running this branch on the isotesters (I said "~350
>> minutes" earlier in this thread),
> 
> Excellent news: this means that the runtime increase concern is not
> valid on lizard -- one less blocker for archiving videos.
> bertagaz also confirmed that archiving them is not much more work for
> him, so we should be good.

I just updated the ticket with more thorough test results. It seems it
*does* increase the runtime with 17% (old video compression) vs 5.8% (new).

The run I talked about above was just one data point, after all, so it's
not entirely surprising if I got outlying results. I'm running another
run without --capture now for comparison. However, there are so many
other variables that can make the runtime differ (transient errors, Tor
bootstrapping issues that make it take a longer time (which seems to
cluster in time for some reasons)) so I'm not sure what that will be run.

Any way, I trust my test results on #10001.

>> which makes me wonder if the main concern of #10001, that --capture
>> increases the runtime (even when enough CPU is available), is
>> actually valid. I'm gonna investigate that now...
> 
> Well, it *is* valid at least on my system. However, it could depend on
> hardware, and/or on the version of the video codec libraries (I did my
> tests on sid, which is useful info because that gives us an idea of
> what software we'll run on our infra in ~2 years).

Right. I guess we need longterm statistics on the isotesters to be able
to see any meaningful numbers.

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] Automated tests specification

[anonym]

On 09/01/2015 06:57 PM, anonym wrote:
> On 09/01/2015 12:04 PM, intrigeri wrote:
>> bertagaz wrote (28 Aug 2015 14:24:51 GMT) :
>>> and might take quite a bit of disk space to store.
>>
>> ... and smaller (#10001). I'm curious how much space a full set of
>> test suite videos take.
> 
> I'll try to remember to collect this info in my next full run.

I got a video that was 309 MiB large with test/6094-improved-snapshots
checked out on an isotester. I don't think the errors I got affected the
runtime (or amount of changes on the screen, which matters more w.r.t.
video compression). Any way, I believe the per-(failed-)scenario
approach is what we really want; videos of the passed scenarios is just
distracting and wasteful.

Failing Scenarios:
cucumber features/time_syncing_bridges.feature:29 # Scenario: Clock way
in the past in bridge mode
cucumber features/time_syncing_bridges.feature:45 # Scenario: Clock way
in the future in bridge mode
cucumber features/tor_stream_isolation.feature:48 # Scenario: Explicitly
torify-wrapped applications are using the default SocksPort
cucumber features/torified_git.feature:22 # Scenario: Cloning git
repository over SSH

186 scenarios (4 failed, 182 passed)
1345 steps (4 failed, 5 skipped, 1336 passed)
348m33.765s

It's interesting to note that this runtime is not different from what I
normally get when running this branch on the isotesters (I said "~350
minutes" earlier in this thread), which makes me wonder if the main
concern of #10001, that --capture increases the runtime (even when
enough CPU is available), is actually valid. I'm gonna investigate that
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] Automated tests specification

[anonym]

On 09/01/2015 12:23 PM, intrigeri wrote:
> bertagaz wrote (26 Aug 2015 17:52:26 GMT) :
>> On Wed, Aug 26, 2015 at 03:38:19PM +0200, anonym wrote:
>>> The current proposal seems to be to only start the automated test run of
>>> a feature branch when it is marked "Ready for QA". This has overloaded
>>> the meaning of this status so it no longer alone means that the branch
>>> is ready for review'n'merge; the reviewer also has to wait until the
>>> automated tester posts the result to the ticket.
>>>
>>> We could get rid of this ambiguity by splitting "Ready for QA" into
>>> "Ready for (automated) testing" (RFT) and "Ready for review" (RFR). Example:
>>>
>>> Let's say I have created a new feature branch and think I'm done. I
>>> assign it to intrigeri (who I want to review it in the end) and mark it
>>> RFT. And automated build is triggered, and then a full run of the test
>>> suite. Let's say the test suite fails. Then it gets reassigned to me and
>>> marked "Dev needed". I fix the issue (which probably was easier to spot
>>> for me than it would be for intrigeri, since I did the implementation)
>>> assign it to intrigeri and mark it RFT again. This time the test suite
>>> passes, and then the ticket is marked RFR automatically. Also, if I run
>>> the test suite myself and see it pass, then I can just mark it RFR directly.
> 
>> I've think about this issue too. My own conclusion was to add a new
>> Custom fiels in redmine, that Jenkins would use, so something similar to
>> yours. The dev mark the ticket as ReadyForQA, then Jenkins run the test
>> suite on it and send its report modifying that field accordingly.
> 
> The way it's conceptualized in Gerrit (and presumably in other similar
> tools) is that Jenkins is "just another reviewer", that can vote +1
> or -1 on a merge request. I like this logic. To translate it into
> Redmine, RfQA means that all reviewers (humans and robots) can start
> looking at the branch, and Pass means that all reviewers are happy
> with it.

Conceptually, I like this.

> I think it would be overly complicated to encode individual
> reviews (e.g. the one done by Jenkins) in the QA Check field, and
> conceptually I prefer to keep QA Check a bit more high level and not
> give it a finer granularity.

I certainly agree that my proposal complicates things.

> So, adding dedicated custom fields seems to be the best option to
> encode individual review results: "Jenkins OK" would be unset
> initially, and set to true (= +1) upon successful testing. Upon failed
> testing:
> 
>  * "QA Check" would be set back to "Dev Needed";
>  * a negative vote from Jenkins is a blocker, so given QA Check has
>been reset already, I'm not sure it's useful to also set "Jenkins
>OK" to "false" (which we would have to revert after pushing a fix
>and setting QA Check = RfQA).
> 
> ... and "Human reviewer OK" would work just the same.

Since pushing stuff into the branch after this field has been set to
true invalidates the Jenkins' test suite run, would Jenkins monitor for
this and unset the field, or is it up to the committer to unset it? I
realize this is not a problem unique to this solution. Any way, doing
this manually gets hairy since we don't necessarily know which commit
Jenkins has tested. I suppose it would help if Jenkins also posted a
message about what commit it has successfully tested. Or maybe the field
we want to add instead could contain the commit?

> But this doesn't address the problem anonym pointed to initially, that
> is "the reviewer also has to wait until the automated tester posts the
> result to the ticket".

And the corollary is that it neither solves the problem: reviewers may
waste time reviewing a branch that breaks an automated test. That's the
important part, IMHO.

> One possible solution would be to assign RfQA
> tickets to Jenkins initially, and once Jenkins has voted +1 (and set
> "Jenkins OK" to true), it could also unassign the ticket from itself,
> and then human reviewers can look into it. Jenkins would still run
> automated tests on branches regardless of their ticket's assignee, as
> specified elsewhere, but at least this would make it clear to human
> reviewers when it's time for them to start reviewing stuff.

Sure. I guess Jenkins would only assign itself, and not assign the
intended human reviewer (since that info isn't available). That seems a
bit awkward to me, to (as the implementer) have to return to the tickets
when Jenkins is done, and then assign the human reviewer.

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] Automated tests specification

[anonym]

On 09/01/2015 12:04 PM, intrigeri wrote:
> Hi,
> 
> bertagaz wrote (28 Aug 2015 14:24:51 GMT) :
>> On Wed, Aug 26, 2015 at 07:46:17PM +0200, anonym wrote:
>> I've also added a new section about the result to keep:
> 
>> ## What kind of result shall be kept
> 
>> The test suite produces different kind of artifacts: logfiles, screen
>> captures for failing steps, snapshots of the test VM, and also videos of
>> the running test session.
> 
>> Videos may be a bit too much to keep, given they slow down the test
>> suite
> 
> Do we have data about how much they slow down the test suite on our
> current Jenkins slaves? See #10001 for partial data about how we could
> make it less resources-hungry...

Speculation: Didn't we plan for an extra core for this? I suppose we'd
need fours cores, for: video capture, sikuli, libvirt (USB emulation in
particular), cucumber-and-other-stuff. Hmm, perhaps
cucumber-and-other-stuff are happy with the left over from the other
cores? So three cores?

>> and might take quite a bit of disk space to store.
> 
> ... and smaller (#10001). I'm curious how much space a full set of
> test suite videos take.

I'll try to remember to collect this info in my next full run.

>> If we want to keep them, we may want to do so only for failing test
>> suite runs.
[...]
> A later iteration (non-blocker) could keep only those from features
> that have failing scenarios. If we agree it would be an improvement,
> I can file a non-blocking ticket about it.
>
> And by the way, perhaps having videos optionally split per-scenario
> would help a lot making good use of such videos: faster download,
> easier to jump to the failing part, less storage needs on our infra.
> anonym and Kill Your TV, if you agree it would be useful and not
> stupid an idea, I can file a non-blocking ticket about it.

Yes, per-scenario videos would be great (my plan was to do this when we
have #8947, but whatever, nothing prevents us from having it now). They
would be more useful than per-feature videos, and actually easier to
implement AFAICT. Please file a ticket!

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] Release schedule for Tails 1.6

[anonym]

Hi,

I'll be the release manager for Tails 1.6, which is a minor release
scheduled on 2015-09-22. For the list of tickets targeting Tails 1.6,
have a look at:

https://labs.riseup.net/code/projects/tails/issues?query_id=187

Here's the preliminary release schedule:

* 2015-09-20:
   - All branches targeting Tails 1.6 *should* *preferably* be merged
 into the `stable` branch by noon, CEST. See more about this below.

* 2015-09-21:
   - All branches targeting Tails 1.6 *must* be merged into the `stable`
 branch by noon, CEST.
   - Tor Browser 4.5.x, based on Firefox 38esr, is hopefully out so
 we can import it.
   - Build and upload Tails 1.6 ISO image and IUKs.
   - Hopefully start testing Tails 1.6. Again, see below.

* 2015-09-22:
   - Finish testing Tails 1.6 by the afternoon, CEST.
   - Release Tails 1.6 during late CEST.

Note that I above have said that I'd prefer everything to be merged one
day earlier than normal. This is because I have a very important AFK
event happening on 2015-09-22 and would, if possible, like to be freed
from my Tails responsibilities as soon as possible that day. Ideally I
would like *everything* (including testing, most notably) but the steps
making the release public (announcements on our website/IRC/twitter/Tor
blog) to be done late on 2015-09-21. If someone with Git commit rights
would like to take over that part (which should be only 5-10 minutes of
mindless work, since I will have prepared everything, + waiting for the
Mozilla release announcement) I would be very happy. I'd do the
remaining post-release steps ASAP on 2015-09-23.

This may of course not work out due to last-minute issues, and in
particular the timing of the Tor Browser release. However, with this
advance knowledge I hope that we can try to keep this schedule on our
side at least. If not it wouldn't be the end of the (my?) world. :) Let
me know what you think!

Testers, please let me know:

* if you are available on 2015-09-21, and which times of that day.

* if you are available on 2015-09-22, 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] Automated tests specification

[anonym]

On 08/26/2015 07:21 PM, bertagaz wrote:
> On Wed, Aug 26, 2015 at 02:00:25PM +0200, anonym wrote:
>> On 07/01/2015 07:19 PM, intrigeri wrote:
>>> bertagaz wrote (25 Jun 2015 09:41:23 GMT) :
>>>> for feature branches, we could run the full test suite only on the
>>>> daily builds, and either only the automated tests related to the
>>>> branch on every git push, and/or a subset of the whole test suite.
>>>
>>> I'm not sure what's the benefit of testing a topic branch every day if
>>> no new work has been pushed to it. In the general case, as a developer
>>> I'd rather see them tested on Git push only, with some rate limiting
>>> per-day if needed.
>>
>> I would say that testing images built due to a Git push only is good
>> enough, but not ideal. We have good reasons for building branches on
>> Debian package uploads too, and retrying on builds triggered by that
>> would be nice as well.
> 
> Yes, the APT upload use case is thought about but reserved for future
> developments, it's not supposed to be taken care of in the current
> milestone.

I know...

> The rational behind my proposal was that it would at least raise the
> issue if there were some external changes that breaks the build of this
> feature branch (mostly, changes in APT/Debian).

... so this was the point I was gonna make, but apparently forgot. And I
some how missed your mention of "external changes" in your response to
intrigeri. Great, then we're on the exact same page! :)

>>> See below wrt. one specific case.
>>
>> I couldn't find what this refers to.
>>
>>>> We can also consider testing only the feature branch that are marked
>>>> as ReadyforQA as a beginning, even if that doesn't cover Scenario
>>>> 2 (developers).
>>>
>>> Absolutely, I think that would be the top-priority thing to do for
>>> topic branches: let's ensure we don't merge crap.
>>
>> It would be great to also ensure that we don't review "crap". :) I guess
>> that is scenario 2, which we explicitly ignore with this proposal. I'll
>> post some ideas about how to deal with that in a separate thread, but I
>> guess this is a good start that will give us 95% of what we want.
> 
> Ok, so that looks like the way to cut down the number of automated tests
> everyone agrees on so far.
> 
> Now I'm wondering if we should implement this at first, or just start
> with testing all of them on eveyr push and see if we need to switch to
> that solution if our infra can't cope with it.

I expect things to quickly go out of hand if we do it on every push, but
hey, my expectations are frequently wrong. I say we try it if it's easy
to quickly switch to your suggested optimization if needed.

>>>> We can also maybe find more ways to split the automated test suite
>>>> in faster subsets of feature depending on the context, define
>>>> priorities for built ISO and/or tests.
>>>
>>> This feels ambituous and potentially quite complex. I say let's design
>>> something simple and then re-adjust.
>>
>> I'm not sure I like this idea in principle. With "context" I assume you
>> (bertagaz) mean the context of the change implemented in the ISO to be
>> tested, e.g. for an ISO that upgrades Tor, the context is "tests that
>> uses Tor". It's true that in that case we may only want to run some
>> subset of tests that uses Tor, but not Tails USB installation/upgrades,
>> for instance. This is in fact something we have done manually, and while
>> it has worked quite well, I think we've already "missed" stuff. After
>> all, these subsets would represent the obvious things to test that I as
>> an implementer or reviewer probably would explicitly test before asking
>> for a review. Hence, only running them wouldn't catch the non-obvious
>> edge cases that would be found outside of the subsets.
>>
>> It should be noted, though, that defining such subsets actually isn't
>> very complex. It can be implemented with cucumbers tags, e.g. we could
>> have scenarios tagged @networking, @tor, @lan, @persistence,
>> @usb_upgrade etc. even in combinations, and then run only scenarios that
>> have at least one of the tags we're interested in.
> 
> Yes, cucumber tags were the solution I was thinking about to implement
> this. But I get your "do not miss stuffs" argument and it sounds
> completely rational to me.
> 
> Yet that could be an option we could combine with the previous one
> (

Re: [Tails-dev] Automated tests specification

[anonym]

On 06/25/2015 11:41 AM, bertagaz wrote:
> I've prepared a blueprint to start this discussion and take notes of the
> decisions:
> https://tails.boum.org/blueprint/automated_builds_and_tests/automated_tests_specs/

Looks great! For the record, I looked at the spec as of commit e70f8e7.

> # Facts
>
> Running the full test suite on 1 isotester hosted on Lizard takes
> around 8 hours.

FYI, with the test/6094-improved-snapshots branch (previously
test/wip-improved-snapshots) a full run on lizard takes ~350 minutes, so
a bit less than six hours. On my laptop it takes around half that, at
180 minutes per full run. It seems

> We intend to run 4 isotesters, so at the moment we would be able
> to run 12 full test suites per day.

So with test/6094-improved-snapshots we can run 24/6 * 4 = 16 full runs
per day! :)

OTOH, we'll keep on adding more tests, so these figures will eventually
becomes obsolete. Until the end of 2015 (when we "probably" get more
hardware) I think we can assume that the run time of a full test suite
will not increase by more than 33% due to new tests, but if we assume
this worst case scenario, then with the test/6094-improved-snapshots
branch we end up at your 12 runs per day number again.

> Scenario 1 : reviewer

vs.

> Scenario 2 : developer

The current proposal seems to be to only start the automated test run of
a feature branch when it is marked "Ready for QA". This has overloaded
the meaning of this status so it no longer alone means that the branch
is ready for review'n'merge; the reviewer also has to wait until the
automated tester posts the result to the ticket.

We could get rid of this ambiguity by splitting "Ready for QA" into
"Ready for (automated) testing" (RFT) and "Ready for review" (RFR). Example:

Let's say I have created a new feature branch and think I'm done. I
assign it to intrigeri (who I want to review it in the end) and mark it
RFT. And automated build is triggered, and then a full run of the test
suite. Let's say the test suite fails. Then it gets reassigned to me and
marked "Dev needed". I fix the issue (which probably was easier to spot
for me than it would be for intrigeri, since I did the implementation)
assign it to intrigeri and mark it RFT again. This time the test suite
passes, and then the ticket is marked RFR automatically. Also, if I run
the test suite myself and see it pass, then I can just mark it RFR directly.

I do not know if this complicates the current plans too much, so perhaps
this could be a future improvement. Or perhaps the current plan will be
good enough in practice. I suppose it's bad in itself to introduce yet
another QA status, complicating things.

Also a question:

>   And the developer who proposed the merge must be notified
>   And the ticket should be reassigned to the branch submitter

Is deciding "the developer who proposed the merge" and "the branch
submitter" actually easy? We do not automatically get a mapping between
Git authors and Redmine users. And parsing the redmine ticket history
(e.g. who marked the ticket a certain QA status last?) also seems
hairy, but perhaps it's "easy" via some API (SQL?) that I'm unaware of?

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] Automated tests specification

[anonym]

On 07/01/2015 07:19 PM, intrigeri wrote:
> bertagaz wrote (25 Jun 2015 09:41:23 GMT) :
>> for feature branches, we could run the full test suite only on the
>> daily builds, and either only the automated tests related to the
>> branch on every git push, and/or a subset of the whole test suite.
> 
> I'm not sure what's the benefit of testing a topic branch every day if
> no new work has been pushed to it. In the general case, as a developer
> I'd rather see them tested on Git push only, with some rate limiting
> per-day if needed.

I would say that testing images built due to a Git push only is good
enough, but not ideal. We have good reasons for building branches on
Debian package uploads too, and retrying on builds triggered by that
would be nice as well.

> See below wrt. one specific case.

I couldn't find what this refers to.

>> We can also consider testing only the feature branch that are marked
>> as ReadyforQA as a beginning, even if that doesn't cover Scenario
>> 2 (developers).
> 
> Absolutely, I think that would be the top-priority thing to do for
> topic branches: let's ensure we don't merge crap.

It would be great to also ensure that we don't review "crap". :) I guess
that is scenario 2, which we explicitly ignore with this proposal. I'll
post some ideas about how to deal with that in a separate thread, but I
guess this is a good start that will give us 95% of what we want.

>> We can also maybe find more ways to split the automated test suite
>> in faster subsets of feature depending on the context, define
>> priorities for built ISO and/or tests.
> 
> This feels ambituous and potentially quite complex. I say let's design
> something simple and then re-adjust.

I'm not sure I like this idea in principle. With "context" I assume you
(bertagaz) mean the context of the change implemented in the ISO to be
tested, e.g. for an ISO that upgrades Tor, the context is "tests that
uses Tor". It's true that in that case we may only want to run some
subset of tests that uses Tor, but not Tails USB installation/upgrades,
for instance. This is in fact something we have done manually, and while
it has worked quite well, I think we've already "missed" stuff. After
all, these subsets would represent the obvious things to test that I as
an implementer or reviewer probably would explicitly test before asking
for a review. Hence, only running them wouldn't catch the non-obvious
edge cases that would be found outside of the subsets.

It should be noted, though, that defining such subsets actually isn't
very complex. It can be implemented with cucumbers tags, e.g. we could
have scenarios tagged @networking, @tor, @lan, @persistence,
@usb_upgrade etc. even in combinations, and then run only scenarios that
have at least one of the tags we're interested in.

>> The automated test suite MUST be able to run features in parallel
>> for a single automated build ISO. This way, if more than one
>> isotester are idle, it can use several of them to test an
>> ISO faster.
> 
> Wow! Not sure if/how this can work out, or actually optimize things
> much, with the upcoming new VM snapshots handling.

I doubt we'll have this for a while and agree with downgrading it to a
"MAY". Or maybe even dropping it, see my answer to the next quite. The
remainder of the answer under this quote will deal with the issues we'd
face if we want to do this, for the interested:

The test suite wasn't written with this requirement considered, and
cucumber itself doesn't support any form of parallelism. I've seen hacks
that wrap around cucumber that allows it in various forms, like the
parallel_tests gem [1].

[1] https://github.com/grosser/parallel_tests

In principle, for parallelism to be valid, the "units" you parallelize
around must be atomic, so e.g. no global, mutable state is shared
between them, at least not without carefully working around the problems
that such sharing can cause. In its current state, without the new
snapshot system, our test suite could be parallelized on the feature
level since we do not share anything important between features.
However, *with* the new snapshot system, the checkpoints we create are
shared between features, so extra care must be taken. I guess we'd need
to use locks + waiting for their creation, or something.

So, at least from the test suite's *internal* perspective it should be
possible and perhaps not even super difficult (although I'm sure I've
missed something that will make it more complex). I do worry about the
logic needed outside the test suite though, that organizes the parallel
runs and combines results (e.g. error logs) and such. Sounds very hairy.

> Anyway: I doubt we'll have the situation when we have idle
> isotesterN's -- we're rather trying to limit the workload to something
> they can handle -- so perhaps it's not worth putting too much time
> into this?

Actually, let's ask the question: what would parallel tests actually do
for us? Given intrigeri's observation (i.e. "I doubt we'll [..

Re: [Tails-dev] [urgent] Please help: reviewing branches for 1.5

[anonym]

On 08/03/2015 04:45 PM, intrigeri wrote:
> * #8471 ("Support 32-bit UEFI boot") ← that one is a new feature;
>   I would be sad if it didn't make it into 1.5, and it shouldn't be
>   too hard to review; mosty of you will lack the hardware to test it,
>   so you'll have to trust me on the fact that it actually works.

I don't have the hardware, but I'll take it and only look for
regressions on other hardware. If any one has 32-bit UEFI hardware and
want to help, let me know!

> * #9748 ("apt.feature fails in the 1.5 devel branch with "No space
>   left on device"") ← this one should be mostly trivial, and fixes
>   a serious regression brought in during the 1.5 cycle; Kill Your TV
>   already reviewed and tested it, so I could be bold and merge it, but
>   still it would be a nice bonus to have a committer look at it.

Taken.

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] TAILS build system with Vagrant 1.7.3

[anonym]

On 07/16/2015 02:11 PM, Adam Burns wrote:
> On 07/15/2015 09:12 PM, anonym wrote:
>> On 07/13/2015 06:32 PM, Adam Burns wrote:
[...]
>>
>> You say that the "Vagrant/VirtualBox shell provisioning of the base box"
>> fails, but the above error is clearly from the Tails build script, not
>> while running the provisioning scripts. 
> 
> Perhaps my wording was in error. What I was trying to say clumsily was
> the bash script vagrant/provision/assets/build-tails running on the
> VirtualBox base image tails-builder-20141201 reeled in by the 'rake
> build' command appears to bork with package dependency issues.

To be clear, I wasn't nitpicking, only trying to make sure that we talk
about the same things. :)

[...]
>> vagrant@tails-builder-20140709:~$ dpkg-query -l | egrep 
>> "hopenpgp-tools|keyringer|linux-image-3.16.0-4"
>> vagrant@tails-builder-20140709:~$ 

This is expected -- see intrigeri's answer. In addition to his question:
do you use an APT cacher or similar?

[...]
> Looking again at https://tails.boum.org/contribute/design/vagrant/ to
> try to rebuild tails veewee base box from first principles:
> 
>> After issuing the commands below, Veewee will download the boot ISO image, 
>> drive the debian-installer using preeseding and run postinstall.sh to take 
>> care of seting up the environment expected by Vagrant.
>>
>> ORIG_BOXNAME=tails-builder
>> DATE="$(date +%Y%m%d)"
>> BOXNAME="${ORIG_BOXNAME}-${DATE}"
>> sed -i "s/tails-builder-[0-9]\{8\}/${BOXNAME}/" vagrant/Vagrantfile
>> mkdir -p "${VEEWEE_SRC}"/definitions
>> cp -a vagrant/definitions/${ORIG_BOXNAME}" vagrant/definitions/${BOXNAME}"
>> veewee vbox build "${BOXNAME}"
>> vboxmanage controlvm "${BOXNAME}" acpipowerbutton
>>
> 'veewee vbox build' (in vagrant CWD) gives 404 error on
> http://cdimage.debian.org/debian-cd/7.5.0/amd64/iso-cd/debian-7.5.0-amd64-netinst.iso
> 
> Looks like this ISO image has been removed from the Debian site.

Indeed. Try upgrading the url in
vagrant/definitions/tails-builder/definition.rb to:


http://cdimage.debian.org/mirror/cdimage/archive/7.8.0/amd64/iso-cd/debian-7.8.0-amd64-netinst.iso

Also update the md5 sum accordingly.

That said, I doubt this is relevant. If you like you could try using the
Debian Jessie-based build box referred to in the
feature/9262-build-on-jessie branch.

> Some notes on to verify and replicate the veewee base box :
> 
> - VEEWEE_SRC does not appear to be defined anywhere in the devel branch.

Right, that is fixed in the feature/9262-build-on-jessie branch.

> - the VirtualBox host shell prompt date is out of sync with the veewee
> base box filename although likely only a cosmetic issue by static
> setting of VIRTUAL_MACHINE_HOSTNAME in vagrant/lib/tails_build_settings.rb

You are correct. There was an issue with the previous build box, so I
had to unpack it and change a line and then re-pack it. Any way, this
discrepancy is of no consequence.

> I'll look at this more closely when I can, but the core issue appears to
> be that the current veewee base box image does not satisfy build
> requirements for the current devel branch?
> 
> I could be mistaken on this, so feedback/corrections are much
> appreciated. Has anyone successfully built tails using vagrant lately?

I built the 'devel' branch using vagrant last night.

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] TAILS build system with Vagrant 1.7.3

[anonym]

On 07/13/2015 06:32 PM, Adam Burns wrote:
> Got Vagrant 1.7.3 to inter-operate with the current TAILS Rakefile by
> adding explicit paths for some extra require commands. This likely is
> not needed once ruby/rake system paths for require commands are set
> correctly (I'm a ruby/rake n00b).
> 
> The Vagrant/VirtualBox shell provisioning of the base box
> 'tails-builder-20141201' currently errors with the following packages
> not found.
> 
> P: Begin installing packages...
> Reading package lists...
> Building dependency tree...
> Reading state information...
> Package hopenpgp-tools is not available, but is referred to by another
> package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
> 
> Package keyringer is not available, but is referred to by another package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
> 
> Package linux-image-3.16.0-4-586 is not available, but is referred to by
> another package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
> 
> Package linux-image-3.16.0-4-amd64 is not available, but is referred to
> by another package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
> 
> E: Package 'linux-image-3.16.0-4-586' has no installation candidate
> E: Package 'linux-image-3.16.0-4-amd64' has no installation candidate
> E: Package 'hopenpgp-tools' has no installation candidate
> E: Package 'keyringer' has no installation candidate
> P: Begin unmounting filesystems...
> 
> real4m42.505s
> user2m6.284s
> sys 0m33.978s
> + RET=123
> + '[' -e binary.iso ']'
> + fatal 'lb build failed (1).'
> + echo 'lb build failed (1).'
> lb build failed (1).
> + exit 1

You say that the "Vagrant/VirtualBox shell provisioning of the base box"
fails, but the above error is clearly from the Tails build script, not
while running the provisioning scripts. Which branch are you trying to
build? If you are trying to build something else than the 'devel'
branch, that might explain it, so please try that.

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] Automated builds specification

[anonym]

On 06/16/2015 02:41 PM, bertagaz wrote:
> On Fri, May 29, 2015 at 01:59:06PM +0200, intrigeri wrote:
>> anonym wrote (30 Mar 2015 07:48:28 GMT) :
>>> On 29/03/15 15:04, bertagaz wrote:

>>> Wild (possibly unrelated) idea: instead of only notifying the author of
>>> the last commit of a topic branch, what about notifying all authors of
>>> the topic branch since it deviated from the base branch?
[...]
>>> Also, I guess we need to filter out authors that are not Tails "core"
>>> developers, so they do not get build failure notifications. This applies
>>> to both packages uploaded (when we upload a package built by a 3rd
>>> party), and Git (patches). Hmm.
>>sure.
>> Why?
> 
> I think on the contrary it might be useful for people that are not core
> devs to get notifications on build failure.

I'm not sure that contributors will appreciate these notifications.

Any way, at least some "core" member *must* be notified too since they
have the power to actually fix it so...

>>> This makes me think that we should perhaps look at Git committer
>>> name/email in Git instead of the author.
>>
>> Indeed, Git has separate committer and author "metadata fields" for
>> each commit. But I don't understand what exactly you're suggesting we
>> use them for -- may you please elaborate on this idea?
> 
> I don't think it's that important. The only use case I see where it would
> change who gets the notification would be when one of us import a patch
> we received. Then, it is interesting still to use the author field, as it
> means that the notification would be sent to the one who actually wrote
> the patch, and not just to the one who merged it. Or maybe we want both of
> them to be notified?

... notifying both author and committer seems like a very nice idea.

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] RFC: persistent Tor state

[anonym]

On 06/15/2015 07:09 PM, Alan wrote:
> The 1st drawback: "If the attacker records that someone has been
> using a given Entry Guard at a given location in the past, and then
> someone uses the same Entry Guard at the same location, then there are
> chances that it's the same person who is back to that location." looks
> quite concerning to me, as I believe this kind of data can easily be
> recorded automatically and used afterwards: 
> 
> - what about a delay after which not to reuse an old location? Would
>   that be a major problem for mitigating the "attacks against anonymity
>   via stable Entry Guard(s)"?

A lot of thought and research has gone into selecting the entry guard
lifetime. We're already gonna mess up all this quite a bit with the
location-aware guards, so I'm wary of messing with it even more.

> - what about prompting the user, when they reconnect to an old location
>   after having connected to other, if they want to reuse the data or
>   not?

Well, such prompts are not good UX, and since this will affect all users
of persistence whenever they reconnect at an old place it will happen a
lot and they will be trained to pick one of the options without thinking.

We also toyed a bit about having an option in the greeter, which would
merge this option with MAC spoofing (since both are about geotracking),
but I'm not sure that's better. Also, we have good reasons for spoofing
the MAC by default, and good reasons for using stable guards by default,
and these are conflicting for such a "merged" option. And having two
options about something that will have a similar high-level explanation
seems confusing.

So, perhaps a pop-up is the best we can do if we want to delegate the
decision to our users?

> It's not very clear to me the implications of not reusing these
>   data however.

"not reusing" => no location tracking, but no benefit from having stable
guards. Of course, how to compare these two conflicting goals will be
very hard to explain to our users. Or did you think about something else?

Thanks for your input!

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] RFC: persistent Tor state

[anonym]

On 05/21/2015 05:38 PM, sajolida wrote:
> intrigeri:
>> anonym and I have made great progress on this front, and we would like
>> feedback from you folks regarding the state of our current reasoning
>> and preferred design:
>>
>>   https://labs.riseup.net/code/issues/5462
>>   https://tails.boum.org/blueprint/persistent_Tor_state/
>>
>> In particular, the "Drawbacks of persistent Tor state" section is
>> important, and because of it the proposed design will require some
>> project-wide decision:
>>
>>   https://tails.boum.org/blueprint/persistent_Tor_state/#drawbacks
>>
>> => added to the summit's agenda, but we can certainly start discussing
>> it earlier.
> 
> I've read the blueprint and really much like it. I'm a bit scared about
> the drawbacks but I wonder how we could do better...
> 
> In one the drawback you describe an attacker faking the MAC address of
> the home router of the user as a confirmation attack to identify her
> somewhere else. You are supposing that the attacker spoofs only the MAC
> address of the AP. Could it be some kind of mitigation to also require
> the attacker to spoof the SSID? Because then, if Tails doesn't
> auto-connect to that AP, the user might detect that there is an AP
> faking her home SSID.

I wouldn't call this a mitigation, but at least it's something.

> This might then become a new argument to fix #7165
> [NetworkManager autoconnects to persistent wireless networks in Wheezy].

Definitely.

> So would it then make sense to hash:
> 
> hash(Tails device secret, N bits of gateway MAC, SSID)
> 
> Of course, I'm simplifying here to Wi-Fi only as there is no notion of
> SSID with wired connections. But you know, wire is deprecated :)

If there's no SSID, like on wired connections, we just set a default
SSID of the empty string or whatever.

> On another topic, I found the shortcut to the 6 number a bit too quick.
> How do you go from "between 500 and 2000 Tor relays" and "N=6 → 64
> possible Tor states"?

We do not really have any solid reasoning here. We need to make a
worst-case analysis for how N affects the probability of picking
compromised guards in a Tor network where C out of G guards are
compromised (and in the control of our local attacker).

Thanks for your input!

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] [review'n'merge:1.4.1] bugfix/9126-deny-tor-browser-access-to-recently-used

[anonym]

On 06/06/2015 05:02 PM, intrigeri wrote:
> Hi,
> 
> this branch denies Tor Browser access to the list of recently
> used documents. Please review'n'merge into stable. Thanks!

Merged!

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] [review'n'merge:1.4.1] bugfix/9364-do-not-modify-hardware-clock

[anonym]

On 06/05/2015 07:22 PM, intrigeri wrote:
> Hi,
> 
> this branch should fix #9364, that is we may be currently modifying
> the hardware clock on shutdown. I've tried (not very hard) for a week
> to test this on bare metal but failed to find appropriate hardware.
> It should be easy for the reviewer, thanks to the details on the
> ticket, to test if the bug is indeed a real one, and if the fix does
> correct it... and they would have to do it anyway, right? :)

As can be seen on the ticket, this fix shouldn't be needed. Still, it's
good for "completeness", and the doc update is nice. Merged!

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] [review'n'merge:1.4.1] bugfix/7249-truncated-notifications

[anonym]

On 06/11/2015 01:39 PM, intrigeri wrote:
> Hi,
> 
> I don't know why, back when we were getting Tails/Wheezy ready I did
> everything so that this bug would be "fixed" (well, not really, but
> improved a bit) in Jessie, and then I forgot to bring the improvements
> back to Tails. Thanks to goupille (who reported this problem again
> recently), I finally did it => please review'n'merge into stable and
> devel. See comments on the ticket wrt. how it's better but not
> perfect, and why I see it as good enough.

Since most people seem to agree it's an improvement, I've merged 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] [review'n'merge:1.4.1] bugfix/9523-eatmydata-v82-everywhere

[anonym]

On 06/10/2015 02:28 PM, intrigeri wrote:
> Assigned to anonym since our other usual reviewers seem to be mostly
> unavailable these days. Please merge into stable, devel and
> experimental, and then ping me so that I can:
> 
>  * upgrade eatmydata on our Jenkins ISO builders (without the backport
>there too, all builds will start failing);
>  * send a heads up to code contributors so that they update their
>build system.

This branch has been merged!

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] [review'n'merge:1.4.1] bugfix/9406-jenkins-build-in-clean-git

[anonym]

On 05/15/2015 11:28 AM, intrigeri wrote:
> Hi,
> 
> the proposed branch fixes build failures in Jenkins, that are caused
> by our build system refreshing the wiki (uh, twice) *before* merging
> the base branch.
> 
> Please review'n'merge into stable and devel (the earlier it's done,
> the less Jenkins build failure noise we'll get :)

I missed this one somehow. Merged 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] Release versioning

[anonym]

On 06/03/2015 12:38 PM, intrigeri wrote:
> sajolida wrote (01 Jun 2015 11:31:18 GMT) :
>> anonym:
>> Couldn't we add an extra number only when we do an
>> emergency release?
> 
> I think we can, and we should.

Let's just be clear on that it is the action of adding an extra *last*
number for emergency releases only that fixes the issue that intrigeri
originally raised.

>>> We could adopt a "even second number for bugfix releases, odd for
>>> major/feature releases" scheme (similar to what Linux used before),
>>> which would fit in perfectly with how we have been alternating between
>>> them so far (which I quite like and hope we will continue with). For
>>> emergency releases the third number would then serve the function you
>>> propose for the fourth number. If we ever want to release two major
>>> releases in a row, or want to postpone a major release, then we just
>>> increment by two.
> 
>> ... or change from odd/even to even/odd. If we consider that this is
>> only meaningful internally and only happens on rare occasions.
>> Skipping a number might feel weird to users, but I think it's no big
>> deal either.
> 
> I would personally really dislike having to deal with
> odd/even->even/odd changes of meaning. The ability to easily tell if
> a past or future release was or will be a major or a minor one is
> critical to me for planning work, deliverables, etc. Of course I'm
> totally biased on this one, but I feel it's much more important that
> some minor weirdness for user-visible version numbers: I bet 99% of
> the users don't care about version numbers, and don't understand their
> meaning anyway, while these numbers impact a lot our daily work.

Switching between not making a distinction between even and odd numbers
is the obvious solution so there was a reason that I picked that weird
scheme. That reason wasn't stated, but it is that I too feel it's
important to quickly be able to tell whether a release was/is/will be a
major, bugfix or emergency one.

>> I'm also tempted to propose changing the first number with major Debian
>> versions (we already almost did that for Tails Wheezy). The way we deal
>> with it right now is not really related to what the user experiences as
>> a "big change" as our improvements come in gradually. Still, a change in
>> Debian version is both a huge work for us and a big change for the user
>> (Tails Wheezy and Jessie both introduce a big change in the appearance
>> of the desktop environment, not to mention all the major updates of
>> included software).
> 
> I like it.
> 
> I'm tempted to amend this proposal with "first number matches Debian's
> major release version", e.g. Tails/Jessie would be Tails 8.0, but I'm
> not convinced myself that this would add much value => food for
> thought, if you folks find a convincing argument in favour of it,
> please state it, but before that happens, no need to explain why it
> wouldn't be good.

Quite a lot of user-facing changes are to be expected with Debian major
upgrades, so incrementing the first number kinda makes sense. For users
the 1.0.1 -> 1.1 upgrade was obviously more significant (mostly due to
the GNOME 2 -> 3 transition, and no IUK) than 0.23 -> 1.0, or perhaps
even any upgrade we ever released. When we release the first Tails based
on Jessie, the changes will be similarly big, and it may appear weird if
that happens with a tiny bump of the second number. I guess Debian geeks
also would appreciate to quickly be able to see what version of Debian
that Tails is based on. Of course, given how much we install from
testing/sid/backports, that will only be a half-truth.

Tails 1.0 was about some sort of feature-completeness according to plans
we had worked on for years. While there always will be more
Tails-specific improvements we can do, I wonder if we ever will need to
do something like that again. Well, perhaps if we do something that
fundamentally changes Tails, like Tails/Cubes or similar. Any way, the
point I'm trying to make is, if we do what you propose, then we lose the
control of the first number, and cannot use it for our own visions. Do
we care?

>> As you can see, I'm generally more tempted to have version numbers
>> relevant for the user than for us.
> 
> This seems to be one point we disagree about in theory, but I'm sure
> we can find consensual solutions when looking at the practical aspects :)

I'm in the middle. I think the even/odd scheme already improves the
situation for our users (e.g. makes them more readable and easier to
distinguish) even with the *potential* version skipping, so I think it's
a good compromise.

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] Release versioning

[anonym]

On 06/03/2015 01:51 PM, intrigeri wrote:
> Hi,
> 
> anonym wrote (03 Jun 2015 11:22:31 GMT) :
>> On 06/03/2015 12:26 PM, intrigeri wrote:
>>> Note that strictly speaking, we don't need the "Tails_" prefix. Also,
>>> I would find it nice to clearly distinguish the "target versions" that
>>> will be 100% reached on a flag day, and by releasing a given Tails
>>> only (e.g. Tails/Jessie), from the ones that are more general
>>> milestones. So, that could become:
>>>
>>> * 2.0 => Milestone_Sustainability
>>> * 3.0 => Milestone_Hardening
>>> * 4.0 => Tails_Jessie
>>>
>>> Thoughts?
> 
>> This makes sense but "Milestone_" feels like a redundant prefix in a
>> field called "Milestone".
> 
> Well, the field is called "Target version".
> 
>> Do we really need a prefix at all?
> 
> Maybe not, but I like the fact that "milestone" expresses something
> that's specific and measurable. I'm afraid that if we drop it, then
> these target version names will look like generic categories to which
> we can add anything that fits into what their name expresses.

Hah! I believe I was just confused because we constantly refer to them
as milestones. So, yeah, I agree with you.

>> Also, for the "general" milestones, I guess they be recurring ones. E.g.
>> the one that's currently called 3.0 is perhaps only an initial push for
>> such related things, but maybe there will be another one. Reusing
>> milestones seems like a bad idea, so perhaps they too can be versioned,
>> e.g.:
> 
>> * 2.0 => Sustainability_1.0
>> * 3.0 => Hardening_1.0
> 
> Totally makes sense, and even better, it addresses the concern
> I expressed above.
> 
> But I'm worried that using such version numbers, especially
> two-components ones in the same range as Tails releases', will be
> confusing,

Yeah, makes sense.

> so my current proposal would be:
> 
>  * 2.0 => Sustainability_M1
>  * 3.0 => Hardening_M1
> 
> ("M" means "milestone", I think I've seen that used elsewhere in
> similar contexts)

Sounds great!

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] Release versioning

[anonym]

On 06/03/2015 12:26 PM, intrigeri wrote:
> anonym wrote (31 May 2015 22:20:13 GMT) :
>> * 2.0 => Tails_maintainability
>> * 3.0 => Tails_hardening
>> * 4.0 => Tails_jessie
> 
> Yay, I like it!
> 
> Note that strictly speaking, we don't need the "Tails_" prefix. Also,
> I would find it nice to clearly distinguish the "target versions" that
> will be 100% reached on a flag day, and by releasing a given Tails
> only (e.g. Tails/Jessie), from the ones that are more general
> milestones. So, that could become:
> 
> * 2.0 => Milestone_Sustainability
> * 3.0 => Milestone_Hardening
> * 4.0 => Tails_Jessie
> 
> Thoughts?

This makes sense but "Milestone_" feels like a redundant prefix in a
field called "Milestone". Do we really need a prefix at all?

Also, for the "general" milestones, I guess they be recurring ones. E.g.
the one that's currently called 3.0 is perhaps only an initial push for
such related things, but maybe there will be another one. Reusing
milestones seems like a bad idea, so perhaps they too can be versioned,
e.g.:

* 2.0 => Sustainability_1.0
* 3.0 => Hardening_1.0

Just throwing an idea out there. Not sure if I like it, even.

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] Release versioning

[anonym]

On 05/31/2015 09:24 AM, intrigeri wrote:
>  * we're not very clear what the first component means (1.0 had
>a well-defined meaning, no idea what 2.0 will be; we're currently
>using 2.0 and 3.0 on our roadmap to make mid/long-term perspectives
>and goals more readable to everyone involved, but that doesn't
>mean we'll indeed release ISOs labeled 2.0 and 3.0 when we reach
>them; I know that's confusing, sorry)

I think it would be much nicer to leave the version numbers for actual
releases, and use descriptive milestone names for larger visions that
currently do not have a set Tails release, something like:

* 2.0 => Tails_maintainability
* 3.0 => Tails_hardening
* 4.0 => Tails_jessie

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] Release versioning

[anonym]

On 05/29/2015 05:19 PM, intrigeri wrote:
> Hi,
> 
> it popped up to my mind that our current versioning scheme is a bit
> painful whenever we need to insert an unexpected release: e.g.
> when we've put out 1.3.1, it "stole" a version number that was
> "reserved", which can result in some confusion, e.g. when looking up
> planning information in past email.

Yes, this was quite annoying (i.e. it invalidated the original 1.3.1
release schedule posted to this list).

> Perhaps we should call all our expected releases a.b.c, and "bonus"
> intermediary releases a.b.c.d? In the case at hand, instead of 1.3,
> 1.3.1 and 1.3.2, this would have given 1.3.0, 1.3.0.1, and 1.3.1.

I've been thinking about proposing *exactly* this but I've been unsure
since introducing yet another number make them harder to read Let's face
it, Firefox' and Chrome's version inflation is actually an instance of
KISS. Personally I don't think we have to go that far, and do like to
have a first number signifying significant milestones.

I'm wondering how much the knowledge of whether a new Tails release is a
major release or not really matters for users. After all, they should
upgrade no matter what and should always read the release notes since
there could significant changes even in bugfix releases (for security
reasons). Hence it seems like making that distinction is only important
for contributors, who we can expect more from for reading extra meaning
in the version numbers.

We could adopt a "even second number for bugfix releases, odd for
major/feature releases" scheme (similar to what Linux used before),
which would fit in perfectly with how we have been alternating between
them so far (which I quite like and hope we will continue with). For
emergency releases the third number would then serve the function you
propose for the fourth number. If we ever want to release two major
releases in a row, or want to postpone a major release, then we just
increment by two.

Here's a "benchmark" between our current scheme, the one you propose
(x.x.x.x) and the even/odd one I'm toying with, for our actual release
history since 1.0:

Current   x.x.x.x   even/odd   Release type
1.0   1.0   1.0(bugfix)
1.0.1 1.0.1 1.2(bugfix, a major release was skipped)
1.1   1.1   1.3(major)
1.1.1 1.1.1 1.4(bugfix)
1.1.2 1.1.1.1   1.4.1  (emergency)
1.2   1.2   1.5(major)
1.2.1 1.2.1 1.6(bugfix)
1.2.2 1.2.1.1   1.6.1  (emergency)
1.2.3 1.2.2 1.8(bugfix, a major release was skipped)
1.3   1.3   1.9(major)
1.3.1 1.3.0.1   1.9.1  (emergency)
1.3.2 1.3.1 1.10   (bugfix)
1.4   1.4   1.11   (major)

IMHO the times around 1.1..1.2.1 in our current scheme and 1.1..1.2.1.1
in x.x.x.x looks pretty crazy (and we will have the same situation
around 2.1), whereas the even/odd scheme always looks sane in terms of
the amount of numbers. The only strange thing in that one are the jumps
from two skipped major releases (1.1 and 1.7). I think a short
explanation in the release notes would make it pretty clear that users
didn't miss a Tails upgrade if we ever have to do that again.

Perhaps I'm just beating at a problem that doesn't really exist and
should stop now. :) No matter what, we definitely need a *separate*
number for emergency releases. Also, I think we should do a better job
at communicating what type (major/bugfix) each release is in the
important places where contributors read about or plans, like in the
release schedule sent to tails-dev@, our website's schedule, and in Redmine.

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] [review'n'merge:1.4.1] bugfix/9416-no-ssl-cert-snakeoil

[anonym]

On 05/20/2015 08:43 AM, intrigeri wrote:
> Hi,
> 
> commit cb24703187001f334617d84884825172197a7893
> Author: intrigeri 
> Date:   Sun May 17 10:25:32 2015 +
> 
> Don't ship the snakeoil SSL key pair generated by ssl-cert in the ISO.
> 
> Not only this introduces needless variations between ISO images built 
> from the
> same source (hence blocks deterministic builds), but there's a risk that 
> some
> package (either one we already ship, or one that we ship some day, or one 
> that
> users install themselves) actually use this pair of SSL keys on the 
> Internet,
> which is wrong since the private key material is public.
> 
> Will-fix: #9416

Merged!

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] Heads up for code contributors: update your build environment

[anonym]

On 05/28/2015 09:20 AM, intrigeri wrote:
> Hi,
> 
> if you're sometimes building Tails ISO images, please APT upgrade your
> build environment and make sure you have live-build
> 3.0.5+really+is+2.0.12-0.tails2.
> 
> For Vagrant users, I've no idea how it should be done, but you know
> how to do it, right? If not, shout and I'm sure that anonym will help
> you :)

This is how you do it:

rake vm:up
rake vm:provision

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] review'n'merge: feature/7976-disallow-lan-in-tor-browser

[anonym]

On 05/26/2015 12:56 PM, anonym wrote:
> I guess we could see 1 as optional:
> 
> * If we skip 1, then we can simply do what FoxyProxy does, i.e. add
>   another bullet in the list of possible explanations for the
>   connection error, e.g. "The Tor Browser blocks access to the local
>   network bla bla".

I just realized that we may need to modify this page even if we do 1. If
we are on a network with a captive portal, start the Tor Browser despite
the warning that Tor isn't ready, and then enter the URL of our favorite
non-LAN web site, e.g. http://www.asdf.com, then we will still get the
"Unable to connect" page, but for a completely different reason, namely
that Tor was blocked from creating a circuit.

So, perhaps we should skip 1 and instead focus on a complete rewrite of
the "Unable to connect" page for all cases, and try to make it stand out
so users will not ignore it. Perhaps it would help if we changed the
header to "The Tor Browser was unable to connect", which is a bit less
generic; hopefully the words "Tor Browser" will be less easy to ignore.
And perhaps it could show the Tor onion (like in about:tor).

On this new page we would mention all common reasons for us getting
here, e.g.:

* Captive portal. In Tails we would also refer to the Unsafe Browser for
dealing with captive portals. Actually this whole bullet is only
relevant in Tails since "normal" Tor Browser users wouldn't even get
here since Tor Launcher would fail.
* LAN is blocked.
* "Tor circuits are sometimes slow and Tor exits are some times blocked,
retry with 'New Tor circuit for this site'"

Possibly some of the bullets from the original "Unable to connect" page
are still relevant. For reference, they are:

* The site could be temporarily unavailable or too busy. Try again in a
few moments.
* If you are unable to load any pages, check your computer's network
connection.
* If your computer or network is protected by a firewall or proxy, make
sure that Tor Browser is permitted to access the Web.

> * If we do 1, then we could dynamically change the page completely
>   to something more specific given that we now know exactly what the
>   error is, e.g.:

To show this very specific explanation when we have detected that the
user tried to visit a LAN address would still be nice. However, if we
can come up with the solve-it-all page above, that is harder for users
to ignore, then I don't think we need to bother about 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] [review'n'merge:1.4.1] bugfix/9417-no-var-cache-man

[anonym]

On 05/20/2015 08:45 AM, intrigeri wrote:
> Hi,
> 
> commit f2fb13129cc9f566a1918acdc78db5d7cd4a6776
> Author: intrigeri 
> Date:   Sun May 17 10:28:39 2015 +
> 
> Stop shipping /var/cache/man/* in the ISO.
> 
> Not only this directory needlessly takes room in ISO images, but it also 
> makes
> IUKs bigger than they could be: there are time-based variations in there.
> 
> Will-fix: #9417
> 
> I've verified that man(1) still works fine with this change in.

Me too. :) I think the only thing one loses from removing the mandb
cache is the `man --appropos` functionality, and perhaps some
performance that is not noticeable by humans.

Merged!

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] [review'n'merge:1.4.1] eatmydata is not being used in the build chroot (#9419)

[anonym]

On 05/20/2015 08:51 AM, intrigeri wrote:
> Hi,
> 
> it was noticed that eatmydata is actually *not* being used for most of
> the Tails build process. Let's fix that.

I "benchmarked" this while doing some other stuff. The speedup isn't
very big. :)

> The needed changes live in two different repositories:
> 
> * live-build: tails/debian-old-2.0+faketime

Merged into tails/debian-old-2!

> * main Tails Git repo: bugfix/9419-eatmydata-in-build-chroot

Merged!

> See #9419#note-3 regarding how to get and test the updated live-build.
> Once successfully reviewed and tested, I'm happy to take care of the
> merge and re-upload it for both i386 and amd64 into our builder-wheezy
> APT suite, if the reviewer doesn't feel at ease doing that.

The packages are now uploaded to both suites.

> And then, I'll update the build doc and send a heads up to
> code contributors.

Please go ahead!

> Also note that the proposed live-build changes also include a tiny,
> unrelated one that will also make things a bit easier when working on
> reproducible builds (#5630). This is meant to minimize the number of
> times we have to go through this special merge process.

\o/

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] review'n'merge: feature/7976-disallow-lan-in-tor-browser

[anonym]

On 05/26/2015 02:24 PM, sajolida wrote:
> anonym:
>> On 05/26/2015 09:52 AM, intrigeri wrote:
>>> Hi,
>>>
>>> for the record, #8711 ("Investigate how we could improve the error
>>> message when browsing LAN from usual Tor Browser") was initially seen
>>> as blocking this work, and anonym's current proposal is to postpone
>>> that part, and to treat with with a priority level "depending on how
>>> much trouble it causes our front desk team".
>>>
>>> I'm personally fine with this proposal.
> 
> Me too.
>
> [...]
>
>> Lastly, my plate is really full for Tails 1.4.1, and I expect some of it
>> to be post-poned to 1.5 and maybe even 1.5.1 (given my vacation plans),
>> so if I'm to do anything more here it may have to wait until Tails 1.6.
> 
> I'd say we can maybe wait and do things properly which is doing 1 in
> coordination with Tor.

Ok, then. I have closed #8711 since the investigation part is done, and
opened #9473 for the implementation, with milestone set to 1.5.1 (I now
realize that 1.5 is a no-no, at least if I'm gonna do it) and assigned
it to me.

> The other error message I'd like to configure is the one saying "The
> proxy server is refusing connections" when Tor is not ready. That's
> related to #8061. So if we can find something that is partly reusable in
> both cases, then that would be great.

Modifying exactly that page is what FoxyProxy does, so this will be
easy. Feel free to create a ticket and make it related to #9473 in some way.

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] review'n'merge: feature/7976-disallow-lan-in-tor-browser

[anonym]

On 05/26/2015 12:56 PM, anonym wrote:
> I did my homework:
> 
> https://labs.riseup.net/code/issues/7976

Argh, I meant:

https://labs.riseup.net/code/issues/9466

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] review'n'merge: feature/7976-disallow-lan-in-tor-browser

[anonym]

On 05/26/2015 09:52 AM, intrigeri wrote:
> Hi,
> 
> for the record, #8711 ("Investigate how we could improve the error
> message when browsing LAN from usual Tor Browser") was initially seen
> as blocking this work, and anonym's current proposal is to postpone
> that part, and to treat with with a priority level "depending on how
> much trouble it causes our front desk team".
> 
> I'm personally fine with this proposal.
> 
> Note that #8711 is about *investigating*, not about actually fixing
> the problem. I suspect this investigation will show that fixing the
> problem is non-trivial, and if that's the case, then IMO it should be
> low-priority.

I did my homework:

https://labs.riseup.net/code/issues/7976

So, while not exactly trivial, it's not hard either. The most awkward
parts will be:

1. Parse the URI and check if the destination address (the @u@ element)
   is a local address so we don't show the error all the time, e.g. when
   mistyping a domain. This is awkward because at least *I* do not know
   of any library functionality present in this context to do that check
   so we have to resort to a IPv4 regex (and IPv6? :S) or something
   ugly like that.

2. To get this into Torbutton in time for the 1.4.1 release, which
   includes reaching an agreement of how the error should be phrased so
   it works for both of us.

I guess we could see 1 as optional:

* If we skip 1, then we can simply do what FoxyProxy does, i.e. add
  another bullet in the list of possible explanations for the
  connection error, e.g. "The Tor Browser blocks access to the local
  network bla bla".

* If we do 1, then we could dynamically change the page completely
  to something more specific given that we now know exactly what the
  error is, e.g.:

  The local network is blocked
  

  The Tor Browser blocks access to the local network bla bla
  ...

  In Tails we'd like to also refer users to the Unsafe Browser here,
  which of course doesn't make sense in general for Torbutton. I guess
  the Tor Browser folks may be fine with a
  extensions.torbutton.running_tails pref that, when true, adds an
  additional paragraph (and I'm sure we'll find other uses for such a
  pref in the future):

  To access the local network, please use the Unsafe Browser bla bla

  where we even could link to the local docs we ship in Tails for the
  Unsafe Browser. Any way, this coordination/communication work will
  make 2 a bit more expensive as well.

What do you think? I added tails-ux@ to Cc since they probably have some
opinions on all this.

Personally I suspect that most users are trained to ignore the "Unable
to connect" page, and would miss any small bullet we add there, making
all this pretty pointless. Hence I suspect this will only be worth doing
if we go all the way and do 1 + a custom error page for when a local
address was blocked. However, I guess skipping 1 still is a viable
*initial* goal for an incremental path to that, if time is scarce ("if",
ha ha!).

Lastly, my plate is really full for Tails 1.4.1, and I expect some of it
to be post-poned to 1.5 and maybe even 1.5.1 (given my vacation plans),
so if I'm to do anything more here it may have to wait until Tails 1.6.

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] review'n'merge: feature/7976-disallow-lan-in-tor-browser

[anonym]

Hi,

So it has been decided that we should disable LAN access in the Tor
Browser, and direct users to use the Unsafe Browser instead for their
LAN-based browsing. Details can be found on the ticket:

https://labs.riseup.net/code/issues/7976

While the branch name and ticket suggests this is a feature, it really
is a security fix, so let's aim for inclusion in the Tails 1.4.1 point
release. I created a automated tests (one less manual test in total!,
yay!) which I hope encourages this move to happen swiftly.

However, let's not merge this before the docs have been written, which
is tracked as #9431. Early testing and code reviews are more than
welcome, though!

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] Question regarding Tails build

[anonym]

On 05/23/2015 10:15 AM, Adam Burns wrote:
> Hi anonym,
> 
> On 05/23/2015 09:09 AM, anonym wrote:
>> On 05/22/2015 01:31 PM, Adam Burns wrote:
>>> I've taken a very quick look at this.
>>>
>>> As the ticket #8086 suggests, it is an issue in the way Rake is used
>>> with a "Monkey-patched" Vagrant to build TAILS.
>>
>> The monkey patch is against *Vagrant*, and has nothing to do with Rake.
>> IIRC newer versions of Vagrant has built-in authentication of the boxes,
>> so that patch can be dropped.
> 
> Yes, understood.
> 
>>> Although the devs are keen to move to some other tech (Docker was 
>>> mentioned), I'm looking at removing Rake (and thus the Vagrant library
>>> calls) from the build process if relatively easy to do so.
>>>
>>> I suspect rake was used to front end Vagrant in earlier days when
>>> perhaps Vagrant was less complete, but from quick examination, I don't
>>> think Rake is required now (nor I suspect the patching). It would
>>> simplify things enormously and bring wider Vagrant version compatibility
>>> across (including non-Debian) build OS environments.
>>
>> For the list of issues we have with Vagrant, see:
>>
>> https://tails.boum.org/blueprint/replace_vagrant/
> 
> Also looked at that & related https://labs.riseup.net/code/issues/7527
> some time back. Most of the issues appear to be solved except for the
> library calls in the rakefile(?)

Please look a bit closer. Beyond importing some constants, we hack in
some stuff for backwards-compatibility with older versions of Vagrant
(see more about this issue below), but there's nothing interesting there
to be concerned about (unless I'm mistaken -- please enlighten me in
that case).

> Both Vagrant & vagrant-libvirt (installation through available though
> vagrant) have matured to some degree. Qemu/KVM and VirtualBox images can
> be built in parallel, or on choice of provisioning environment from a
> Vagrantfile.

Ok, that sounds great! However, before I lost hope about Vagrant as our
"official" build tool, my impression was that they as a project were
moving things too fast, not caring much about backwards compatibility
(including plugins, like vagrant-libvirt hard-depending on
ever-increasing versions of base Vagrant), and making it very hard to
support different versions of Vagrant at the same time. Hence our hope
to support Debian stable + Debian testing + Debian sid + latest Ubuntu
LTS + Ubuntu current (if not LTS). Also, it looked painful
maintenance-wise (and has proved to be so). Perhaps it's better now, but
it's not clear to me. Lastly, from our bluepint: "Vagrant hasn't been
actively maintained in Debian for a while. It'll be part of Jessie, but
that was by a very short margin", which is problematic from Tails'
perspective.

> But granted my current experience has been with veewee, Vagrant, ansible
> and VirtualBox/Qemu/KVM so may not be entirely appropriate here.

It sounds relevant. Patches are certainly welcome to improve the current
situation. Even if "we" (the "core" developers, whatever) move towards
docker it wouldn't hurt to also keep Vagrant (with the Virtualbox
backend, and preferably with Libvirt too) as an alternative  if someone
is committed to maintain it in Tails. And to make sure Vagrant is
well-maintained in Debian.

However, it's a bit painful that veewee (and other stuff in the Vagrant
world we need?) isn't packaged in Debian. If "we" move to docker, it'd
be nice if there was a tool which could convert the docker image we will
provide into a Vagrant box.

> I still hope to put in small amount of time to at least strip rake out
> of the mix to then suggest/assess what may be possible after that :)

The current Rake logic is quite nice, IMHO, and I think you must have
misunderstood something about the whole situation. Rake is nothing else
than a Make-like system, and we don't do anything crazy with it. I
wouldn't be surprised if we end up adapting our current Rakefile to use
docker in case we move to it.

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] Question regarding Tails build

[anonym]

On 05/22/2015 01:31 PM, Adam Burns wrote:
> I've taken a very quick look at this.
> 
> As the ticket #8086 suggests, it is an issue in the way Rake is used
> with a "Monkey-patched" Vagrant to build TAILS.

The monkey patch is against *Vagrant*, and has nothing to do with Rake.
IIRC newer versions of Vagrant has built-in authentication of the boxes,
so that patch can be dropped.

> Although the devs are keen to move to some other tech (Docker was 
> mentioned), I'm looking at removing Rake (and thus the Vagrant library
> calls) from the build process if relatively easy to do so.
>
> I suspect rake was used to front end Vagrant in earlier days when
> perhaps Vagrant was less complete, but from quick examination, I don't
> think Rake is required now (nor I suspect the patching). It would
> simplify things enormously and bring wider Vagrant version compatibility
> across (including non-Debian) build OS environments.

For the list of issues we have with Vagrant, see:

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

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] Question regarding Tails build

[anonym]

On 05/22/2015 07:26 PM, kurono wrote:
> It works indeed thanks!
> 
> El 22/05/15 a las 13:37, Adam Burns escribió:
>> kurono,
>>
>> During the meanwhilst, you may want to take a look at this
>> https://labs.riseup.net/code/issues/8304 to get your build working with
>> a suitable Vagrant version.

The method described in the patch to #8304 involves downloading and
installing unauthenticated .deb:s. Is there really a problem with the
secure way we described:

https://tails.boum.org/contribute/build/#index1h2

I'm referring specifically to the part around "At the moment Tails
relies on a version of Vagrant (the 1.4.x series) that is not packaged
in Debian any more. Here's a workaround for both Debian Wheezy and Jessie".

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] Question regarding Tails build

[anonym]

On 05/22/2015 09:43 AM, kurono wrote:
> Hi,
> 
> If I understand it correctly, the only current way of building Tails now
> is manually as described here:
> https://tails.boum.org/contribute/build/
> right?
> 
> Or is there another way that works?

Using the Vagrant method also works both in Debian Wheezy and Jessie
(proof: I use it). Please let us know if the existing instructions for
installing the dependencies do not work.

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 failed in Jenkins: build_Tails_ISO_experimental #2276

[anonym]

On 05/19/2015 01:04 AM, tails-sysadm...@boum.org wrote:
> [...]
> W: Failed to fetch 
> http://ftp.us.debian.org/debian/dists/experimental/main/binary-i386/Packages  
> Hash Sum mismatch
> 
> E: Some index files failed to download. They have been ignored, or old ones 
> used instead.
> Fetched 43.1 MB in 19s (2224 kB/s)
> P: Begin unmounting filesystems...
> [...]

Would it be possible to teach jenkins to detect this particular type of
transient APT issue (which isn't that uncommon), and trigger a rebuild?

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] [review'n'merge:1.4] bugfix/9370-AppArmor-hardening-Pidgin

[anonym]

On 05/11/2015 04:01 PM, intrigeri wrote:
> Hi,
> 
> this branch fixes a hole in Pidgin (and possibly other apps) AppArmor
> confinement, discovered thanks to the ongoing audit of our AppArmor
> policy (#8007). Kill Your TV has run the relevant automated tests and
> they pass. Please review'n'merge, and very sorry for the last
> minute notice.

Merged!

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] Truly Random Mac Changer

[anonym]

On 05/08/2015 10:11 PM, intrigeri wrote:
> Peter N. Glaskowsky wrote (08 May 2015 18:59:35 GMT) :
>>> On May 8, 2015, at 10:20 AM, intrigeri  wrote:
>>> Source Valley wrote (08 May 2015 16:55:50 GMT) :
 There are countless example I can think of where one might need a truly 
 random mac
 changer, here is just one example: If I'm sitting in a coffee shop and I'm 
 the only
 one with a Unique first 3 octet wifi card, then it wouldn't be too 
 difficult to
 reveal who I am.
>>>
>>> I don't understand. May you please clarify?
> 
>> I assume this is the usual issue that someone observing the network can look 
>> up an OUI, here for example:
> 
>> https://www.wireshark.org/tools/oui-lookup.html
> 
>> and if it turns out to be distinctive— for example, used only in certain 
>> Dell-branded
>> laptops— it could potentially identify the user if he or she is the only 
>> user with
>> such a machine in the coffee shop at that moment.
> 
> OK, I see. In such contexts, I don't think it matters much what exact
> bits of the MAC address we modify, as long as we spoof the MAC address
> exactly once per session: the timing of connection/disconnection is
> probably enough to correlate a given MAC address with a physical body
> with a quite good success rate: the MAC address that suddenly appears
> on the LAN when $PERSON shows up, takes $COMPUTER of a bag and turns
> it on, and suddenly disappears when $COMPUTER is put back into a bag
> and $PERSON leaves, is very likely to be $COMPUTER's MAC address, and
> the network traffic from that MAC address is very likely $PERSON's
> network traffic.

Exactly. However, having a NIC with a rare OUI is a serious problem in
other ways if the attacker takes that in consideration (i.e. treats that
OUI as unique in some geographical region, which may be reasonable in
some cases I suppose).

Just to further elaborate why randomly picking between OUI:s (or
(worse!) completely randomizing the vendor bytes) isn't so simple to do
in a safe manner, look at this part of the design document:

https://tails.boum.org/contribute/design/MAC_address/#index12h2

Those conclusions are not set in stone, feel free to attempt to change
our minds! :)

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] [review'n'merge:1.4] bugfix/8891-iso-image-padding

[anonym]

On 05/07/2015 09:50 PM, intrigeri wrote:
> Hi,
> 
> please merge this branch into testing and devel, so that our ISO boots
> on VirtualBox even in the cases when isohybrid makes it so its size is
> not a multiple of 2048 bytes.
> 
> anonym: please note that I've added a few commits on top of your
> original implementation, so that we get more info to report upstream
> whenever we need.

Merged!

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] review and merge bugfix/9327-disable-starttls-warnings

[anonym]

On 05/07/2015 07:09 PM, sajolida wrote:
> intrigeri:
>> Hi,
>>
>> sajolida wrote (05 May 2015 16:54:28 GMT) :
>>> Ticket: #9327 - Claws and Tor shouldn't warn on StartTLS connections to
>>> port 110 (POP3) and 143 (IMAP)
>>> Branch: bugfix/9327-disable-starttls-warnings into testing
>>
>> I'm all for it. Code review passes, not tested. IMO this requires
>> a design doc update, though.
> 
> Done in 7f7b804.

All looks goo to me now, and my tests with `torsocks nc mail.riseup.net
110` (and 143) worked as expected in 1.3.2 (warning) and an image built
from the branch (no warning). Merged!

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] [review'n'merge:1.4] feature/9340-Linux-from-Stretch

[anonym]

On 05/05/2015 09:52 AM, intrigeri wrote:
> Hi,
> 
> as explained on #9340, without this change, our build system will very
> soon start producing unbootable ISO images. Please merge into stable,
> testing, devel and feature/jessie.
> 
> Filed #9341 for the next steps (once Linux 4.0 migrates to Debian
> testing).

Merged!

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.