[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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. :)

>>> 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


(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,

Happy new year!

Reply to: