Re: When does a derivative become a derivative? Whonix integration into Debian?
Paul Wise:
> On Tue, Dec 17, 2013 at 1:14 AM, adrelanos wrote:
>
>> Is this "not modifying conffiles of other packages" written in stone or
>> open for relaxation for blends?
>
> Set in stone.
A pity.
> The tor.d directory would need to be implemented before
> Whonix could become a blend.
> I would suggest filing a bug with tor
> upstream about this.
Already open. :)
https://trac.torproject.org/projects/tor/ticket/1922
>>> I'm not sure about using specific GTK+ engines, that doesn't seem related.
>>
>>> I would suggest relying on the existing metapackages for KDE/GNOME
>>> desktops rather than creating new ones, unless there are some privacy
>>> implications?
>>
>> There are privacy, space and usability implications.
>
> Hmm, the privacy implications are surprising to me.
For example, if you were to ask on the tor-talk mailing list whether
KMail or Thunderbird+TorBirdy is better in context of privacy/anonymity,
I am quite sure no one would argue for KMail. Same for Konquerer vs Tor
Browser. And more.
>> We're not using Debian installer. Our premade VM images can be imported
>> and are ready to go. That's why having language packages makes sense,
>> unless I missed a better solution.
>
> There are already the task-* language packages, which are used by the
> installer and can also be installed.
I see. Didn't put much time into that. The following is derived (some
time ago) from Tails' package selection.
Package: whonix-workstation-langpack-common
Recommends: iceweasel-l10n-all | firefox-l10n-all, ttf-dejavu,
ttf-liberation, locales-all,
ttf-kacst, ttf-farsiweb, scim-pinyin, scim-tables-zh, scim-uim,
ttf-arphic-ukai, ttf-arphic-uming,
culmus, libfribidi0, ttf-indic-fonts, scim-anthy, ttf-khmeros,
ttf-unfonts-core, ttf-lao,
ttf-thai-tlwg, xfonts-intl-chinese, xfonts-wqy, xfonts-bolkhov-koi8r-75dpi,
xfonts-bolkhov-koi8r-misc, xfonts-cronyx-koi8r-100dpi
Not sure why Tails explicitly installs these packages. Any idea?
>>> I wonder if tlsdate would be an appropriate alternative to sdwdate?
>>
>> Unfortunately not.
>>
>>> Are there any advantages of sdwdate?
>>
>> Clock is crucial for anonymity. [1] We can't use insecure NTP. [2]
>
> Er, I said tlsdate not ntpdate.
I see. Adding that sentence ad this point added confusion I saw that
after re-reading it now.
> tlsdate extracts timestamps from the
> TLS handshake of a HTTPS or TLS connection and so would work over tor
> and TCP.
>
> http://packages.debian.org/sid/tlsdate
>
Yes.
(So does sdwdate.)
>> - randomized interval to avoid fingerprinting (not always running at the
>> same time, thus not revealing one is an sdwdate user; presupposes being
>> a Tor user)
>
> Not sure but it sounds like the -j option of tlsdate can do that:
>
> http://manpages.debian.net/man/0/tlsdated
Dunno. I mailed Jacob.
> The rest sound like useful additions to tlsdate if it doesn't already
> support them.
Sure. In an ideal world I would have submitted patches to tlsdate
instead. Since I haven succeeded picking the C programming language yet,
I created a rewrite in bash. Not a reason against inclusion into Debian,
though?
Happy new year!
Reply to: