Patrick Schleizer wrote (25 Sep 2014 19:32:47 GMT) : > intrigeri:
>> 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? > Depends on what you mean by you mean by conflicting. It randomizes the
> clock only at boot, that's all, and other time keeping mechanisms are
> free to adjust it from there. Having bootclockrandomization co-installed
> with NTP is probably not very useful, indeed. Because NTP leaks the
> local system clock. [1] But would that justify "Conflicts: ntp"?
I'm unsure.
On the one hand, if the security this package can guarantee is put
very clearly, then it probably doesn't need any conflict. I think this
part of the package description is overly optimistic, and may lead the
user to believe that installing the package will always achieve
a security goal it cannot guarantee:
This is useful 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.
Now, once the actual realistic goal of this package is clearly put, it
might be that it seems less useful to upload it in a general purpose
distribution that can be installed in so many ways that prevent the
package from reaching its only goal. Or maybe not :)
I guess some thinking will be needed on a case-by-case basis.
>> If so, creating (and maintaining!)
>> the list of conflicting packages within the Debian archive seems to be
>> a daunting task to me. > Creating the list could be simplfiied thanks to the "packagesearch"
> package as well as the debtag "use::timekeeping"?
Yes. Let's assume that this list won't ever be perfect anyway.
> Maintaining the list,
> well, are new NTP like time keeping packages added to the Debian archive
> every year?
I doubt it, which surely helps. But maybe I should clarify what I had
in mind.
My point is about carrying the responsibility that if users rely on
$PACKAGE_1 to provide them $SECURITY, then when $PACKAGE_2 is
introduced or changes its behaviour in a way that breaks the way
$PACKAGE_1 provides $SECURITY, how long is an acceptable a delay for
the maintainers of $PACKAGE_1 to notice and fix the problem? How do
they monitor the archive and notice such breakage in the first place?
>>> - 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. > Not sure what you mean by overhead.
Overhead:
* get the packaging good enough for Debian
* keep this packaging up-to-date with Debian standards and best
practices
* find a sponsor every time until you get DM credentials
* handle bug reports
* handle upgrades, deprecation, new conflicts etc. properly
* very low s/n ration for the bytes pushed to the Debian
infrastructure
Things almost always look easy to maintain when initially packaged.
And then it gets hairy :)
> What I also find nice, that design documentation can be in the vicinity
> of the code itself.
Agreed, it's nice to have.
>> 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. > Yes. And more. > - source code got easier to understand: > As far as Whonix is concerned, I have the feeling that this kind of
> modularity helps other coders to now better grasp what the heck Whonix
> is actually doing and how compared to the past, where there where just
> three giant folders (whonix_shared(|gateway|workstation)/etc/... and so
> forth).
Agreed. As long as learning how to package stuff properly for Debian
doesn't become another stumbling block to contribute (which would be
my fear as far as Tails and Freepto are concerned). OTOH, it's not
necessarily harder than learning to configure a live-build tree.
> More people working on Whonix now.
I'm glad to read this :)
(Snipping other advantages of packaging stuff, that I fully agree with.)
>>> - power-savings-disable-in-vms
>>
>> I've no idea where exactly, but this one would be worth
>> upstreaming somehow. > It's also quite a simple package. What about just a separate package
> power-savings-disable-in-vms as is? Would be a good start?
I meant upstreaming in the piece of software that should handle this
automatically, instead of requiring every distro to carry an
additional package, and every user to install it.
