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:
http://packages.qa.debian.org/g/gnome-packagekit.html
http://packages.qa.debian.org/u/update-notifier.html
>> 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?
Indeed.
> 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.
http://packages.debian.org/sid/tlsdate
> - 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
The rest sound like useful additions to tlsdate if it doesn't already
support them.
--
bye,
pabs
http://wiki.debian.org/PaulWise
Reply to: