Bug #10694

Additional software install fails if remote repository broken

Added by andrewgdotcom 2015-11-30 01:03:05 . Updated 2018-07-27 21:56:13 .

Status:
Rejected
Priority:
Normal
Assignee:
Category:
Persistence
Target version:
Start date:
2015-11-30
Due date:
% Done:

0%

Feature Branch:
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Additional Software Packages
Deliverable for:

Description

Last week, deb.tails.boum.org was down for a while. This meant that additional software installation always failed, even for packages that had been cached.

Solution:

On any download failure, tails should fall back to cached packages.

Files

signature.asc (801 B) andrewgdotcom, 2015-12-01 04:47:02
signature.asc (801 B) andrewgdotcom, 2015-12-02 04:38:21

Subtasks

Related issues

Related to Tails - Feature #14568: Additional Software Packages Resolved 2013-12-11 2018-06-26

History

#1 Updated by sajolida 2015-11-30 10:00:54

  • Assignee set to alant
  • QA Check set to Info Needed

Thanks for opening this issue. Can you confirm that the packages were not installed at all? and that you are not referring to a failure to upgrade them.

I’m assigning this to Alan who’s the primary author of this feature. We want to work on improving this feature in 2016 so if this is has no security implications and is simple to fix, maybe we could include this in our plans.

Alan, what do you think?

#2 Updated by intrigeri 2015-11-30 14:20:48

> Last week, deb.tails.boum.org was down for a while. This meant that additional software installation always failed, even for packages that had been cached.

That’s not supposed to happen unless locally cached APT indices have expired (i.e. if this Tails has not been started for more than a week or so).

> On any download failure, tails should fall back to cached packages.

At first glance, it sounds like a bad idea to allow an active network adversary to force us to bypass APT security.

#3 Updated by andrewgdotcom 2015-11-30 14:34:24

> That’s not supposed to happen unless locally cached APT indices have expired (i.e. if this Tails has not been started for more than a week or so).

Ah, I think it was over a week…

>> On any download failure, tails should fall back to cached packages.
>
> At first glance, it sounds like a bad idea to allow an active network adversary to force us to bypass APT security.

Are we bypassing security though? We’re using out of date packages, fair enough, but they’re packages we’ve installed before. Perhaps a warning…?

Andrew.

#4 Updated by intrigeri 2015-12-01 02:42:42

>> At first glance, it sounds like a bad idea to allow an active network adversary to force us to bypass APT security.

> Are we bypassing security though? We’re using out of date packages, fair enough, but they’re packages we’ve installed before.

Yes, this would bypass security: it would allow an active network adversary to hide security updates from us. Anyone who wants to get the bigger picture, see the research behind http://theupdateframework.com/ :)

> Perhaps a warning…?

On this ticket I’ll try to provide tech insight that I’m not sure will be taken into account otherwise, but I’ll let others think about solutions, so I won’t comment about this one.

#5 Updated by andrewgdotcom 2015-12-01 04:47:02

On 01/12/15 10:42, redmine@labs.riseup.net wrote:
>
>> Are we bypassing security though? We’re using out of date packages,
>> fair enough, but they’re packages we’ve installed before.
>
> Yes, this would bypass security: it would allow an active network
> adversary to hide security updates from us. Anyone who wants to get
> the bigger picture, see the research behind
> http://theupdateframework.com/ :)
>
>> Perhaps a warning…?
>
> On this ticket I’ll try to provide tech insight that I’m not sure
> will be taken into account otherwise, but I’ll let others think about
> solutions, so I won’t comment about this one.

Fair enough, I’ll just note that under the same circumstances (update
server unavailable) the tails base system still boots into a working
state. If an adversary was capable of blocking updates to ensure a
security hole stayed open, this would be a much more profitable route. ;-)

Andrew.

#6 Updated by intrigeri 2015-12-01 13:07:54

> Fair enough, I’ll just note that under the same circumstances (update server unavailable) the tails base system still boots into a working state.

When the Tails update server is unavailable, this situation will display a warning advising to check our homepage for upgrades.

#7 Updated by andrewgdotcom 2015-12-02 04:38:21

On 01/12/15 21:07, redmine@labs.riseup.net wrote:
> Issue Bug #10694 has been updated by intrigeri.
>
>> Fair enough, I’ll just note that under the same circumstances
>> (update server unavailable) the tails base system still boots into
>> a working state.
>
> When the Tails update server is unavailable, this situation will
> display a warning advising to check our homepage for upgrades.

Yes. And if an additional-software update fails due to an unavailable
deb server, I agree a similar warning is warranted. I’m just not sure
why additional software should be subject to stricter security
conditions than the base system, especially since additional software
already comes with a health warning.

And in this case, unavailability of tails.boum.org caused the entire
additional-software process to fail, not just for those packages hosted
on tails.boum.org. This implies that if just one server in the
sources.list goes down it would (temporarily) deinstall all additional
software on all copies of tails, everywhere. This strikes me as fragile.

Andrew.

#8 Updated by BitingBird 2016-06-27 09:10:35

  • Affected tool set to Additional Software Packages

#9 Updated by BitingBird 2016-07-01 14:22:34

  • Status changed from New to Confirmed

#10 Updated by Anonymous 2018-01-18 17:20:47

#11 Updated by alant 2018-07-27 21:56:13

  • Status changed from Confirmed to Rejected
  • Assignee deleted (alant)
  • QA Check deleted (Info Needed)

ASP are now always installed offline, only the upgrade would fail.