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

Re: When does a derivative become a derivative? Whonix integration into Debian?

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. 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. Personally, I really dislike when programs
install full configuration files containing documentation for each
option in /etc and I would welcome tor, privoxy etc being fixed in
this regard.

> My thought was, what would happen if one of them no longer be
> essential/required in future.

Good point.

> Thanks for mentioning. We're only using the
> /usr/lib/update-notifier/apt-check utility. It simply outputs "x
> packages can be updated, y are security updates" (x and y are numbers).
> Is there a replacement for it? In any case, I'll probably find some
> solution in the next days.

Not sure, I would suggest talking to the maintainer and the maintainer
of the proposed update-notifier replacement:


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

> Maybe that's a point where a project stops being a blend and
> becomes a derivative?


> 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 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. tlsdate extracts timestamps from the
TLS handshake of a HTTPS or TLS connection and so would work over tor
and TCP.


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


The rest sound like useful additions to tlsdate if it doesn't already
support them.



Reply to: