Re: [Tails-dev] [Freepto] (senza oggetto)

Delete this message

Reply to this message
Author: intrigeri
Date:  
To: Patrick Schleizer
CC: Everything about freepto, The Tails public development discussion list
Subject: Re: [Tails-dev] [Freepto] (senza oggetto)
Hi,

Patrick Schleizer wrote (16 Sep 2014 01:02:28 GMT) :
> intrigeri:
>> Patrick Schleizer wrote (03 Jul 2014 14:55:57 GMT) :


>> bootclockrandomization
>>
>> Randomizes clock when systems boots by adding a few seconds and
> nanoseconds to enforce the design goal, that the host clock and
> Gateway/Workstation clock should always slightly differ (even before
> secure timesync succeeded!) to prevent time based fingerprinting /
> linkablity issues. For better anonymity and privacy.


This conflicts with any other mechanism that sets the time (e.g.
GNOME time sync, ntp, etc.), right? If so, creating (and maintaining!)
the list of conflicting packages within the Debian archive seems to be
a daunting task to me.

Also, note that:

> NEW_TIME="$(( $OLD_UNIXTIME $PLUS_OR_MINUS $DELAY ))"


... is a bit misleading, as the time spend between when $OLD_UNIXTIME
was computed and when you're doing that is implicitly added to the
delay. I would instead compute random numbers first, and then run
`date --set', passing it shell command interpolation $(..) to get the
current time.

> Re-usable for Tails should be much simpler than uploadable to Debian.
> Even if a package would only contain a single config file, which was
> useful for Tails, it could be re-used in Tails.


Definitely.

> Here are some packages that may be useful and easily re-usable for Tails.


Thanks for the list, I've looked at a few ones.

> - timezone-utc


We rely on live-config for that.

> - tcp-timestamps-disable
> - ipv4-forward-disable
> - ipv6-disable


Wow, I'm not sure I'd be interested in going *that* far into using
Debian packages for everything. The overhead is huge just to create
a one-liner file. As I see it, the main use of moving this kind of
stuff into Debian packages is that all interested distros can share
a single source tree for a given feature. It's mainly interesting if
one expects this source tree to evolve in the future, otherwise, one
can as well copy'n'paste the line in the right place and avoid the
overhead. Do you expect that specific line to need change in
the future?

(A middle-ground could be to either pack a bunch of similar tweaks
into a single package, or to use Puppet recipes.)

> - poweroff-passwordless


For *all* users, really?

> - damngpl [ _maybe_ useful for https://labs.riseup.net/code/issues/5548 ]


Interesting, indeed.

> - curl-scripts


I don't think we have anything that needs that.

> - power-savings-disable-in-vms


I've no idea where exactly, but this one would be worth
upstreaming somehow.

> - pkg-manager-longer-timeouts


I'm curious, as I've never seen this needed in Tails. Did you see it
happen on Whonix?

>> or would be ready in your opinion to
>> be uploaded to Debian?


> Since packages that contain only config files or worse, only a single
> config file are not allowed, this will be much fewer.


Indeed. I think a higher-level view is needed, to pack enough related
stuff together in a way that makes sense for the Debian archive.

> Maybe let's start with a really simple package to get
> me bootstrapped.


Seems sound :)

> That I will polish for Debian derivatives or even Debian itself. The
> bootclockrandomization package is kinda simple.


As explained above, it actually seems to be one of the hardest ones.

> Should I port to systemd first?


The sysvinit compatibility should work just fine, so that's not
a blocker IMO.

Cheers,
--
intrigeri