Re: When does a derivative become a derivative? Whonix integration into Debian?
Hi,
thank you very much for your thoughts, Paul!
Paul Wise:
> On Mon, Dec 16, 2013 at 1:06 PM, adrelanos wrote:
>> Well, Whonix is packaged already. Just not sure you like the way it's
>> packaged. Would it be accepted for a blend?
>
> I haven't looked at how it is packaged yet. All the blends packaging
> obviously needs to be policy compliant; not modifying conffiles of
> other packages and so on.
I hope this isn't a deal breaker? That is unfortunately the essence of
what Whonix is doing. We're for example modifying /etc/tor/torrc (using
config-package-dev [in debian, great tool]). The only way of not doing
that would be implementing /etc/tor.d upstream first, which would have
to be done in C, which is outside my skill set. My choices boiled down
to not creating a derivative or having one which comes with all the
recommended privacy enhanced settings.
Is this "not modifying conffiles of other packages" written in stone or
open for relaxation for blends?
>> Could you comment in meanwhile on our debian/control file? [1]
>> (Why do we depend on package x? Comments are here. [2])
>
> Some of the stuff being depended on is priority essential/required and
> therefore is always installed.
My thought was, what would happen if one of them no longer be
essential/required in future. Also lintian doesn't complain.
> update-notifier-common is scheduled to be removed:
>
> http://packages.debian.org/unstable/update-notifier-common
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.
> 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.
> I'd likewise suggest not recommending any default applications unless
> they specifically help with privacy.
Some help with privacy, such as mat and its dependencies. Others are
recommendations because we believe they're a great choice for various
reasons. Maybe that's a point where a project stops being a blend and
becomes a derivative? It's a "we respect Debian and wouldn't exist
without them, we don't 100% agree with their default installed
applications, we believe our users, which often use Linux for the first
time or just switched to Linux are better suited with applications that
they already liked on Windows, such as VLC. This is what we think is
best for this target group. Artistic freedom." thing.
> I wonder if there are any apps that aren't compatible with the Whonix
> setup that should be conflicted with.
I don't think so. (There are some that conflict with our goals, such as
NTP, which doesn't work over Tor, because Tor is TCP (+some DNS) only
and NTP is UDP only and due to authentication issues, but it's not as
bad as requiring to protect an advanced user from itself. Means, when
you install any Debian packages in Whonix it never breaks Whonix. At
least it didn't happen until now.)
> I believe general language stuff in Debian is handled by the installer.
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.
> I believe that for accessibility stuff the accessibility team aim to
> just get the needed changes into the respective desktops by default.
>> Would probably be better if Whonix was split into many smaller packages.
>
> Agreed.
>> Things like sdwdate [3] (which is an NTP alternative) would be better in
>> separate packages and maybe even be useful for general Debian users.
>
> 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]
Advantages:
- distributed trust (pal, neutral and foe pool; thresholds; builds
median out of 3 servers) [3]
- 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)
- loads of hooks
-- can run a pre script before trying to fetch
-- can run a prerequisite script before trying to connect, this could be
for example a connection checker. In case of Whonix, it asks Tor's
control port if Tor is already ready to receive connections and starts
as soon as Tor is ready. Waits otherwise. And it's possible to write an
optional GUI informing the user about the current time.
-- hook for successfully setting the time
-- hook for failing to set the time
-- hook for progress bar
Difference (not sure it's an advantage):
- written in bash instead of C
- I can make it better! :)
> http://packages.debian.org/unstable/tlsdate
>
> If you still want it in Debian, then take a look at our intro to
> getting things in:
>
> http://mentors.debian.net/intro-maintainers
>> We're also dropping a few scripts in /etc/profile.d [4], since I am not
>> aware of any other way to implement that functionality. Is that against
>> debian/blends policy? If this isn't the right place, what would be the
>> correct place to ask about such policy questions?
>
> If the default browser isn't x-www-browser somewhere, that is probably
a bug.
The whole default browser thing on Linux distributions is a bug. [4]
Our default "browser" is Whonix Confirm Open [5]. On Whonix-Gateway
kwrite is our default "browser" because Whonix-Gateway is not supposed
to open html files/links. On Whonix-Workstation, the user gets a:
"The following (link|file) will be opened in (Tor Browser|kwrite). Continue?
(Be careful if Tor Browser is already running as your activities might
get linked.|)
Yes | No"
This isn't possible to implement without setting the BROWSER environment
variable. Since there is no /etc/environment.d/ (debian-devel didn't
like my suggestion), I can't think of any better way [as a distro] of
setting environment variables other than /etc/profile.d. This won't
interfere with the user, because the user is free to overrule the
BROWSER environment variable in bashrc or so.
> Power saving thing sounds like a workaround something else that should
> do that by default.
This is a small feature for VMs. We disable power saving inside VMs (not
useful to turn of the virtual monitor, doesn't safe any energy and is
confusing) and otherwise leave it default. I can't think of any other
way implementing that.
> Not sure about the other things, haven't had time to look at them but
> I think the FreeDesktop autostart stuff might be more appropriate.
FreeDesktop autostart is very cool, but it doesn't work for CLI stuff
and we're also supporting CLI users.
> In general debian-devel/debian-mentors are useful places to ask policy
> questions.
>
>> That shouldn't be an issue for a Whonix pure blend. (not pre-installing
>> OpenSSH)
>
> There are other files that are per-machine too. dbus/systemd
> machine-id files come to mind
Eh. We're even sharing the dbus machine id among all Whonix users to
reduce uniqueness of the system. Although dbus machine id to my
knowledge never leaked over networks.
> Debian hasn't really done much work in
> this area so it is a bit of an unknown.
I would like to help reporting a few of them. Although I haven't spot
lots yet. One thing is /etc/passwd /etc/passwd-. Using defaults
passwords and asking the user to change them is a bit sub optimal.
All the best,
adrelanos
[1] https://www.whonix.org/wiki/Dev/TimeSync
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%23687166
[3] https://www.whonix.org/wiki/Dev/TimeSync#sdwdate
[4] http://blog.codef00.com/2011/02/18/the-default-browser-on-linux-debacle/
[5]
https://github.com/Whonix/Whonix/blob/master/whonix_shared/usr/lib/whonix/confirm_open
Reply to: