[Tails-dev] Tails 4.0 (Buster) release date & branches

[intrigeri]

Hi,

segfault and I met today; we looked at the candidate release blockers
for 4.0 and it turns out there's no real blocker. At this point, it
looks very much like our devel branch (based on Buster) fixes more
problems than it brings regression.

So there's no reason to delay this announcement anymore:
we'll release 4.0 on October 22, woohoo!

I'll send a release schedule shortly.

Thanks to everyone who helped port Tails to Debian 10 (Buster)
in any way :)

Until 4.0 is out, there's no big change to how our branches are used:

 - master is for our live website; it's still based on Stretch

 - stable is for critical bugfixes & security fixes that should be
   part of a 3.16.x emergency release, if we have to publish one;
   it's still based on Stretch

 - devel is for anything else

 - testing is currently unused; it'll be open once we freeze our code
   base for 4.0, when we prepare 4.0~rc1

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] Scheduled CI maintenance: September 19-22

[intrigeri]

Hi,

on September 19-22, the sysadmin team will be upgrading our Jenkins
(#10068). Don't count on CI during these days. We'll let you know once
things are supposed to be back into working shape.

Thanks in advance for your patience :)

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] boot tails iso with grub

[intrigeri]

Hi,

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

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

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

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Tails vs Electrum

[intrigeri]

Hi,

s7r:
> It would be neat to get some help - I have tried unsuccessfully reaching
> to the debian cryptocoin team as well as some package maintainers that I
> saw maintain packages related to this area, but nothing. I am still
> expecting an answer from two more people, hope to get them in the next days.

> But if not,
> If there is someone in the Tails Foundation Team that can help with
> Debian packaging, just point him in my direction and we can sponsor
> this.

Thanks for the prompt feedback!

Can you please:

1. Let me know once you've received these answers (or given up on
   waiting for them), "in the next days" as you said.

2. Send me (privately if that's more appropriate) the conclusion of
   these conversations: I don't want us to nag the same folks with the
   same questions you've already asked them.

And then, I'll happily organize the next steps to resolve this with
our Foundations Team :)

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Randomness blueprint

[intrigeri]

Hi,

intrigeri:
> Jurre:
>> Some of us have been working on creating a blueprint discussing certains 
>> questions related to randomness in Tails.

> FTR it looks like:

>  - The blueprint needs an update to take #15292 into account.

>  - The current status on #11897 is "We still have to discuss this".

> So I don't think this blueprint currently has an up-to-date proposal
> that's ready to be reviewed or discussed. If I got it wrong, please
> let me know :)

A year later, I've updated that blueprint¹. Main changes:

 - Correctly reflect the currently supported methods for installing
   and running Tails.

 - Mention the solutions that kurono and segfault have been
   working on.

 - Mark as obsolete a proposed solution that was superseded by
   a better one for which we have actual code.

It made me realize that we've gotten somewhat stuck in a process that
has become obsolete. The initial goal of #11898 + this ticket + this
thread was to generate a document and proposals that we could get
audited by knowledgeable folks. I believe that's because back then, we
envisioned a novel, Tails-specific solution. But it turns out that we
don't really need to invent any wheel here: kurono and segfault wrote
code that demonstrates we have two ways to simply implement what's
commonly accepted as best practice (i.e. what most other operating
systems do): #11897.

Some implementation details differ (e.g. where exactly the persistent
seed is stored) but that's not particularly relevant from a security
design standpoint, and I don't think the original goal of this process
is still relevant: at this point, I don't really see what we would
need to ask the crypto community. I'm going to update Redmine so it
reflects my understanding of where we're at now.

If I got any of this wrong, I'll be happy to stand corrected.

I expect we'll reuse quite some bits of the blueprint when updating
the design doc for #11897, so thanks a lot to everyone who did the
research and the writing!

And it'll still be useful if we can get skilled folks to review the
actual implementation: a well established security design can be
erroneously implemented.

[1] https://tails.boum.org/blueprint/randomness_seeding/

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Tails vs Electrum

[intrigeri]

Hi s7r,

intrigeri:
> s7r wrote:
>>> Option B: find co-maintainers for the Debian package
>>> 
>>> 
>>> We have the skills at Tails to become co-maintainers but if there's
>>> a way to find some other co-maintainers, it would be sweet. Ideally we
>>> would not have to be part of it but worst case we can, at least for
>>> a while.
>>> 
>>> s7r, how about you ask the Debian Cryptocoin Team¹ if they want to
>>> co-maintain Electrum with mithrandi and/or with some Tails folks,
>>> under the umbrella of their team?
>>> 
>>> [1] 
>>> https://qa.debian.org/developer.php?email=team%2Bcryptocoin%40tracker.debian.org

>> I have sent some emails, but I have to admit I didn't have time to stay
>> quite on top of this. I plan to further discuss it and look for solutions.

> Great!

> Any progress on this front? Could you please point me to the
> corresponding mailing list thread?

> (And if you only did private email so far, I suggest you switch to
> using that team's public mailing list in the future, which fits the
> Debian culture better and has thus more chances to work :)

> Please Cc me further communication with the Debian Cryptocoin team, if
> you don't mind. It'll help me assess whether, and how much, we as
> Tails need to invest into co-maintaining the package.

Any news?
What kind of timeline do you have in mind for the next steps?

If it's not realistic that you find time for this soon,
maybe the Tails Foundations Team could take over this communication.

Meanwhile, I see no recent activity in the packaging repo¹; and the
current maintainer seems to be still MIA².

[1] https://salsa.debian.org/cryptocoin-team/electrum/activity
[2] https://contributors.debian.org/contributor/mithrandi@debian/

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [Tails-news] Call for testing: 4.0~beta1

[intrigeri]

Hi,

> We will provide security upgrades for Tails 4.0~beta1 like we do for
> regular versions of Tails.

We'll be doing all this extra work so that Tails contributors and
enthusiasts can switch to 4.0~betaN for real world production use
cases. This will help us identify the most important issues so we can
fix them before we release 4.0 final. It worked very well for 3.0.

So: please consider upgrading the Tails systems you use daily to
4.0~beta1! :)

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] Testing & devel branches now target Debian 10 aka. Buster

[intrigeri]

Hi,

anonym and I decided yesterday to merge feature/buster into devel;
then, building on top of that, anonym merged devel into testing
and froze it to prepare 4.0~beta1.

Our next release (3.16), scheduled for September 3, will be a bugfix
one and based on Debian 9 (Stretch).

The next one, scheduled for October 22, may be:

 - either a bugfix one (3.17) based on Stretch;

 - or a major one (4.0) based on Buster.

So from now on:

 - Work targeted at Tails 3.x must be based on the stable branch.

   This includes mostly not-too-invasive bug fixes.

   Work towards installing Tor Browser 9.0 (based on Firefox 68 ESR)
   must be based on stable too, because it will be included in 3.17 if
   we ever publish that release.

 - Work targeted at Tails 4.x must be based on the devel branch,
   except important bug fixes during a freeze, that must be based on
   the testing branch.

   This includes anything that does not satisfy the criteria for 3.x:
   new features, invasive or somewhat risky changes, and also anything
   whose implementation would differ substantially between Stretch and
   Buster (let's avoid having to forward-port stuff at this point).

If anything is unclear, please ask :)

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Working group to define the "core Tails system" (#16531)

[intrigeri]

Hi,

intrigeri:
> So I thought we could try this:

> 1. Create a working group of a few people who are interested in this
>topic and want to be involved in every step of this process.

>→ If you want in, please let me know by the end of July.

I would love if more folks could get involved so I'll happily wait
until mid-September.

> 2. Gather initial input from everyone (not just members of the
>working group)

>→ Feel free to send me, by the end of July, a list of statements
>such as "I think feature X / application Y should be part of the
>core Tails system because $REASONS" or the opposite.

>While doing so, please consider taking our personas into account
>since that's the closest thing we have at the moment to
>collectively defined priorities:
>https://tails.boum.org/contribute/personas/

>I will collect this input. It will help the working group take into
>account diverse point of views right from the beginning.

Same here: you now have until mid-September to share such input.

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Upcoming infrastructure disruption: Puppet master and PuppetDB upgrade (#16460)

[intrigeri]

Hi,

intrigeri:
> We'll let you know when we believe things are back to a stable,
> working state.

We're done and things should be now working as well as they used to.

If there's any regression, please file a ticket in Redmine, assigned
to "Sysadmins". Thanks in advance!

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] Upcoming infrastructure disruption: Puppet master and PuppetDB upgrade (#16460)

[intrigeri]

Hi,

zen and I will attempt to upgrade our Puppet "master" (sic) to Debian
Buster today. This will likely cause some disruption on our
infrastructure now and then. We'll let you know when we believe things
are back to a stable, working state.

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] Working group to define the "core Tails system" (#16531)

[intrigeri]

Hi,

I'm cross-posting widely due to the scope and importance of this
topic, but please reply only to tails-proj...@boum.org or to
me personally.

To subscribe to that mailing list:
https://www.autistici.org/mailman/listinfo/tails-project

Problem statement
=

The Foundations Team¹ is tasked with maintaining the "core Tails
system": we don't have the means to maintain every single feature that
was added in the last 10 years. But we have no definition of what the
"core Tails system" is, which causes trouble:

 - It makes it hard for us to prioritize our work on a day-to-day basis.

 - It makes it hard to tell whether we're focused on problems that
   Tails, as a project, thinks are the most important ones.

Similar problems probably affect other kinds of work, such as UX and
technical writing.

Process
===

This decision will affect where we focus our work and resources so I'd
like the process to allow as many of us as possible to participate
accordingly with their own level of availability & interest.

So I thought we could try this:

1. Create a working group of a few people who are interested in this
   topic and want to be involved in every step of this process.

   → If you want in, please let me know by the end of July.

2. Gather initial input from everyone (not just members of the
   working group)

   → Feel free to send me, by the end of July, a list of statements
   such as "I think feature X / application Y should be part of the
   core Tails system because $REASONS" or the opposite.

   While doing so, please consider taking our personas into account
   since that's the closest thing we have at the moment to
   collectively defined priorities:
   https://tails.boum.org/contribute/personas/

   I will collect this input. It will help the working group take into
   account diverse point of views right from the beginning.

3. The working group does whatever it takes to build a proposal,
   including reasons why feature X and task Y are in but application Z
   is not.

4. Send this proposal to the tails-proj...@boum.org mailing list
   and call for comments.

5. Iterate on #3 and #4 as needed.

6. Eventually reach consensus on a definition.

   It's fine if we did not manage to reach consensus on every single
   feature / application: we'll document as such the ones that are
   left to be decided.

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] mmc and sdhci kernel/initrd support ?

[intrigeri]

Hi,

Insurgo:
> On 7/3/19 4:57 AM, intrigeri wrote:
>> That's probably doable. For avoidance of doubt, is this:
>>
>>   mmc_core
>>   mmc_block
>>   sdhci
>>   sdhci_pci
> Exactly.

Thank you. For those following at home, Insurgo turned this into
a merge request that the Foundations Team will review soon:
https://salsa.debian.org/tails-team/tails/merge_requests/29
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] mmc and sdhci kernel/initrd support ?

[intrigeri]

Hi,

Insurgo:
> TLDR: mmc and sdhci kernel modules are compiled as modules, but not
> included in initrd, so Heads cannot kexec boot Tails verified ISO from
> sdcard by device-uuid, since the device is not recognised under initrd
> to be able to boot the kernel from sdcard mounted iso.

> Can mmc and sdhci modules be included in initrd in the next Tails release?

That's probably doable. For avoidance of doubt, is this:

  mmc_core
  mmc_block
  sdhci
  sdhci_pci

… the exact list of modules you want included?

Would you be interested in trying to contribute this change yourself?

If so, you can submit a merge request on
https://salsa.debian.org/tails-team/tails.

I think the best way to do so is to create a new file based on
config/chroot_local-includes/usr/share/initramfs-tools/hooks/kms.

Other doc you might need:

  https://tails.boum.org/contribute/how/code/
  https://tails.boum.org/contribute/build/

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [review'n'merge] Update French translation team documentation and allow import from Transifex

[intrigeri]

xin:
> Hello, I update the French translation team documentation except the
> part about the documentation, I'm waiting for the weblate workflow
> documentation to do it.
> And we use Transifex again for customs softwares.

> Please review and merge.

Done!
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [announcement] pre-commit hook to validate PO files

[intrigeri]

sajolida:
> .git/hooks/pre-commit: 14: .git/hooks/pre-commit:
> /home/amnesia/Persistent/master/wiki/src/contribute/l10n_tricks/unifyPo:
> not found

Sorry about that.

Fixed on master (00f83d4b971ba14018278a0e3e7e58452bcd524c),
please copy the new version of the hook.

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] [announcement] pre-commit hook to validate PO files

[intrigeri]

Hi,

FWIW there's now a script in ./bin/pre-commit-translation in our main
Git repository, that can be used as a pre-commit hook. It will do some
sanity checks on PO files.

For those of you who regularly modify PO files directly in Git (I
guess that's mostly some translators, tech writers and myself), it
might be useful to set it up as documented in the comments on top of
that file.

Note that the very same checks are run by our CI:

 - Whenever we push to our master branch
 - As part of the test suite we run after building Tails images

… so I feel no need for stronger encouragements nor for documenting
this in the various places where it might be useful (the vast majority
of the target audience for this pre-commit hook will not read such
documentation as they already have their development environment set
up).

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Proposal: Redmine workflow change

[intrigeri]

intrigeri:
> intrigeri:
>> I'll wait (at least) one more week and if there's no strong objection,
>> I'll implement this proposal.

> I'm doing this today. Expect tons of notifications from Redmine.

Done!

Context:
https://lists.autistici.org/message/20190324.103611.7aa3cabe.en.html

Corresponding doc changes: 3a5f3861..3fdce88

I've updated all the Redmine custom queries I had access to. If you
have created custom queries that you've made visible only by yourself,
you may need to update them yourself.

I'll make sure the corresponding CI code updates I've pushed
work fine.
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Proposal: Redmine workflow change

[intrigeri]

intrigeri:
> I'll wait (at least) one more week and if there's no strong objection,
> I'll implement this proposal.

I'm doing this today. Expect tons of notifications from Redmine.
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] Redmine problems

[intrigeri]

Hi,

we've been told a few days ago that the physical machine our Redmine
instance runs on is dying fast. This did cause outages recently and
may cause more in the near future. We're looking into our options to
migrate it away.

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Disabling suspend on lid close? (#11052)

[intrigeri]

Hi,

(a month after I've sent my proposal to reject #11052)

sajolida:
> If those who are fine with the current situation are the vast majority,
> then we might be degrading the experience for most.

Thanks for this detailed analysis (which I agree with). 

Meanwhile, segfault suggested something on #11052: bring back the
behaviour we had before 3.13.2, that is, if the Tails device is
unplugged while the system is sleeping, and still unplugged when the
system is woken up, then emergency shutdown is triggered. It's unclear
how much work that would be but I think it's worth giving it a try and
do it if it turns out to be cheap. And then IMO this would bundle
nicely, as our default settings, with keeping "suspend when closing
the lid" enabled (which would be nice, for all the reasons provided by
sajolida and myself). What do you think?

If we agree on this, I'll reject #11052 and will file a new ticket for
us to implement segfault's suggestion.

> I'm not saying this to discard the idea of giving the choice but to
> contrast it with the potential cost of this choice. Now, we might find a
> different way of giving the choice against cold-boot attacks without
> degrading the experience for busy and distracted users.

(Assuming we have the default behaviour I've described above, which
avoids degrading the experience for busy and distracted users.)

It may be nice to provide a way to somehow tell Tails "I'm going to
close the lid but please don't suspend, because I want to keep the
system up and able to trigger emergency shutdown if I unplug the Tails
device". I see that as a new feature request with a tiny target user
base, so to be honest, even if someone showed up and was ready to do
the coding work, regrettably I suspect it would require more UX/design
work and reviewing resources from us than it's worth, so I'm not sure
how to handle this.

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Macbook Keyboard and Touchpad Solution with the SPI driver

[intrigeri]

Hi,

Never Nada:
> I think Tails should consider adding this Apple SPI Linux driver that is used 
> by many people already:
> https://github.com/cb22/macbook12-spi-driver/

Yep, see https://redmine.tails.boum.org/code/issues/15652 that
I updated the last time I looked into this.

> This solution works so well now that it will be added to the [Linux
> kernel](https://www.phoronix.com/scan.php?page=news_item&px=Linux-Finally-MBP-Key-Touchpad)
>  soon.

This is great news, I'm glad this driver was finally submitted
upstream! I see the reviewers of the initially submitted patch series
requested changes and the driver is not in Linus' tree yet.

> But waiting for Debian to have this in the kernel could take more
> than a year.

FYI this is incorrect: Tails generally ships the kernel from Debian
sid, which does not lag much vs. Linux mainline, and generally enables
such hardware support quickly upon request.

Right now is special though (due to the Buster freeze). We'll probably
stick to 4.19 for a little while more though, so we should get
whatever Linux 5.x is current in our October or December release.

> Can this driver be added to Tails?

Given we'll get the real fix for free soon, I don't think it's worth
investing our limited resources into a temporary solution (especially
one that depends on third-party code and that probably won't work with
Secure Boot).

But if someone was ready to do the work, we would consider a good
quality patch: see #15652 :)

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Fwd: Privacy Matters – Add-ons for Firefox (en-US)

[intrigeri]

Hi,

🍁CMCC-CCCM⚜:
> From: 
> Date: Mon, May 20, 2019 at 7:29 AM

> […] we try
> to stick to Tor browser default as long as possible to have a similar
> fingerprint on the web.

Exactly (except uBlock Origin).

>> I also like to suggest you include the following add-ons for security and
>> privacy purpose:
>>
>>- Adblock Plus
>><https://addons.mozilla.org/en-US/firefox/addon/adblock-plus/> OR
> uBlock
>>Origin <https://addons.mozilla.org/en-US/firefox/addon/ublock-origin/>

FYI, we do ship uBlock Origin.

As for the rest, this looks like a raw list of privacy-related
add-ons; I'm afraid this is not a strong enough case as-is. In order
to convince Tor Browser upstream that they should ship one of those,
one should first have a good read and understanding of their design
goals and means:

  https://2019.www.torproject.org/projects/torbrowser/design/

… and then argue, in this context, what threats including this
specific add-on would protect against, what the drawbacks are, and why
it's worth it anyway.

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [review'n'merge] Missing word in 3.14 news

[intrigeri]

xin:
> Hello, please review and merge.

> Repo: https://git-tails.immerda.ch/xin/tails/
> Branch: missing_word_3.14_news
> Last Commit: eeef956c75a666bdb7cff6e79fc6a6e7ae027dee

Thanks, good catch!

I took the liberty to merge this, even if it's not my turf, because
I know sajolida has been busy elsewhere and the longer we wait,
the less value this fix has.

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Update glibc

[intrigeri]

Hi Aria,

Aria Fathi:
> Im trying to use some wallets on a USB Stick Tails OS but I get the error I
> attached. The wallets are compiled on Ubuntu 18.04 or later I guess.

Tails is currently based on Debian Stretch, which ships glibc 2.24, so
indeed these symbols are undefined.

> Please update libraries.

That's not feasible for Tails 3.x but this problem will be fixed in
Tails 4.0, based on Debian Buster. Meanwhile, you could suggest
whoever provides this binary to compile it with less strict versioned
dependencies requirements, which they should do anyway if they care
about systems other than Ubuntu 18.04.

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [Default search engine] DuckDuckGo

[intrigeri]

Hi Jean,

Jean Dupont:
> However, I don't understand why Tails doesn't use the default .onion
> version of duckduckgo?

Please see the last iteration of this discussion:
https://redmine.tails.boum.org/code/issues/12121#note-5

Cheers!
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] default package suggestion

[intrigeri]

Hi Matt,

Matt Gensler:
> I am writing to recommend that the package gnome-tweak-tool be installed by
> default in the Tails operating system. It includes some useful system
> settings that not available in the standard system settings GUI. For me
> personally, I really like the fact that it allows me to turn off the
> suspend when lid is closed action that is the default for laptops.

FTR here's the ticket where we decided to remove gnome-tweak-tool
3 years ago: https://redmine.tails.boum.org/code/issues/11237

Let's keep in mind that GNOME Tweaks is a GUI frontend for gsettings.
Any setting one can change in GNOME Tweaks can also be set on the
command line with gsettings. I suspect that the vast majority of Tails
users who care so much about one of these settings, that they really
want to change it from the default, are in one of these categories:

 - Either they're technical enough to do it on the command line.

 - Or they don't mind adding gnome-tweak-tool to their Additional
   Software (which is nicely integrated in the UX of installing
   a package nowadays).

And I suspect that the vast majority of our users would not use GNOME
Tweaks anyway. So at this point, I see no strong reason to re-add
GNOME Tweaks.

> Thanks for your continuing work on Tails!

Thanks for your feedback!

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] Upcoming release: 3.13.2

[intrigeri]

Hi,

we're trying to publish an emergency release that fixes #16694 aka.
"armagadd-on 2.0". It's not clear yet who'll do which part of the
RM'ing work nor when exactly we'll be ready to test it, but let's
assume for now that the manual test suite will happen at some point
tomorrow.

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [review'n'merge] typo on unlock_veracrypt_volumes

[intrigeri]

segfault:
> […] yes, I'm on it.
> I created one now: https://redmine.tails.boum.org/code/issues/16696

Woohoo \o/
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Firejail for unsafe browser and SSR screen recorder

[intrigeri]

Hi,

Daniel Kahn Gillmor:
> On Fri 2019-05-03 12:45:17 +0200, intrigeri wrote:
>> When we switch to Wayland (#12213) we'll need to change the way we run
>> the Unsafe Browser. In particular, we won't be able to run it under
>> a dedicated user anymore.

> this seems problematic to me.  dedicated user accounts are one of the
> simplest, most reliable process isolation mechanisms in unix. 

I agree for non-GUI apps. But for GUI apps running on X11 (and
probably on Xwayland), they can trivially escape that sandbox; and
reciprocally, other apps can easily interact with the "sandboxed" one.
So I think this isolation mechanism, that's being obsoleted here, has
always been extremely weak in this context. I won't regret it much:
the usual design patterns to replace it provide much better security.

> I scanned
> https://redmine.tails.boum.org/code/issues/12213 briefly but didn't see
> any mention of a bug report/feature request to the wayland developers
> about this gap, other than this FAQ:

> 
> https://fedoraproject.org/wiki/Common_F25_bugs#Running_graphical_apps_with_root_privileges_.28e.g._gparted.29_does_not_work_on_Wayland

> (which seems like it's more about not wanting to leak root privs, not
> about dedicated non-priv users)

(Disclaimer: I didn't study this sort of things recently and don't
remember the details.)

All the cases where we run a GUI app under a dedicated UID in Tails
are there primarily in order to give that specific app some privileges
that the desktop user ("amnesia") should not directly have, for
example applying an upgrade or accessing the Internet without going
through Tor. So I believe the same reasoning as for running GUI apps
as root applies here as well.

Granted, in the Unsafe Browser case, ideally we also want to give it
a limited view of the filesystem, i.e. restrict its privileges, just
like we do with AppArmor for some apps, but that's a nice bonus
feature rather than a strict design requirement.

> i think this would be worth raising with Wayland upstream if it hasn't
> been raised already, pointing out that there are good security reasons
> to want to run applications under user isolation.

Possibly. Given we don't particularly need/use that
privilege-restricting isolation in Tails, I won't invest time into
this. It is my understanding that the active community around Wayland
has made a strong commitment to namespace-based isolation solutions
(e.g. bubblewrap), that have lots of interesting features which
UID-based isolation lacks, so honestly I would not expect them to care
much about UID-based isolation.

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Tails vs Electrum

[intrigeri]

Hi,

sajolida:
> In terms of documentation:

> - We've had an unusable version of Electrum in Tails for 1.5 month and,
>   if we can't make it usable again, we should consider removing it at
>   some point, independently of the Debian status of the package. Please
>   let me know if we reach a point where we should remove it and I'll
>   update the doc.

Depending on how fast the discussions s7r started with potential
Debian co-maintainers go, it might be realistic to ship a fixed
version of Electrum in our 2019-07-09 release. So perhaps it's
not worth the effort to remove it just yet.

> - I'm still ready to build up on s7r's tutorial and explain how to run
>   the AppImage in Tails for advanced users as I offered in the opening
>   post of this thread.

It could be a waste of effort if we manage to fix the problem
properly soon.

In any cane, it's not clear to me that this is something we should
support, recommend, or even suggest: while it's safer for some users
than the alternative (using that AppImage outside of Tails), for most
users it exposes their other Tails data and activity to additional
risks. I would be fine with something along the lines of "if you use
Tails *only* for Electrum, fine, go for it; otherwise, please be
patient".

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Firejail for unsafe browser and SSR screen recorder

[intrigeri]

Hi,

jg30--- via Tails-dev:
> So I had an idea that maybe we could incorporate the Firejail sandboxing 
> program to the unsafe web browser.

When we switch to Wayland (#12213) we'll need to change the way we run
the Unsafe Browser. In particular, we won't be able to run it under
a dedicated user anymore. So indeed, we'll need to look for other
options that allow us to configure specific nameserver and firewall
rules for this app. I'd love to see a prototype that uses Firejail
or similar technologies to do this :)

One thing we want to fix at the same time: making the Unsafe Browser
accessible (#7502).

> I looked at the applications that Tails comes with and saw that there 
> really was no screen recorder in there.

GNOME supports this natively:
https://wiki.gnome.org/Projects/GnomeShell/CheatSheet#Screencast_recording

Note that most other screen recording software are incompatible with
Wayland by design. I don't know what's the status of the Wayland APIs
and GNOME implementation to allow external screen recorders to request
permission from the user to record the screen.

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Persistent storage creation accessibility issues with Orca

[intrigeri]

Hi again Cory,

Cory Samaha:
> I assume without being able to access the persistent storage
> features, there is no other way to store PGP keys - perhaps the most
> important thing I was hoping to do.

You could:

 - Either get help once to create the persistent volume. Once created,
   it should be usable with Orca.

 - Or create an encrypted storage volume with GNOME Disks, store
   OpenPGP keys there, and copy the corresponding folder to
   /home/amnesia every time you start Tails. I understand that
   very inconvenient.

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Persistent storage creation accessibility issues with Orca

[intrigeri]

Hi Cory,

sorry for the delay…

Cory Samaha:
> I emailed the Orca screen reader list today with a query regarding
> the accessibility of the persistent storage volume creation tool.
> While I do see a bug that seems somewhat related on Redmine Bug
> #7503, it seems that this only refers to error messages.
> In contrast, I couldn’t get any portion of this tool to read with
> Orca, never mind the error messages.

Thanks for your report. I've updated our #7503 ticket so it now
reflects better the status quo. It's not easy to solve but we plan to
fix this next year, as part of porting Tails to Wayland.

> Also, while we are on the subject of Tails accessibility with Orca,
> I tried to use the auto update tool (I believe called senity) to
> update from 3.12 to 3.12.1.  Unfortunately, this tool does not seem
> to read either.

Thanks again. I've reported this as #16685, which we'll fix at the
same time as the other problem.

>  When trying to subvert the GUI and run
>  tails-upgrade-frontend-wrapper from terminal, I did get
>  a notification that an update was available, immediately followed
>  by the text **WARNING **: Couldn't connect to accessibility bus.
>  While it seemed that I could type “Upgrade now" or “Upgrade later”,
>  it dumped me back into the graphical interface which, again, does
>  not read with Orca.

Indeed, there's no way to interact with the Upgrader in a terminal :(

> I’m just trying to figure out if this is an issue with Orca or the
> way Tails is developed

It's due to poor design decisions I made while developing some parts
of Tails years ago.

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Kloak and Keyboard Biometrics

[intrigeri]

Hi Justin,

Justin McAfee:
> Regardless, I have been reading white papers on styleography and keystroke
> biometrics and have found a fairly elegant solution from vmonaco's github
> page.

> Would like to propose that we include the "kloak" program as a feature in
> the next Tails release. This software assists in combating keystoke
> biometrics by inserting brief (100-200ms) delays between keystrokes, faking
> out matching algorithms.

Thank you for this suggestion. This project¹ seems pretty serious and
points to actual research (that I didn't read yet). That's confidence
inspiring. We'll need to discuss about the usability trade-off though.
May you please get back to us once this project is not marked as
experimental anymore and the most severe issues (e.g. #12²) are fixed?

[1] https://github.com/vmonaco/kloak
[2] https://github.com/vmonaco/kloak/issues/12

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] Disabling suspend on lid close? (#11502)

[intrigeri]

Hi,

status quo is:

 - Tails suspends (to RAM) on lid close.

 - Until Tails 3.13.1 (inclusive), the only user-friendly way to
   suspend the system was to close the lid. This will be fixed in
   Tails 3.14, that will display a button in the status menu to
   suspend the system.

 - Until Tails 3.13.1, on some systems, Tails would trigger its
   emergency shutdown procedure when resuming from suspend.
   This will be fixed in Tails 3.14.

Now, some years ago, we decided to disable the "suspend on lid close"
behaviour and to display a button to suspend, for two reasons:

1. Coming back from suspend breaks sometimes on some hardware.

   → We've had suspend-on-lid-close enabled for years and this was
   reported only once, 3 years ago. I doubt it's a widespread problem.

2. While the system is suspended, one cannot trigger the emergency
   shutdown procedure simply by unplugging the boot medium. The user
   has to first wake up the system, for example by opening the lid,
   before unplugging the boot medium. This might violate some
   users' expectations.

   → Now that we added a suspend button, as decided during the very
   same discussion as the one that decided to disable "suspend on lid
   close", we're exposing more users to the exact same threat. I don't
   understand why it's more problematic to do so on lid close than
   when suspending via that newly added button.

IMO we should stick to the default, well-known behaviour, of
suspending on lid close, and reject #11052.

Can any of you remember/think about strong reasons to deviate from the
defaults here?

If you feel like diving into the archaeological details:

 - https://redmine.tails.boum.org/code/issues/11052 and the related tickets
 - https://tails.boum.org/contribute/meetings/201605/

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [review'n'merge] typo on unlock_veracrypt_volumes

[intrigeri]

Hi,

sajolida:
> I've seen no answer to your email on tails-dev.

> Foundations Team, should this be part of your mission? as per:
> « reviewing code contributions that are on nobody else's plate [...] »

It definitely is part of our job. segfault asked me for guidance
a couple weeks ago wrt. how to handle this and I replies. I suspect
this fell through the cracks since. segfault, are you still on it?

(As we can see, email is slightly suboptimal to track such things.)

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Tails vs Electrum

[intrigeri]

Hi s7r,

s7r wrote:
> intrigeri wrote:

>> Option A: use a trusted onion server and keep 3.1.3-1~bpo9+1 for now
>> 

Update: Tails 3.14 should ship Electrum 3.2.3-1 from sid. That won't
help it connect to the network but at least we upgrade to the newest
version that's in Debian, which is the best we can do.

>> If that's sufficient to fix the most critical issues on the short
>> term, then we need to know: […]

Thanks a lot for your comprehensive answer!

> I run 2 (two) .onion servers, accessible via v3 onion hostnames (new
> generation onion services). They run on own hardware and have plenty of
> resources and bandwidth so, they should be reliable. But the situation
> gets complicated because the servers can be abused (DOSed) by clients at
> application level (ask expensive historic data for addresses that
> consume high CPU and disk I/O resources) and make the server
> unavailable. […]

So I understand that basically, as of today, we would trade "Electrum
in Tails can't connect to the network most of the time because we run
a deprecated client version" (the current situation) for "Electrum can
use the configured trusted Onion server only when it's not DoS'ed".

I guess this would be a usability improvement but it does not seem
sufficient to make Electrum in Tails really usable.

> If we decide to do this, it means users MUST have a higher level of
> trust in this server, rather than any public Electrum server. […]

The risk×impact does not seem too bad to me. At least, not enough
to be a blocker in itself.

So all in all, my current take on option A is: at least as long as the
DoS issue is that severe, this option doesn't seem to provide enough
usability benefits to be worth doing the work and taking the security
hit. And we're thus left with option B:

>> Option B: find co-maintainers for the Debian package
>> 
>> 
>> We have the skills at Tails to become co-maintainers but if there's
>> a way to find some other co-maintainers, it would be sweet. Ideally we
>> would not have to be part of it but worst case we can, at least for
>> a while.
>> 
>> s7r, how about you ask the Debian Cryptocoin Team¹ if they want to
>> co-maintain Electrum with mithrandi and/or with some Tails folks,
>> under the umbrella of their team?
>> 
>> [1] 
>> https://qa.debian.org/developer.php?email=team%2Bcryptocoin%40tracker.debian.org

> I have sent some emails, but I have to admit I didn't have time to stay
> quite on top of this. I plan to further discuss it and look for solutions.

Great!

Any progress on this front? Could you please point me to the
corresponding mailing list thread?

(And if you only did private email so far, I suggest you switch to
using that team's public mailing list in the future, which fits the
Debian culture better and has thus more chances to work :)

Please Cc me further communication with the Debian Cryptocoin team, if
you don't mind. It'll help me assess whether, and how much, we as
Tails need to invest into co-maintaining the package.

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Tails→Buster: status update

[intrigeri]

Hi,

intrigeri:
>  - We'll have two remote sprints focused on Buster: one in May and
>another one in June. You'll all be invited to participate!

You may now save the dates:

 - 2019-05-23 and 2019-05-24

 - 2019-06-17 and 2019-06-18

We'll need folks to:

 - try nightly builds and provide feedback

 - go through our documentation and identify what needs updating
   (incidentally, this process usually spots quite a few regressions)

 - fix code regressions

We'll coordinate mostly on the tails-dev XMPP channel.

I hope to see you there :)

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Security implications: moving code from Verification Extension to our website

[intrigeri]

Hi,

u:
> On 16.04.19 14:29, intrigeri wrote:

>> One rather minor implementation note, that's relevant in this context
>> only because any software is only as secure as the _version run by
>> actual users_: this migration increases the need to ensure web
>> browsers use the correct version of the relevant web resources (such
>> as JavaScript files), to replace the extension version check we
>> currently have, which is done for every download. At the moment JS can
>> be cached for 24h. We have a ticket about this already; I think it
>> needs to be part of the migration plan.

> I don't think this increases this need: it's still the same as it is
> now, as the Installation Assistant already uses Javascript files hosted
> on the server.

Fair point, a component of the big picture is already subject to this
problem, so perhaps having even more code subject to this problem does
not change anything substantially. I don't know and I don't feel
competent to analyze the consequences of this further myself. The best
I can do is to clarify some technical details that might be useful to
whoever wants to dig deeper. So, this proposal replaces:

A. code, that currently lives in the current extension, and does its
   own version checking independently of JS caching policy: it only
   relies on data it gets from a HTML page that should not be cached
   by browsers

with:

B. code that can be retrieved from the browser cache

And in both cases, as Ulrike mentioned, there's another piece of
cooperating JS code, that lives on our website and can already be
retrieved from the browser cache.

> Is the ticket you are talking about this one:
> https://redmine.tails.boum.org/code/issues/16091? (It's about CSS, not
> JS, but I suspect the exact same issue applies.)

Yes. I've just made it more generic :)

Cheers!
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Security implications: moving code from Verification Extension to our website

[intrigeri]

Hi,

jvoisin:
>> General security implications
>> -
>> 
>> The question we are asking ourselves is: are there any predictable
>> downsides to move the verification code from an extension to the website?

> I don't see any significant downsides.

I could not find any either, as long as the threat called [H] in the
design doc of the current system can be mitigated, either in the same
way as what we currently do (see Cross-origin communication and
Content Security Policy paragraphs) or in other ways.

One rather minor implementation note, that's relevant in this context
only because any software is only as secure as the _version run by
actual users_: this migration increases the need to ensure web
browsers use the correct version of the relevant web resources (such
as JavaScript files), to replace the extension version check we
currently have, which is done for every download. At the moment JS can
be cached for 24h. We have a ticket about this already; I think it
needs to be part of the migration plan.

> I think that having the verification happening on the website will
> vastly improve the user experience and is a great idea.

+1

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Proposal: Redmine workflow change

[intrigeri]

Hi,

I'll wait (at least) one more week and if there's no strong objection,
I'll implement this proposal.

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Proposal: Redmine workflow change

[intrigeri]

Hi,

anonym:
> intrigeri:
>> Given we now have "mentions" (@nickname) on our Redmine, for the
>> majority of cases, when the requested info can presumably be provided
>> cheaply and quickly, I think we should use mentions and not reassign
>> the ticket. And when I'm mentioned, if I realize that providing the
>> requested info needs will take me great amounts of work, I should
>> do whatever works for me to track this work, be it on a new ticket
>> or my personal offline organization tools.

> I quite like this feature and have set up filter rules in my email
> client for the resulting redmine notifications I receive so I don't
> miss them. However, I wonder how this works out if you don't do
> something like that. I also fear that the ad hoc tracking of
> "mentions" that you propose above is easy to forget.

I think most of us are in one of these 4 situations:

 - They notice and track new incoming emails but don't pay much
   attention to tickets reassigned to them on Redmine (note that
   Redmine sends no notification to the new assignee).

   Mentions help. Reassigning does not help (I've seen quite a few
   cases recently where it appears that the new assignee had no idea
   something was expected from them).

   So dropping "Info Needed" is a no-op.

 - They regularly look at their Redmine plate but they won't notice
   incoming email Redmine sends them, unless they set up
   ad-hoc filters.

   Mentions don't help. Reassigning or creating a new subtasks helps.

   So dropping "Info Needed" + reassignment brings a regression.
   To mitigate this:

- We should strongly recommend these folks set up whatever
  filters they need to notice email our Redmine is sending them.
- Creating a dedicated subtask for the info request is an option
  in some cases (I'll discuss this below).
- To address the root cause of the problem and make email
  a communication option that actually works, we should gently
  suggest these folks to unsubscribe from sources of incoming
  email that they don't read, and that swamps them in an inbox
  they barely dare looking at. I guess that's part of self-care
  recommendations we could promote more visibly within Tails :)

 - They pay attention to their Redmine plate and to incoming email.

   All's well, no change here.

 - They don't pay much attention to their Redmine plate and don't
   notice incoming email from Redmine.

   No change here. No ticket tracking system will help. Only social
   processes, such as regular team meetings, have a chance to enable
   successful collaboration & communication.

> I just had a half-baked idea that might have some merit: say I work
> on ticket X and need info about "foo" from intrigeri. Then I just
> create a subticket Y of X called "Info needed: foo" and assign it to
> intri. When intri has posted the information about "foo" to X he can
> then mark Y as resolved.

That's surely a valid option in some cases, mainly: 1) when the
overhead of "just" creating a subtask is justified by the amount of
work needed to fulfil the info request; 2) for those of us who can't
afford paying attention to email Redmine sends them. I don't know how
much of our "Info Needed" usage fits into this category. I want to
keep this option in mind even though I'd rather first tackle the root
cause of the problem, because for (2) this option feels like
a workaround.

Cheers!
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Proposal: Redmine workflow change

[intrigeri]

sajolida:
> intrigeri:
>> So I propose that we drop the "QA Check" field and instead, introduce
>> a "Needs Validation" status.

> Good idea! Works for me.

:)

> What would happen to tickets that go back-and-forth between the main
> author and the reviewer? Would they stay in "Needs Validation" or go
> back-and-forth between "In Progress" and "Needs Validation"?

The latter, as per:

  And if the reviewer requests changes, they would set the status
  back to "In Progress".

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Status of tails reproducible builds?

[intrigeri]

Hi,

node.ad...@secmail.pro:
> What status is it for the reproducible builds?

I'm glad you're asking.
Tails images have been reproducible for a while.

Here's how to:

1. Build an image: https://tails.boum.org/contribute/build/

2. Verify that it matches what we've published:
   https://tails.boum.org/contribute/build/reproducible/#verify-iso

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Tails→Buster: status update

[intrigeri]

Hi,

last week, the Foundations Team and our special guest Alan had
a sprint focused on porting Tails to Debian 10 (Buster).

What we did was mostly:

 - update the test suite: good WIP that lead to identifying
   regressions for which tickets were filed; we're almost there!

 - fix regressions identified by the automated test suite and manual
   test suite; this resulted in quite some work on the Debian side
   (uploads, unblock requests, merge requests, bug reports)

 - set up a workflow that allows our team to use merge requests
   on Salsa (Debian's GitLab)

 - provided guidance and proposals on the Electrum front

 - learned how to build GNOME Shell from upstream Git and documented it

 - rethought our team's task management in depth, documented new
   guidelines and implemented them:
   
https://tails.boum.org/contribute/working_together/roles/foundations_team/#tasks-management

The blockers we know about for releasing Tails 4.0 are tickets
with priority normal or higher on:

   https://redmine.tails.boum.org/code/projects/tails/issues?query_id=279

Next steps:

 - The Tails community can try nightly builds and provide feedback:
   
https://nightly.tails.boum.org/build_Tails_ISO_feature-buster/lastSuccessful/archive/build-artifacts/
   In particular, testing our Buster images on various hardware would
   be very valuable. We'll probably send a public call for
   testing soonish.

 - Technical writers can start updating the doc whenever they see fit.
   No doubt they will identify some regressions along the way :)

 - We'll have two remote sprints focused on Buster: one in May and
   another one in June. You'll all be invited to participate!

 - We still hope that on 2019-07-09 or shortly after, we can release
   a 4.0~betaN and commit to provide automatic upgrades and security
   support until 4.0 final is out

 - We'll schedule a sprint in September to finalize 4.0 and the
   integration of Tor Browser 9.0.

 - Our current best bet for releasing Tails 4.0 final is 2019-10-22.

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Tails vs Electrum

[intrigeri]

Hi,

first, thanks a lot to everyone who contributed to this thread!

s7r:
> mithrandi is of course interested into continuing to maintain Electrum
> in Debian and will do so, but we should find other people also to work
> as a team so he doesn't become the single point of failure, like it
> happened this time.

Sounds good. I'm elaborating on this below (option B).

> Unfortunately, I personally don't know how to do it
> all by myself, but I'm willing to help with monetary payments for the
> hours spent on this as well as donate testing infrastructure.

This is good to know. If we go this way in the end, I think we'll
greatly appreciate any kind of support you can provide :)

I've just had a meeting with 2 of my Foundations Team colleagues
(hefee & segfault), aiming at providing input regarding the available
options, guidance regarding the next steps, and information regarding
what the Tails Foundations Team feels we could do on our side.
Only the first two options below (A and B) seem doable.

Option A: use a trusted onion server and keep 3.1.3-1~bpo9+1 for now


If that's sufficient to fix the most critical issues on the short
term, then we need to know:

 - Are there such servers available? Are they reliable enough
   for Tails? What configuration change do we need to do to use them?

   I'm not sure I understood this comment right:
   https://redmine.tails.boum.org/code/issues/16564#note-10

 - How much do we need to trust this server? (Ideally, we need
   pointers to some authoritative document, rather than claims made by
   the very person who runs this server :)

Option B: find co-maintainers for the Debian package


We have the skills at Tails to become co-maintainers but if there's
a way to find some other co-maintainers, it would be sweet. Ideally we
would not have to be part of it but worst case we can, at least for
a while.

s7r, how about you ask the Debian Cryptocoin Team¹ if they want to
co-maintain Electrum with mithrandi and/or with some Tails folks,
under the umbrella of their team?

[1] 
https://qa.debian.org/developer.php?email=team%2Bcryptocoin%40tracker.debian.org

If needed, there's now a formal package salvaging process in Debian:
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#package-salvaging

For Tails 3.x, if fetching the package from sid or experimental
doesn't work, it would be OK to ship a custom, Tails-only backport
from whatever is in sid or experimental. But for Tails 4.0 (Buster) we
would prefer shipping a package that's in buster-backports.

The FT would be ready to help s7r with maintaining the integration of
Electrum into Tails, if needed.

If we go this way, we would try this out for a while and invest as
little as possible into it, e.g. we would not bother about the
optional dependencies if they are not readily installable. Then, 6-12
months later, we would re-evaluate to check how much of our resources
this work takes, and Tails as a project can make a strategic decision
wrt. whether we should keep doing this work or focus our limited
resources elsewhere.

Option C: remove Electrum
=

This would be sad. We would like to evaluate options A and B first.

Doing a poll to learn how much people use Electrum in Tails might help
us better understand what the impact of this option would be.

Option D: AppImage
==

segfault and I have documented on this thread and on #16564 various
reasons why we think it's not an acceptable option for Tails at the
moment, and could easily require more work from all affected parties
than option B.

Option E: Flatpak
=

This could very well become the ideal option for Electrum at some
point but we're not ready for it yet. Flatpak is something we want to
work on in the next couple years anyway, for other reasons.

Thoughts?

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Tails vs Electrum

[intrigeri]

Hi,

s7r:
> On my last discussion with Electrum's Debian maintainer, he said that
> there are dependencies that are not in Debian yet, and have to go
> through new, etc. and there are huge chances that we won't be able to
> have it in Buster. python3-zbar for example, some hardware wallet
> libraries, etc.

My understanding is that these are optional dependencies for bonus
features, but Electrum base functionality works just fine with it.
E.g. the 3.2.3-1 package has:

  Suggests: python3-btchip, python3-trezor, python3-zbar

Correct? Or are there *hard*-dependencies missing in Debian at the moment?

> Let's pretend we make somehow some magic and package everything in
> Debian so we have Electrum 3.3.4 running in stable. We appear to be OK
> for the time being. But, who knows what the next attack will be, or what
> will happen, and then we'll end up in the same situation, that there's a
> new version we don't have in `stable-backports`. And we need it urgently
> because the one we have doesn't work any more, or it's vulnerable, or
> etc. Actually, it is already _3rd time_ we are in this situation.

I think there's a misunderstanding about the ways available to package
maintainers, in order to fix critical issues in stable backports.
It can be done in two ways:

  - Either go through sid → testing → backports: generally 5 days;
even less if the package includes autopkgtests.

  - Skipping testing i.e. sid → backports, for security issues or
other critical problems, as an exception. All this can happen on
the same day as a new upstream release. For details, see:
https://backports.debian.org/Contribute/

In other words, assuming a package maintainer is available to get the
fix in backports, there's no policy or technical reason that prevents
them from doing so very quickly.

Things are a bit different during a Debian freeze. We could ship
a Tails-specific backport whenever Debian policies (as opposed to
maintainer availability) are the only blocker to get the fixes we need
into stable backports. That can be the case for a few months every
2 years, such as… right now.

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [review'n'merge] Unfuzzy home page

[intrigeri]

xin:
> Hello, please review and merge.

> Repo: https://git-tails.immerda.ch/xin/tails/
> Branch: unfuzzy_home
> Last Commit: 95889a222145c75c2d892e77672b865364f81916

Merging, thanks!
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] Proposal: Redmine workflow change

[intrigeri]

Hi,

With the upcoming migration to GitLab in mind, while reading some
books, using a kanban board locally, and with the idea to make the
contribution process smoother for both newcomers & long-timers, I've
thought quite a bit about how we use tickets to organize our
work recently.

My main conclusion so far is: I want to make it easier to determine
and set the status of a ticket.

Currently, the status of a Redmine ticket is built from the
combination of "Status" and "QA Check"; it does not help that some of
these combinations make no sense at all. I've noticed that many of us
have a hard time managing these 2 fields, regardless of how long
they've been contributing to Tails; so this data is very often wrong.
This, plus Redmine limitations, makes it impossible at the moment to
have an overview of a set of tickets, grouped by their actual status
(defined by a combination of "Status" and "QA Check").

So I propose that we drop the "QA Check" field and instead, introduce
a "Needs Validation" status. So a ticket would typically go through
this journey:

 New → Confirmed → In Progress (once someone starts working on it)
 → Needs Validation (once it's deemed ready to be merged by the
 person/team who's been working on it) → Fix committed → Resolved.

And if the reviewer requests changes, they would set the status
back to "In Progress".

The only thing we lose along the way is QA Check = "Info Needed" plus
the associated reassignment dance. Removing that has only benefits
IMO:

 - This value is very often wrong because we forget to drop it and to
   reassign back, after providing the requested info.

 - Assigning a ticket to someone else + Info Needed, merely to get
   some input regularly causes trouble: it makes the task invisible to
   the person who's requesting the info, which makes it harder to
   organize their work — occasionally I'll be surprised when a ticket
   lands back on my plate after the info is provided. And if the
   requested info is not provided in a timely manner, WIP can be
   stalled for a long time, with no easy way for the requester to
   notice and decide whether they should move on without that info.

Given we now have "mentions" (@nickname) on our Redmine, for the
majority of cases, when the requested info can presumably be provided
cheaply and quickly, I think we should use mentions and not reassign
the ticket. And when I'm mentioned, if I realize that providing the
requested info needs will take me great amounts of work, I should
do whatever works for me to track this work, be it on a new ticket
or my personal offline organization tools.

Thoughts?

I'll be happy to implement this proposal.

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [review'n'merge] Few changes in Numerous_security_holes_in_3.12

[intrigeri]

xin:
>> Branch: Numerous_security_holes_in_3.12
>> Last Commit: 2bb390c0c4fbea0322d01a0f7c1bd80066f19ee5

> Hello, this branch is still relevant, can someone take a look?

Merged, thanks for your patience.

___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Tails vs Electrum

[intrigeri]

Hi,

sajolida:
> I think the Foundation Team should follow up on this idea there.

So far, Electrum hasn't been part of our mission but even if we don't
do the work ourselves, I agree we should at least provide guidance
wrt. what solution would be acceptable or not for Tails.

I won't have time for this in March but I've added this topic
to the agenda for the upcoming Foundation Team sprint (early April).

> In terms of priorities for the project. I'm personally really not
> thrilled at the idea of spending a lot of time dealing with this
> situation.

Yep. That's in line with our decision a couple years ago to remove
Electrum unless someone stepped up to maintain its integration in
Tails. And then s7r did step up! (thanks :)

> But I also guess that Electrum users are a good share of our
> user base and removing Electrum might make us loose users. Bitcoin users
> are also traditionally good donors and removing Electrum might make use
> loose donations.

Good point. Data coming from Help Desk suggests that we have quite
a few users of Electrum indeed, or at least, the ones we have are
particularly vocal :)

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] Fwd: Buggy boot

[intrigeri]

Hi,

I'm forwarding this report to our help desk. Thanks for the kind words :)

bradley--- via Tails-dev:
> Hey,

> Thanks for all the work you put into Tails. It is an amazing system and I
> find it very useful.

> I would like to report one issue however. Every second time I boot Tails,
> it fails. It either displays some errors in the command line booting
> screen or the letters on the normal booting screen are not readable and I
> need to restart anyway.

> If what I am writing about does not ring a bell, I can try to elaborte a
> little more.

> What can be a cause of it?

> Cheers,
> Brad

___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [review'n'merge] Update links in known issues page

[intrigeri]

xin:
> Hello, please review and merge.

> Repo: https://git-tails.immerda.ch/xin/tails/
> Branch: links_known_issues
> Last Commit: 00580669564237f1d46271832f71a32ace13374d

Merged, thanks!
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [Tails-l10n] Release schedule for Tails 3.13

[intrigeri]

Hi,

anonym:
> I'll be the RM, using this schedule:

In the end I'll be the RM and the schedule will be:

* 2019-03-17:
  - Feature Freeze: Unless I have told you otherwise, all feature branches
targeting Tails 3.13 should be merged into the `stable` branch by
noon, CET. Ask if you need an exception!
  - Start preparing Tails 3.13.

* 2019-03-18: Build and upload Tails 3.13

* 2019-03-19: Test and release Tails 3.13

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] [announcement] The Foundations Team now has an email address

[intrigeri]

Hi,

there's now a way to email the Foundations Team as a whole when you
want to talk to all of us at once:
https://tails.boum.org/contribute/working_together/roles/foundations_team/#contact

@help desk: for now at least, this does not impact your workflow wrt.
forwarding support request you cannot handle and debugging info.
Until we have some kind of rotation in place for the Foundations
Team's "frontdesk" role, I'm still responsible for triaging and
dispatching this sort of things.

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Automerge of devel into feature/buster?

[intrigeri]

Hi,

Sandro Knauß:
>> Sure. I've answered part of it above. On top of that, please read the 
> "Overview" and "Build system" sections of the corresponding doc: https://
> tails.boum.org/contribute/APT_repository/custom/ then let me know if there's 
> anything left unclear.

> What I find is not clear enough: How new packages enters the
> APT repo?

We built packages locally and upload them there ("Importing a new
package" section on that page).

> Okay let's summarize the current situation for feature/buster from my point 
> of 
> view:

This reflects my understanding of the situation as well.

>> A) Treat feature/buster as any other topic branch (status quo)

> we need to make sure, that someone is taking responsibility to merge devel 
> into buster regularly. Otherwise this work it put on the shoulders for those 
> you want to do fix unrelated stuff and mixing different task in one branch 
> makes 
> it all more complicate to do reviews and use the branch.

Fully agreed. I've just done it and this time there was no conflict to
resolve whatsoever; I didn't check if the resulting feature/buster
builds on Jenkins yet (but it was broken before anyway). If that's the
main or only blocker for option A (vs. option C), then I volunteer to
do that myself regularly.

>> B) Treat feature/buster as a "main" branch, like stable and devel

> IMO think it is too much overhead for the moment. We may switch to this 
> solution if feature/buster needs a diff against devel packages. I think we 
> will 
> switch to it if we focus more on getting a version ready for Buster.

Absolutely.

>> C) Treat feature/buster as a special case, i.e. use devel APT suite as
>> a basis + feature-buster overlay, but no automatic Git merge from
>> devel into feature/buster

> For me this sounds like kibi and I see this branch. As long as the overlay is 
> small, that should be fine for the moment. And I am not arguing against 
> merging 
> with devel I think this should be our way to solve things.

I'm fine with you folks trying this out for a while if you want, e.g.
until we ship a first public beta/RC with security support (once we're
there, I don't think that these lower expectations will fly anymore,
and we'll need to revert to either option A or B).

>> I understand we have different expectations wrt. what our CI is
>> supposed to tell us. I guess that's because you and I are implicitly
>> asking different questions to our CI.
>> 
>> The question I personally care about most is: "could we merge and
>> release this branch tomorrow?". The current setup correctly answers
>> "nope" for feature/buster. Options B and C would sometimes incorrectly
>> answer "yes". But the "yes" you would like to hear may very well be
>> the correct answer to another question, i.e. the one you're most
>> interested in personally :)

> We know both that releasing Buster tomorrow doesn't make sense, as Buster 
> isn't even released. I fully understand, that "can we merge devel into 
> feature/buster" is a very good question and the answer from CI is helpful. 
> But 
> I don't see why "can I merge devel into buster" should be a precondition for 
> any review on the buster branch.

Fair enough. As you know, I personally think that the drawbacks of
removing this precondition outweigh the advantages, but I won't argue
endlessly about it and I'm happy to see you try your preferred way :)

> And if it is mostly about po conflicts, we can help the merge
> strategy for po files.

Right, it's good to keep this in mind!

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Automerge of devel into feature/buster?

[intrigeri]

Hi,

Sandro Knauß:
> intrigeri:
>> A) Treat feature/buster as any other topic branch (status quo)
>>
>>Pros:
>>- We don't have to maintain a full-blown feature-buster APT suite.

> What is meant by "full-blown APT suite".

An APT suite that has _all_ our custom packages, e.g. tails-greeter.
At the moment our "devel" suite has 41 source packages. Chances
are that feature-buster would have slightly fewer packages.
With the current setup we don't need that: a build of feature/buster
will use the "devel" APT suite.

> Why we would need that for other solutions?

For B, that's basically the definition of a "main" branch: it lives in
isolation and is not built on top of another "main" branch.

For C we don't need that by definition of "use devel APT suite as
a basis + feature-buster overlay".

> How much work is this to maintain this?

Very rough estimate: I would expect 30-120 minutes of work after each
Tails release, depending on many factors.

>>- All our CI results are always about a product that makes sense.

> Well at least for my information state, I'd say no the CI gives wrong status.

I understand we have different expectations wrt. what our CI is
supposed to tell us. I guess that's because you and I are implicitly
asking different questions to our CI.

The question I personally care about most is: "could we merge and
release this branch tomorrow?". The current setup correctly answers
"nope" for feature/buster. Options B and C would sometimes incorrectly
answer "yes". But the "yes" you would like to hear may very well be
the correct answer to another question, i.e. the one you're most
interested in personally :)

>> - We need to maintain a full-blown feature-buster APT suite.   
>>   We've done that in the past and it's been super painful and
>>   error-prone (as in: "oops, I've replaced Buster-specific
>>   packages with Stretch-specific ones in feature-buster").

> Can you explain this? It all sounds like there is one level I don't really 
> have in mind/understood.

Sure. I've answered part of it above. On top of that, please read the
"Overview" and "Build system" sections of the corresponding doc:
https://tails.boum.org/contribute/APT_repository/custom/ then let me
know if there's anything left unclear.

>>   Our release process doc assumes we're in this case but very
>>   often, in this option the "merge devel into feature/buster" step
>>   is just too hard _at the APT level_ so the RM skips it, and in
>>   the end feature/buster lags behind devel like crazy most of the
>>   time. Or sometimes even worse, it's in sync' at the Git level
>>   but outdated at the APT level, which gives very
>>   confusing results.

> Are you talking about "packages built for the tails apt repository, that 
> would 
> also need to be rebuild for feature/buster"? 

Indeed, they're the biggest problem:

 - We may have to update, build and upload them (e.g. once Tails
   Greeter has itself a feature/buster branch).

 - We have to ensure we don't replace them with a Stretch version.
   We currently lack the tooling we would need to do this with great
   confidence and avoid such mistakes.
   (In the "Merging a main branch"instructions of the aforementioned
   documentation, this is "Make sure you are not going to overwrite
   newer packages with older ones".)

>> - Sometimes feature/buster will FTBFS because it needs an update
>>   that's been done in devel (e.g. Linux ABI bump). So all in all,
>>   we don't necessarily get more data from our CI.

> but we still need to merge such a patch to feature/buster. So a failing 
> feature/buster makes sense for me in that case. 

Glad we're on the same page. I wrote this because the main (only?)
advantage of the B option is precisely the hope we would get more data
from our CI… and it turns out it's not clear that would be the case in
practice, so the drawbacks of option B seem to vastly outweigh its
potential advantage.

>> - One more special case to reason about. I've found our whole
>>   Git/APT integration to be one of the most complex pieces in the
>>   Tails build system puzzle for newcomers and long-timers alike to
>>   wrap their mind around. Making it more complex will make it
>>   even harder.

> Ah this sounds familiar ;D Okay I need to learn more about this before 
> deciding. Your text sounds like, we should try to make it simpler. 

FWIW anonym & I have occasionally dreamed of encoding more stuff about
our

Re: [Tails-dev] Release schedule for 2019

[intrigeri]

Hi,

one clarification:

intrigeri:
>  - Please base your branches on the stable one if you're targeting
>Tails 3.x.

This may suggest that our "devel" branch will be mostly useless during
that time. Indeed, this will be the case… mostly. Mostly, because we
will keep updating, on our stable branch, selected packages from
Debian. Keeping our devel branch in a shape that builds and passes
tests will give use useful data points about the impact of such
updates, without having to first prepare a branch for each of them.

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] Release schedule for 2019

[intrigeri]

Hi,

here's a proposed release schedule for this year:

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

You'll notice that there is no major release planned earlier than
October 22. Yes, that's a long time without any major release. In the
last 5 months, we're released three big new features. Congrats! As far
as I know, there's no big new feature in the pipeline for the next few
months so it seems to be a good time to start looking further ahead,
focus on Buster and start work on other large roadmap items with less
churn and day-to-day busywork. Also, note that starting in a few
months, with every 3.x release we'll prepare, test and publish a 4.0
pre-release of some kind.

During that time:

 - We would probably stick to whatever kernel is in Buster instead of
   tracking sid.

 - We'll relax a bit our policy for what changes qualify for inclusion
   in 3.x bugfix release. Whenever reasonable, provided sufficient CI
   coverage and calls for testing, slightly larger changes than usual
   may be accepted. In doubt, please talk with the foundations team
   and release managers.

 - Please base your branches on the stable one if you're targeting
   Tails 3.x.

Thoughts, feelings?

Anything I missed that could invalidate this plan?

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [review'n'merge] Fix additional_software links

[intrigeri]

Hi,

xin:
> Hello, please review and merge.

> Repo: https://git-tails.immerda.ch/xin/tails/
> Branch: additional_software_links
> Last Commit: f5e6979b256298691aa07258bc60ffa664adb42b

Indeed, in commit d21aacde010ed0b7871791016e4a880179ce26e3
we renamed that page without updating links accordingly,
and no rewrite rule was added.

Merged, thanks!
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [Tails-l10n] Release schedule for Tails 3.13

[intrigeri]

Hi,

scratch all that. With the updates Georg nicely shared, we can now
tell that 3.13 will be a regular bugfix release and there won't be any
3.13~rc1. It's not 100% clear yet who will be the release manager
but kibi agreed to be the fallback option.

I expect the schedule will be:

 - March 18: build and upload Tails 3.13
 - March 19: test and release Tails 3.13

… but I'll let whoever ends up being the RM confirm and set deadlines
for branches submission and merging :)

Anyone who's part of our internal QA process ("manual test suite"),
please let tails...@boum.org know if you're available on March 19 to
test the final release. Thanks in advance!

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Release schedule for Tails 3.13

[intrigeri]

Hi,

Georg Koppen:
> intrigeri:
>> This relaxes me a bit regarding #27466, #26553, and #28044
>> (Tor bugs, not Tails tickets).

> No worries about those. We think we don't get those bugs into a stable
> release shape for 8.5. They will be 9.0 material if at all.

OK, so in the end it looks like 8.5 should not bring big changes for
us (at least not those we had on our radar already as potential deal
breakers).

>> Does this mean that the first 8.5.x release that has *no*
>> corresponding 8.0.x will be the 2019-05-14 one?

> I am not sure exactly what you mean but let me come up with my best
> guess. :)

> Assuming there are _no_ emergency releases in between, then the release
> planned for 2019-05-14 will be the first stable release picking up
> Firefox security bug fixes that will be based on 8.5 while the
> corresponding alpha will be 9.0aX.

What I need to understand is essentially: what's our deadline to make
sure Tails is ready to ship Tor Browser 8.5.

I think I now understood that:

 * If there's an emergency release, late March or in April, then it
   may be based on 8.5 (depending on how ready the 8.5 tree is).

 * Else, if there's no emergency release between the time the 8.5 tree
   is ready to be called stable, and May 14, then the first Tor
   Browser 8.5 release Tails needs to ship will be the May 14 one.

It follows that Tails needs to be ready before late March to upgrade
to 8.5, in case there's an emergency release.

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Release schedule for Tails 3.13

[intrigeri]

Hi Georg,

Georg Koppen:
> Don't wait on us here for Tor Browser 8.5. The current plan is to have
> the release, which is scheduled for March 19, be a "normal" 8.0.x
> release and getting 8.5 out end of March.
> However, this is mainly bound to having the Android part in shape in
> time, because 8.5 will be the first major release with Android
> support. Thus, it might happen that we need to postpone 8.5 a little
> further into April.

OK, thanks a lot for the update! I totally missed that but I have
quite some backlog reading to do on Tor Browser team meeting minutes.

I'll update our release schedule and other plans accordingly.
This relaxes me a bit regarding #27466, #26553, and #28044
(Tor bugs, not Tails tickets).

Does this mean that the first 8.5.x release that has *no*
corresponding 8.0.x will be the 2019-05-14 one?

> That said, also keep in mind that Pwn2Own will be between March 20-22
> and Firefox is one of the targets. The actual schedule of exploit
> attempts is usually revealed at the beginning of the week, so not sure
> yet when a potential emergency release would need to happen (if at all).

I wish Mozilla made it so they have a scheduled release *after*
Pwn2Own instead of a couple days before… anyway, thanks, that's
definitely something we should keep in mind. Added to our calendar and
to our checklist for building release management schedules, so we rely
a bit less on you to remind us of such important things :)

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] Release schedule for Tails 3.13

[intrigeri]

Hi,

I'll be the release manager for Tails 3.13 up to, and including, the
release of 3.13~rc1. Then someone else, likely kibi, will take over
until 3.13 final is out.

This release will be a hybrid bugfix/major release:

 - It'll be major in the sense that it will upgrade Tor Browser to
   8.5, which will include major changes.

 - It won't be major in the sense that we may lack time to prepare and
   review major other changes in time for the freeze. We might also
   decide to stick to the frozen APT snapshots used by 3.12.

So please base on the *stable* branch any work targeted at 3.13.

If a Tor Browser 8.5 beta is ready and integrated into Tails
by then:

 - March 8: build and upload Tails 3.13~rc1
 - March 9: test and release Tails 3.13~rc1

Otherwise, we may have to skip the RC and instead send a call
for testing later, for an unofficial nightly built image.

And then, in any case:

 - March 18: build and upload Tails 3.13
 - March 19: test and release Tails 3.13

Anyone who's part of our internal QA process ("manual test suite"),
please let me know if you're available on March 9 to test the RC,
and/or on March 19 to test the final release. Thanks in advance!

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [review'n'merge] doc update

[intrigeri]

xin:
> Hello, I made few changes in the website.
> Please review and merge.

> Repo: https://git-tails.immerda.ch/xin/tails/
> Branch: doc_update
> Last Commit: ffc43f287a4018825d4519367b1056c0903e7181

Merged, thanks!
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Automerge of devel into feature/buster?

[intrigeri]

Hi,

Cyril Brulebois:
> […] the build in Jenkins failed because devel is automatically
> merged into it.

Yes, so far feature/buster has been treated like any other topic
branch, i.e. its base branch is "devel", and then when building
feature/buster:

1. As you've noticed, on Jenkins we merge devel into feature/buster
 
2. We use the "devel" APT suite as a basis, and on top of that we have
   very few Buster-specific packages in the feature-buster
   overlay suite.

> Does this automatic merge (due to config/base_branch I assume) make
> sense, as we're going to merge devel into it in a regular manner anyway?

> (Right now, that means somebody would have to fix the conflicts before
> we get a build and the resulting test suite run…)

Glad you're asking!

I believe there are three main ways to handle this. We've tried the
first two ones below (A and B) extensively. You might be proposing
a third one (C):

A) Treat feature/buster as any other topic branch (status quo)
   
   Pros:

- We don't have to maintain a full-blown feature-buster APT suite.
- All our CI results are always about a product that makes sense.

   Cons: when merge conflicts happen, until someone manually resolves
   them, we have no CI results at all.

B) Treat feature/buster as a "main" branch, like stable and devel

   Pros:

- No automatic merge so as long as changes in Debian don't break
  stuff, the branch should always build on Jenkins ⇒ more data
  from our CI.

   Cons:

- We need to maintain a full-blown feature-buster APT suite.
  We've done that in the past and it's been super painful and
  error-prone (as in: "oops, I've replaced Buster-specific
  packages with Stretch-specific ones in feature-buster").

  Our release process doc assumes we're in this case but very
  often, in this option the "merge devel into feature/buster" step
  is just too hard _at the APT level_ so the RM skips it, and in
  the end feature/buster lags behind devel like crazy most of the
  time. Or sometimes even worse, it's in sync' at the Git level
  but outdated at the APT level, which gives very
  confusing results.

- The data we get from our CI is not very valuable as most of the
  time, we're testing the port of an obsolete codebase to Buster.
  E.g. as of today, feature/buster is lagging behind devel by
  3 weeks.

- Sometimes feature/buster will FTBFS because it needs an update
  that's been done in devel (e.g. Linux ABI bump). So all in all,
  we don't necessarily get more data from our CI.

C) Treat feature/buster as a special case, i.e. use devel APT suite as
   a basis + feature-buster overlay, but no automatic Git merge from
   devel into feature/buster

   Pros:

- We don't have to maintain a full-blown feature-buster APT suite.
- No automatic merge so as long as changes in Debian don't break
  stuff, the branch should always build on Jenkins ⇒ more data
  from our CI.

   Cons:

- Mismatch between the code in Git (based on an old version of the
  devel branch) and the packages installed from the devel APT
  suite ⇒ CI results are at best low-value for the same reason as
  in option B, and worst case they're super confusing (the code
  assumes given package versions and vice-versa). If we go this
  way, I suspect we'll spend more time debugging issues that would
  be solved by merging current devel into feature/buster, than the
  time it takes to resolve merge conflicts with option A.

- One more special case to reason about. I've found our whole
  Git/APT integration to be one of the most complex pieces in the
  Tails build system puzzle for newcomers and long-timers alike to
  wrap their mind around. Making it more complex will make it
  even harder.

- Sometimes feature/buster will FTBFS because it needs an update
  that's been done in devel (e.g. Linux ABI bump). So all in all,
  we don't necessarily get more data from our CI.

Personally, I very much like the simplicity and predictability of
option A. In my experience, dealing with these occasional merge
conflicts is simple in the vast majority of case: most of the time
they're in PO files, and until we start merging Buster-specific
translations into feature/buster, one can pick the versions from
devel, then run ./refresh-translations, then git add + commit and be
done with it. So I'm quite convinced that the savings we would get
from option C don't outweigh its drawbacks.

Now, I'm not going to work on feature/buster between sprints, so I am
happy to let those who will work on it pick the option they prefer :)

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] upgrades and ideas

[intrigeri]

Hi,

I'm relaying your message to our help desk:

new...@secmail.pro:
> hi I was wondering if the new tails that comes out Jan 28th 2019
> will support Jabber chat?  ICQ chat?  and/or Wickr chat?

> Also it would be nice to have a feature where one could make the heading
> of the TOR browser window not say "- Tor Browser"  as if you use in
> public it could comprimise somethigit.  build in a hot key or mode to have
> it say something else. blue finn? I dunno anything.

> also if there is a way to have the tabs open just say "tab1" tab2" etc.
> that way it's not broadcast to the world what you are doing to anyone who
> walks by.

> Thank you

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] more suggestions

[intrigeri]

Hi,

new...@secmail.pro:
> Another suggestion please build in a monero wallet..

Please see this email:
https://lists.autistici.org/message/20190110.073515.99734363.en.html

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [Tails-project] boot tails iso with grub

[intrigeri]

Hi,

linux-service:
> I am no export, but using this now:

> curl -s 
> "https://tails.boum.org/install/v2/Tails/amd64/stable/latest.json"; | jq  
> . | awk -F'"' '{ for(i=1; i<=NF; i++) { if($i ~ /^http/) print $i } } '

> but it is no pure jq

I'm afraid we're running in circles :/  I'm sorry about that.

First, I'll reiterate: I appreciate that you're trying to ship Tails
on these computers. Thank you!

Now, let's take a step back. This thread started with you essentially
asking essentially "is it safe to ship this modified Tails and its
home-made upgrade system?". So far the discussion has been:

1. answering "it could probably be made safe if you do this and that,
but in the current state of things, it's not OK to call this Tails".
But quite some bits of "this and that" are not implemented.

2. asking you more info that I need to answer your question
meaningfully. Some of the first batch of questions I've asked in
October have not been answered yet.

Since installing and running Tails on an internal hard drive is not
supported yet, safely ship something that can be called "Tails" on
these computers requires non-trivial software development, UX design
and tech writing work, and only so the basics are covered and users'
expectations match what you're actually providing (not even aiming at
providing a full-fledged Tails experience).

I'll be honest with you: at this point of the process, I'm not
confident at all that you'll manage to find/allocate the resources
needed to do all this work.

And I don't think it makes sense for Tails, as a project, to invest
much in doing this work ourselves. I'd much rather see us work on
making "installing and running Tails on an internal hard drive"
a first-class citizen: it would benefit much more people. I don't
expect this will happen shortly but it's good to know that it would
address most of the issues identified in the course of
this conversation.

So I would like to ask you to reconsider whether you are in a position
to get all the needed custom work done. And if not, it would be much
better to stop shipping
something-like-Tails-but-not-quite-but-that-still-pretends-to-be-Tails
on the internal hard drive. The good news is that there are many
other, much simpler & cheaper, ways to let your clients know about
Tails and more general privacy issues, for example:

 - include a flyer promoting Tails and/or Tails stickers in the box
   when you ship a computer

 - give the default browser a home page explaining that private
   browsing mode / incognito tabs are not that incognito, and pointing
   to our website

 - add a bookmark to our website in the default browser configuration

… and I'm sure a quick collective brainstorming would find many more
ideas :)

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [Tails-project] boot tails iso with grub

[intrigeri]

Hi,

linux-service:
> Ok, but i am not able you get the correct jq code to retrieve the url.

> The - character is making some problems,,,

Can you please share the exact command you're running and the error
you get?  (If our JSON is not strictly valid enough, we can fix that.
If jq is buggy, there are plenty of other JSON parsers around.)

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [Tails-l10n] Tails contributors meeting: Sunday February 03

[intrigeri]

sajolida:
> The next Tails contributors meeting is scheduled for:

>   Sunday 03 February

As per our scheduling rules we'll avoid Sunday so the meeting
will instead take place on Wednesday, February 6. Same hour,
same place. See you there :)

___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Electrum unable to connect to onion servers

[intrigeri]

Hi,

adding s7r, who is maintaining the integration of Electrum in Tails,
into the loop:

node.ad...@secmail.pro:
> I run a ElectrumX on a hidden service

> 4yi77lkjgy4bwtj3.onion port 50001 for TCP and port 50002

> I was testing connection to this electrum server from different software
> including tails with the built in electrum. It looks like tails can
> connect to clearnet electrum servers. But not able connect to hidden
> service electrum servers. I test the electrum connection with other hidden
> service electrum servers with no working.

> I do not think it is connection issue in tails. I can see the connection
> to this hidden service in onion circuits. And I can reach this service on
> both port 50001 and port 50002 in terminal. Is there issue in compatiblity
> with tails and electrum when it comes to connecting to onion electrum
> servers? Being able to connect to onion servers is huge important for
> security and privacy.

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [Tails-project] boot tails iso with grub

[intrigeri]

linux-service:
> so if i:

> #!/bin/bash
> url=`curl 
> 'https://tails.boum.org/install/v2/Tails/amd64/stable/latest.json' | awk 
> -F'"' '{ for(i=1; i<=NF; i++) { if($i ~ /^http/) print $i } } '`
> wget $url

> i always get the latest iso?

That's the idea :)

Now, "parsing" JSON this way feels super fragile. If you have to stick
to shell, I recommend using jq(1) to extract the info you want.

But really, switching to Python / Ruby / etc. would be nicer (and then
you won't have to deal with the "shell programming is hard" problem,
which your example script shows — e.g. missing quotes may lead to
arbitrary code execution as root on all your users' systems, if our
latest.json ever had malicious content).

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [Tails-project] boot tails iso with grub

[intrigeri]

Hi,

linux-service:
> I am just putting the iso on our server (now  wget 
> https://www.ubuntushop.be/tails.iso
> ) because of the iso version numbering.

> I am no expert, i am looking for a wget command for downloading always 
> the late st iso from tails.

The URL you're looking for is in the JSON file I've pointed you at :)

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] Tails→Buster: status update

[intrigeri]

Hi!

last week, a bunch of Foundations Team members had a sprint
focused on porting Tails to Debian 10 (Buster).

What we did was mostly:

 - update the test suite: good WIP that lead to identifying
   regressions for which tickets were filed
   https://redmine.tails.boum.org/code/projects/tails/issues?query_id=279

 - fix a number of regressions, admittedly slower than they were
   being identified

 - made the ISO and IUK build reproducibly

We'll probably have another sprint on this topic early April.
We will invite other Tails contributors to participate remotely.

I'm quite confident that after this second sprint, things will be
working well enough for our technical writers to start updating
our doc.

It's too early to commit to any particular timeline, but FWIW here's
what seems the most likely to me at this point:

 - April: release 4.0~beta1, call for testing; no promise to provide
   automatic upgrades nor security support at this point

 - June or July: third sprint

 - 2019-07-09 or shortly after: release 4.0~beta2 and commit to
   provide automatic upgrades and security support until 4.0 final is
   out

 - July-August: fix the most critical regressions identified by
   testers and start porting to Firefox 68

 - 2019-09-03: release 4.0~rc1 at the same time as 3.16

 - September to mid-October: fix as many regressions as we can,
   complete porting to Firefox 68

 - 2019-10-22: release 4.0 final

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [Tails-project] boot tails iso with grub

[intrigeri]

Hi,

sorry for the delay…

linux-service:
> More and more business customers ask to disable usb on their notebooks 
> for security, so we have no option other than work with grub and iso.

Got it, thanks. Please disregard my question about "blocked USB ports"
on the other, private discussion. I assume they also ask you to disable
any micro SD slot the laptops might have, right?

I understand that if we supported installing Tails on the hard drive,
this would satisfy your needs. We're very close to removing one
major blocker for this (incidentally, thanks to the USB image project).
I'm not sure how much initial work and maintenance it would take
to fully support this use case. I would be happy to take a look
if we knew this work could be funded ;)

> We working with iso's:

> menuentry "tails" {
>      set isofile="/iso/tails.iso"
>      loopback loop $isofile
> set root=(loop)
>      linux (loop)/live/vmlinuz boot=live iso-scan/filename=${isofile} 
> findiso=${isofile} apparmor=1 nopersistence noprompt timezone=Etc/UTC 
> block.events_dfl_poll_msecs=1000 splash noautologin module=Tails 
> slab_nomerge slub_debug=FZP mce=0 vsyscall=none page_poison=1 
> union=aufs  quiet toram
>      initrd (loop)/live/initrd.img
> }

I see that you're removing live-media=removable, as expected. As said
before, this implies full trust in the internal hard drive, which is
something the users might not be expecting when using Tails. I'm not
sure how best this should be dealt with. I think this needs a little
bit of UX design.

> We have created a bash script with gksu or pkexec for the user for 
> updating their tails iso :

> #!/bin/bash
> cd /iso
> gksu -- bash -c 'xterm -e "rm tails.iso; wget 
> http://95.211.190.99/astick1804/tails.iso";'

This upgrade method is significantly weaker than the initial
installation and upgrade paths we document and support:

 - Due to the use of cleartext HTTP and no verification, it's
   vulnerable to an active MitM attacker.

 - No verification is done, while all our supported installation and
   upgrade methods verify at the very least checksums served over
   HTTPS from our own website (which is trusted in our thread model).

Do you make this clear to your users in any way?

I'm worried they could be assuming "it's Tails, thus it's safe"
while running code that does not meet our standards. This could
harm them and the Tails "brand".

Instead of trying to communicate about this weakness to users, I think
the best way is to:

 - Either let them follow the Tails official documentation for
   downloading, which gives you verification for free. It works at
   least in Chrome and Firefox. And them have them use your script for
   installing the upgrade.

 - Or add verification to your upgrade script. The best way to do that
   will change soon and the corresponding design doc will be updated
   on our website on Jan 29. Meanwhile, check out this file, that's
   used by our "Tails Verification" browser extension to verify the
   ISO image downloaded from untrusted sources:
   https://tails.boum.org/install/v2/Tails/amd64/stable/latest.json

> We have also a script for updating grub's 40_custom.

Good :)

> I am donating to tails per sold computer.

Thanks!

Finally, I'm still interested in your answers to these questions of
mine:

> Op 31/10/18 om 11:06 schreef intrigeri:
>>   - Do you communicate to your clients, somehow, that the way you're
>> installing this Tails system is unsupported by the Tails project
>> and the resulting system may behave differently than a "real" Tails?
>> 
>>   - The Tails user experience relies more and more on our opt-in
>> persistence feature. While we still support read-only Tails, be
>> aware that you're shipping a flavour of Tails with a restricted
>> feature set. It would be nice to communicate this to your users
>> and point them to our doc about installing a full-blown Tails :)

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] tails iso

[intrigeri]

linux-service:
> Can you confirm that there will also iso images available.?

Yes (mostly for usage in virtual machines).

> We have more and more notebooks with blocked usb ports, so we still need to 
> boot tails.iso from grub2.

Just curious: can you elaborate on "blocked usb ports"?
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Secure Instant Messaging client for TAILS

[intrigeri]

Hi Jim,

Jim via Tails-dev:
> Tails needs to come pre-installed with one of the Encrypted Instant
> Messaging applications for instant communication through the Tails
> operating system.

I believe this is already covered:
https://tails.boum.org/doc/anonymous_internet/pidgin/

Regarding interoperability with mobile messaging apps, our roadmap¹
includes "Mobile messaging applications: research support for Signal, Wire,
Telegram, etc"². Help is welcome there!

[1] https://tails.boum.org/contribute/roadmap/
[2] https://redmine.tails.boum.org/code/issues/14567

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Monero client on Tails

[intrigeri]

Hi,

Jim via Tails-dev:
> Has the Tails development considered pre-installing the full Monero client 
> onto the TAILS OS?

We did, but at the time no Monero client was available in Debian:

  https://redmine.tails.boum.org/code/issues/14390
  https://redmine.tails.boum.org/code/issues/15686
  https://redmine.tails.boum.org/code/issues/13443

But now I see that the Monero *command-line* client is available in
Debian (including stretch-backports).

> It would make perfect send for Tails to come pre-installed with
> either the full Monero GUI client.

I see no Monero GUI in Debian so our reply on the aforementioned
tickets still applies: I don't think we should install a command-line
Monero with no GUI by default.

Still, if someone wants to work on Monero support in Tails, with
a target audience that's fine with the command line, next steps would
be to install the Monero client on Tails (apt install
monero/stretch-backports), test it, and figure out what it takes to
make it work fine.

Note that the package description reads:

 Beware that full global transaction history (blockchain) is stored locally,
 which may require very large amounts of disk space.
 .
 Disk space requirements (as of June 2018):
 ~40 gigabyte data, ~50 gigabyte on disk, growing ~2 gigabyte per month.
 More info at <https://moneroblocks.info/stats/blockchain-growth>.

… which might not work well with Tails persistent volumes on USB sticks.

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Patch waiting to be reviewed

[intrigeri]

Hi,

m3hm00d:
> I updated the status of bug#15583 [1] around 7 days ago. Please review
> the submission and advise.

Thanks a lot! I'll review this soonish, aiming at inclusion in Tails
3.12 (but if we miss that deadline, no big deal: we release pretty
often :)

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [review'n'merge] Fix download-iso translation

[intrigeri]

xin:
> Hello, I found strange things in the translation of the download-iso
> page in the branch feature/15292-usb-image.

Sorry, I messed this branch up :/

I'll repair what I can once
https://redmine.tails.boum.org/code/issues/16205 is solved.
This *might* fix the strange things you've found.
___
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] Disable usage of su and ask the user to use sudo instead (refs:15583)

[intrigeri]

Hi Faisal,

Faisal Mehmood:
> This commit contains a new chroot hook file. The hook, upon execution by
> live-build, will add a function 'su' to '/etc/bash.bashrc'. The
> function 'su' is supposed to intercept calls to 'su' and take these
> steps:

Thanks! I'll review this and will comment on Redmine :)

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

[intrigeri]

Hi Daniel,

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

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

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [PATCH] Add the meeting notes for december 2018

[intrigeri]

Muri Nicanor:
> attached

Applied, thanks!
___
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] Missing bit of information on your website

[intrigeri]

Hi,

Cody Brownstein:
> Sunny Karnani wrote:
>> I was looking over the download and verification instructions and
>> noticed that it might be helpful to add an additional step in the
>> Command line instructions under "See instructions for basic OpenPGP
>> verification.
>> "
>>  that
>> describes how to import the Tails signing key.

> I agree with you that the user should be instructed to not only download
> the Tails signing key but to import it as well.

> I am attaching to this email a patch that fixes that.

Thanks!
I've updated https://redmine.tails.boum.org/code/issues/16175
accordingly. Looks like your patch implements the (A) option.
___
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] [Announcement] Expect disruption of our CI this week

[intrigeri]

Hi,

> as part of our USB image project, we'll change some parts of our
> ISO/IMG build system this week and will need to adjust our Jenkins CI
> accordingly.

The trouble should be over now, except occasional USB image build
failures until #16168 is fixed.

Please report any infra/CI regression to groente and myself on
Redmine, as subtasks of #15993. Thanks!

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] [Announcement] Expect disruption of our CI this week

[intrigeri]

Hi,

as part of our USB image project, we'll change some parts of our
ISO/IMG build system this week and will need to adjust our Jenkins CI
accordingly. We'll need your input to spot the bits we've forgotten
and that remain to be adjusted, so please report any breakage to
groente and myself on XMPP or Redmine.

Thanks in advance and sorry for the inconvenience!

If you want details, see #15993, #16154 and friends.

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Memory Hole: strategy and timeline

[intrigeri]

Hi,

Daniel Kahn Gillmor (24 May 2018):
> On Mon 2018-02-19 12:00:12 +0100, intrigeri wrote:
>>  - A working desktop example should be made widely available, that is
>>Enigmail 2.0 should:
>>- be released as stable
>>- be the default version non-technical users can install via
>>  whatever installation/upgrade methods the Enigmail project
>>  supports
>>- be available for Debian stable users at least via stretch-backports

> This sounds great.  Unfortunately, […]

After months of tireless (and seriously frustrating) efforts, dkg
managed to get Enigmail 2.0 into Debian stable. Congrats!

So the only blocker left for Tails to tweet about this is
the specification.

> I have pushed an implementation for reading protected headers in
> notmuch, which is still waiting for review there.  I welcome review on
> the notmuch mailing list.

Great, I'll reply off-list :)

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [Tails-ux] TAILS Secure Boot Support

[intrigeri]

Hi,

sajolida:
> I'll let our developers have a look and see if such a technique could be
> implemented in Tails before Debian 10 (Buster) scheduled for mid-2019.

Thanks for caring.

This technique is basically what we're going to do when we add Secure
Boot support. In theory one could probably implement it this right
now. Having to use the signed shim and GRUB2 packages from Buster,
while we build in a Stretch environment, may make it a little bit more
challenging than waiting until Tails is based on Buster but I doubt
that would be a serious blocker. All in all, I suspect the hardest
part is not really the Secure Boot part, it's distributing an USB
image (#15292) and then migrating to GRUB2 (#15806).

So your question boils down to "can we do it earlier than planned?".
Our Foundations Team is plenty busy with other matters in 2018Q4 and
2019Q1. If the community thinks we should postpone some of this
planned work in order to tackle GRUB2 and Secure Boot earlier, please
let us know.

Now, if anyone else wants to work on this earlier, I'll be more than
happy to review your work :)

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] Announcement: test suite requirements changes

[intrigeri]

Hi,

if you have no local setup to run our automated test suite,
you can skip this email. Otherwise, read on.

The branch that implements automated tests for VeraCrypt was just
merged. With it come two changes that may require adjustments
to your test suite setup:

 - new dependency: tcplay
 - Running the test suite as a non-root user is deprecated.

The curious may want to look at the details: 

  git log -p ffd41363dc..d01d4b2 -- wiki/src/

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [Tails-l10n] git.tails.boum.org aka. git-tails.immerda.ch is moving

[intrigeri]

sajolida:
> 7 hours later, I restarted Tails and I still get the same error when
> fetching accounting.git and internal.git. I don't get this error when
> fetching master.git.

anonym has reported similar issues but he cannot see them if he uses
the IP address directly, which seems to confirm the hypothesis of
overenthusiastic DNS caching on exit nodes. Nothing we can do about
exit nodes whose DNS resolver/upstream does not honor TTL :/
Hopefully they invalidate their cache after 24h or so.

I've seen it too. For me, retrying a few times with torsocks --isolate
works eventually.
___
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-l10n] git.tails.boum.org aka. git-tails.immerda.ch is moving

[intrigeri]

sajolida:
> intrigeri:
>> There will be some downtime and DNS will take a while to update.

> What the timing window?

The migration is over and things are back into working shape.

> When trying to get accounting.git right now I get:

> gcrypt: Repository not found: ta...@git.tails.boum.org:accounting.git
> gcrypt: ..but repository ID is set. Aborting.

Either that was during the very short downtime (a few minutes) or the
exit node you were using was over-enthusiastically caching DNS records
(all involved TTLs are at 5 minutes). Or something.

___
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] git.tails.boum.org aka. git-tails.immerda.ch is moving

[intrigeri]

Hi,

our friends at immerda are migrating the Git infrastructure they host
for us (git.tails.boum.org aka. git-tails.immerda.ch) to a different
server. There will be some downtime and DNS will take a while
to update.

The new SSH fingerprints are:

  https://www.immerda.ch/assets/certs/certs.txt
  https://www.immerda.ch/assets/certs/certs.txt.asc

If you use over git+ssh a repository hosted there, you'll probably
need to verify and accept the new fingerprint.

Dear sysadmins, I bet there's stuff that needs manual updates on our
infrastructure (e.g. users that push to the immerda mirror). I'll let
you track this in whatever way that works for you.

@u: The translation platform might be impacted as well, I don't know.

Cheers,
-- 
intrigeri


signature.asc
Description: PGP signature
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [Tails-project] boot tails iso with grub

[intrigeri]

Hi!

Meta: redirecting from tails-project@ to our development mailing list
and taking over from our Help Desk who, understandably, cannot handle
this further than "this is not supported, sorry" :)

linux-service:
> We are selling opensource computers and install default a system where a 
> tails iso on the harddrive is booted with grub2 toram.

Interesting! There are a number of concerns with this approach but I'd
like to help you do this in a way that's reasonably safe for your
clients and does not cause us too much additional work.

> The hdd(s) are not mounted. Is this way of booting tails equal secure as 
> booting from usb or dvd?

There are a few concerns about this approach, some of them tackle
your question:

 - How do you force live-boot to start from an internal drive?
   I assume you need to remove live-media=removable, no?
   Note that doing this implies full trust in the internal hard drive,
   which is not something the users may expect when using Tails.

 - Do you communicate to your clients, somehow, that the way you're
   installing this Tails system is unsupported by the Tails project
   and the resulting system may behave differently than a "real" Tails?

 - How do you keep the kernel command line up-to-date? Assuming you
   hard-code it in the GRUB configuration, please be aware that we
   sometimes change it. I'm worried your GRUB config and what the
   installed ISO expects might get de-synchronized over time.

 - How do handle upgrades? I'm worried that your clients are left
   with an obsolete Tails and no documented way to upgrade it.

 - We'll soon stop supporting the ISO image except for DVDs and
   virtual machines (https://labs.riseup.net/code/issues/15292).
   Probably not a big deal for you in terms of initial installation,
   but this will make upgrades even harder for your clients. And an
   important upcoming security improvement (persistent RNG seed) will
   only work when Tails is installed on a USB stick.

 - The Tails user experience relies more and more on our opt-in
   persistence feature. While we still support read-only Tails, be
   aware that you're shipping a flavour of Tails with a restricted
   feature set. It would be nice to communicate this to your users
   and point them to our doc about installing a full-blown Tails :)

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [Tails-project] Tails contributors meeting: Saturday November 03

[intrigeri]

u:
> Do we agree that because this meeting is scheduled on a Saturday, it
> should rather happen on November 6th, ie. Tuesday?

Yes.

(In case it helps resolving such matters in the future,
https://tails.boum.org/contribute/calendar/ has the correct info :)
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [review'n'merge] Fix broken link

[intrigeri]

xin:
> Hello, a link to the additional software documentation is broken in 3
> languages.
> Please review and merge.

Merged, thanks!

(And in passing, a RewriteRule in .htaccess would be nice.)
___
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] onion-grater fix Tor control auth cookie authentication even if HashedControlPassword is set

[intrigeri]

Hi,

Patrick Schleizer:
> https://github.com/Whonix/onion-grater/commit/70e735dae1c15920c356b07fc6aaf4b9589b465a
> Please review and merge.

Code looks OK, quick manual testing in Tails works fine. I'll wait for
my full Tails test suite run to confirm this and then I expect I'll
push this to tails.git today :)

> The more I think about it, perhaps we could abolish DEFAULT_COOKIE_PATH
> = '/run/tor/control.authcookie' altogether?
> [...]
> Then we might be able to simply this and just use authenticate().

No strong opinion here, feel free to send a patch if you feel strongly
about it. Bonus points if the patch has been quickly tested in
a running Tails system.

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] inclusion of xinput in the main build of Tails

[intrigeri]

Hi,

zero identity:
>> And it can't be disabled in the BIOS / firmware setup? Or physically removed?

> That's very much dismissing the general issue and requesting users
> solve this issue on their own. The inclusion of the package the user
> requested would be the ideal solution, I think.

At this point I'm not requesting anyone to do anything: I'm merely
gathering information. Said info was provided (thanks!) so here's
my summary.

I was asking about disabling the problematic device in the firmware
setup because, while not frankly easier than the xinput one, this
option at least solves the problem once and for all, so I think that
investing some time into it would be more appealing, to less technical
users who are affected by this problem, than "run xinput blah blah
every time you start Tails". But I understood this won't work, too bad.

The proposed "ideal solution" does not solve the problem: it only
installs by default a tool that will allow technical users, who are at
ease with the command line, to solve this issue on their own. For such
users, there are two options:

 - Either we don't include xinput by default, and then affected users
   need to install it once, accept adding it to their Additional
   Software, and then on every boot, either wait for xinput to be
   started and run a command line, or implement the more automated but
   technically involved solution I've mention on this thread last month.

 - Or we include xinput by default, and then it's exactly the same as
   above, except one can skip the "accept adding it to their
   Additional Software" step, which arguably is the easiest one
   in the whole procedure for less technical users.

So I don't understand how including xinput by default would improve
user experience substantially.

And since we're not discussing fixing the problem but providing ways
to users to fix it themselves: I suspect the hardest part of this
whole procedure, for less technical users, is to find out that there's
a solution at all, on some web site they trust enough to copy'n'paste
command lines from. So I'll happily document this solution (a xinput
command line) on our Known Issues page once someone kindly shares it.
This way, all affected users can benefit from it, not only those who
know about it already and are requesting xinput to be included
by default.

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] TBB-Firefox sends OS+kernel in update queries to Mozilla

[intrigeri]

For the record this is tracked upstream at
https://trac.torproject.org/projects/tor/ticket/16931
___
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.