splitting Whonix (anonymous operating system) into multiple packages for possible reuse of parts by QubesOS TorVM

[Patrick Schleizer]

Hi!

I made some process splitting Whonix into multiple packages. Not
published yet. Still needs a lot packaging / testing.

Almost every function Whonix implements, has been implemented in a
separate package. Most Whonix specific code has been transformed into
more general form, so it can possibly be used by other projects such as
QubesOS TorVM, Debian, etc.

I kept inclusion into Debian (as well as a bit rpm) in mind. Some
packages are unlikely to join Debian, others stand chances, I think.

Using very simple make files, using very simple packaging. Files in
package_source_folder/usr/bin/xxx will get installed to /usr/bin/xxx on
actual system. Here is an already published example package:
https://github.com/Whonix/sdwdate

No reason to re-use all packages. They have little dependencies on each
other, are made as standalone as possible. You can pick and choose what
you like.

Below is the temporary list of packages names. Hopefully package names
are descriptive, telling you what they are doing without explanation. A
few less descriptive names have descriptions inside [].

Any suggestions for package names without "Tor" in their name? I don't
want to challenge the Tor Project, they are quite adamant about this:
https://www.torproject.org/docs/trademark-faq.html.en - (Hence the name
"anonymizer-config-gateway", what would be better called
"anonymizer-config-tor".) What to call a Tor Browser Updater, if not
torbrowser-updater?

Before I go ahead and create loads of git remote repositories... Now
would be a good time to suggest better/changed package names as well as
combination/split of functionality.

Cheers,
Patrick

anon-apt-sources-list [debian stable sources.list]
anon-apt-sources-tpo [torproject stable sources.list]
anon-banned-packages [packages better not installed on an anon distro]
anon-base-files
anon-dist-chroot-sanity-checks [scripts running inside chroot during build]
anon-gateway-dhcp-conf
anon-gateway-dns-conf
anon-gateway-firewall [Not sure if we can make a general one or if this
has to become whonix-gateway-firewall]
anon-gateway-network-conf
anon-gateway-sdwdate-conf
anon-gpg-tweaks [gpg.conf for improved privacy and security]
anon-gw-base-files
anon-gw-chroot-upgrade-tor
anon-gw-clearnet-user [creates clearnet user on gateway]
anon-gw-first-run-notice ["do not use this gateway as a workstation",
"do not show again"]
anon-gw-kde-startmenu [suggested kde start menu entries useful for a gateay]
anon-iceweasel-warning ["do not use iceweasel for anything other than
downloading Tor Browser unless you know what you are doing"]
anon-icon-pack
anon-kde-streamiso [kde global proxy settings]
anon-meta-packages [recommended packages to have installed]
anon-mixmaster [mixmaster config to make it work over Tor]
anon-torchat [torchat config to make it work in a workstation]
anon-shared-chroot-fix-grub
anon-shared-chroot-inst-linux-486
anon-shared-chroot-inst-linux-686
anon-shared-chroot-inst-linux-amd64
anon-shared-chroot-log-build-version
anon-shared-chroot-remember-sources [remember sources.list used for
install for later download of gpl sources]
anon-shared-chroot-upgrade-torsocks
anon-shared-chroot-vrms [check, that there are no contrib, non-free
packages installed]
anon-torchat [torchat in anon distribution without Tor over Tor]
anon-workstation-dns-conf
anon-workstation-firewall
anon-workstation-network-conf
anon-ws-base-files
anon-ws-chroot-inst-tb [chroot script for installing Tor Browser while
building]
anon-ws-kde-startmenu [start menu favorites]
anon-ws-kde-startmenu
anonymizer-config-gateway [torrc etc.]
anonymizer-helper-scripts [check Tor enabled, check Tor bootstrap
status, etc.]
apparmor-profile-anondist [apparmor-profile rules required when having
apparmor installed to work around a few diverted files]
apparmor-profile-torbrowser
... more apparmor profiles to come [https://www.whonix.org/wiki/AppArmor]
apt-longer-timeouts
apt-no-autoupdate [to prevent fingerprinting, no running at predictable
times, auto update check at randomized intervals is implemented in
whonixcheck]
bootclockrandomization [prevent time based fingerprinting by unlinking
host/vm clock at boot]
console-autologin [usability]
control-port-filter [we discussed this on this list a while ago]
curl-scripts [lib: curl-prgs for bash; curl exit codes to human readable
error messages]
damngpl [http://www.finnie.org/software/damngpl/damngpl]
desktop-icons-gateway
desktop-icons-workstation
dummytor [run Tor Browser without Tor over Tor and without modifications
right after download and extract from torproject.org; prevent Tor over
Tor by installing Tor on the workstation;
https://www.whonix.org/wiki/Dev/Dummy_Tor]
grub-enable-apparmor [+ verbose messages while booting]
ipv4-forward-disable [make sure no leaks]
ipv6-disable [don't have IPv6 firewall rules yet, very limited Tor IPv6
support]
kde-apper-no-autoupdate [to prevent fingerprinting, no running at
predictable times, auto update check at randomized intervals is
implemented in whonixcheck]
kde-dolphin-menubar-enable [usability preference only for new/first time
users; can be changed by the user]
kde-kgpg-tweaks [usability preference only for new/first time users; can
be changed by the user + keyserver changed]
kde-konsole-unlim-scrollback [usability preference only for new/first
time users; can be changed by the user]
kde-lowfat [performance tweaks only for new/first time users; can be
changed by the user]
kde-mouse-doubleclick [usability preference only for new/first time
users; can be changed by the user]
kde-no-move-max-win [prevent accidentally maximizing browser window,
because Tor Browser hasn't sorted out related fingerprinting issues yet]
kde-sounds-off [usability preference only for new/first time users; can
be changed by the user]
kdm-autologin [usability preference only for new/first time users; can
be changed by the user]
kmix-disable-autostart [usability preference only for new/first time
users; can be changed by the user]
knetattach-hide [not useful (?) in context of anonymity distributions,
installed as dependency]
leaktest-gateway
leaktest-workstation
msgcollector [gets messages from whonixcheck, timesync,
torbrowser-updater, shows them in terminal and/or X]
open_link_confirmation [ask for confirmation before opening a link to
prevent linking activities, configurable]
pidgin-improved-privacy
poweroff-passwordless [usability only]
powersaving-disable [usability only [not useful inside VMs, up to the host]
rads [RAM Adjusted Desktop Starter
https://www.whonix.org/wiki/Desktop#RAM_Adjusted_Desktop_Starter]
scurl [small simple curl https-only wrapper]
sdwdate
sdwdate-plugin-anon-dist-con-check [checks if Tor is enabled + no
package manager is running + Tor is fully bootstrapped]
sdwdate-plugin-anon-dist-streamiso
shared-folder-help [usability]
swap-file-creator [usability]
swappiness-lowest [usability]
timesanitycheck
timesync [sdwdate plugin; GUI and monitor for sdwdate,
bootclockrandomzation and timesanitycheck]
timezone-utc
torbrowser-default-browser [use Tor Browser as default browser]
torbrowser-starter
torbrowser-updater
tor-ctrl
torsocks-remove-ld-preload [lib]
uwt [for stream isolation]
uwtwrapper-apt-get
uwtwrapper-aptitude
uwtwrapper-curl
uwtwrapper-git
uwtwrapper-gpg
uwtwrapper-mixmaster
uwtwrapper-rawdog
uwtwrapper-ssh
uwtwrapper-wget
vbox-disable-timesync [to prevent conflicts with sdwdate]
whonix-base-files [dpkg origins, motd...]
whonixcheck [making anoncheck of it perhaps later]
whonix-developer-meta-files [scripts for signing, compressing,
uploading, ...]
whonix-gw-kde-desktop-conf [kde folderview + desktop background]
whonix_initializer [https://www.whonix.org/wiki/Verifiable_Builds]
whonix-legacy [support for upgrading older Whonix versions to newer]
whonix_repository [tool for enabled/disabling Whonix's stable, testers,
developers APT repository]
whonixsetup [On first run. Connection wizard. Enable Whonix's APT
Repository? Do not automatically connect to the public Tor network to
aid users who want to hide Tor from their ISP.
(https://www.whonix.org/wiki/Hide_Tor_and_Whonix_from_your_ISP)]
whonix-ws-kde-desktop-conf [kde folderview + desktop background]
xchat-improved-privacy

[Marek Marczykowski-Górecki]

Below some (I hope useful) comments.

>
> Cheers,
> Patrick
>
> anon-apt-sources-list [debian stable sources.list]

On standard debian /etc/apt/sources.list isn't owned by any package. Is it
really good idea to change that? IMO its better to provide only
sources.list.d/ files.

> anon-apt-sources-tpo [torproject stable sources.list]
> anon-banned-packages [packages better not installed on an anon distro]
> anon-base-files
> anon-dist-chroot-sanity-checks [scripts running inside chroot during build]

Is that chroot used only for building? If so, perhaps better
anon-dist-build-sanity-checks?

> anon-gateway-dhcp-conf
> anon-gateway-dns-conf
> anon-gateway-firewall [Not sure if we can make a general one or if this
> has to become whonix-gateway-firewall]

This can be rather hard to reuse, so probably better whonix-gateway-firewall.

> anon-gateway-network-conf
> anon-gateway-sdwdate-conf

Really that level of splitting is a good idea? I don't know details of Whonix
configs, but I don't see any use case where e.g. anon-gateway-dhcp-conf will
be really useful without matching anon-gateway-network-conf. Perhaps
"anon-gateway-configs" would be better (save some maintenance effort)?

> anon-gpg-tweaks [gpg.conf for improved privacy and security]
> anon-gw-base-files
> anon-gw-chroot-upgrade-tor
> anon-gw-clearnet-user [creates clearnet user on gateway]
> anon-gw-first-run-notice ["do not use this gateway as a workstation",
> "do not show again"]
> anon-gw-kde-startmenu [suggested kde start menu entries useful for a gateay]

IMHO its better to stick to one prefix - anon-gw or anon-gateway.

> anon-iceweasel-warning ["do not use iceweasel for anything other than
> downloading Tor Browser unless you know what you are doing"]
> anon-icon-pack
> anon-kde-streamiso [kde global proxy settings]
> anon-meta-packages [recommended packages to have installed]
> anon-mixmaster [mixmaster config to make it work over Tor]
> anon-torchat [torchat config to make it work in a workstation]
> anon-shared-chroot-fix-grub
> anon-shared-chroot-inst-linux-486
> anon-shared-chroot-inst-linux-686
> anon-shared-chroot-inst-linux-amd64
> anon-shared-chroot-log-build-version
> anon-shared-chroot-remember-sources [remember sources.list used for
> install for later download of gpl sources]
> anon-shared-chroot-upgrade-torsocks
> anon-shared-chroot-vrms [check, that there are no contrib, non-free
> packages installed]

Same here about chroot.

> anon-torchat [torchat in anon distribution without Tor over Tor]

> anon-workstation-dns-conf
> anon-workstation-firewall
> anon-workstation-network-conf

Merge to anon-ws-configs (network-configs?)

> anon-ws-base-files
> anon-ws-chroot-inst-tb [chroot script for installing Tor Browser while
> building]
> anon-ws-kde-startmenu [start menu favorites]
> anon-ws-kde-startmenu

anon-ws vs anon-workstation.

> anonymizer-config-gateway [torrc etc.]
> anonymizer-helper-scripts [check Tor enabled, check Tor bootstrap
> status, etc.]

anon-proxy-*?

> apparmor-profile-anondist [apparmor-profile rules required when having
> apparmor installed to work around a few diverted files]
> apparmor-profile-torbrowser
> ... more apparmor profiles to come [https://www.whonix.org/wiki/AppArmor]
> apt-longer-timeouts
> apt-no-autoupdate [to prevent fingerprinting, no running at predictable
> times, auto update check at randomized intervals is implemented in
> whonixcheck]
> bootclockrandomization [prevent time based fingerprinting by unlinking
> host/vm clock at boot]

Those two:

> console-autologin [usability]
> control-port-filter [we discussed this on this list a while ago]

IMHO have little sense as separate packages - so simple its more work to reuse
that package compared to simply do this manually.
So perhaps better merge to some other package containing configs
(anon-gw-configs? anon-ws-configs? anon-common-configs?).

> curl-scripts [lib: curl-prgs for bash; curl exit codes to human readable
> error messages]
> damngpl [http://www.finnie.org/software/damngpl/damngpl]
> desktop-icons-gateway
> desktop-icons-workstation
> dummytor [run Tor Browser without Tor over Tor and without modifications
> right after download and extract from torproject.org; prevent Tor over
> Tor by installing Tor on the workstation;
> https://www.whonix.org/wiki/Dev/Dummy_Tor]

anon-ws-disable-stacked-tor?

> grub-enable-apparmor [+ verbose messages while booting]


> ipv4-forward-disable [make sure no leaks]
> ipv6-disable [don't have IPv6 firewall rules yet, very limited Tor IPv6
> support]

Really separate packages? Those two are one-liners...

Underscores in package name instead of dashes as other packages?

Underscore?

> whonix-legacy [support for upgrading older Whonix versions to newer]
> whonix_repository [tool for enabled/disabling Whonix's stable, testers,
> developers APT repository]

Underscore?

> whonixsetup [On first run. Connection wizard. Enable Whonix's APT
> Repository? Do not automatically connect to the public Tor network to
> aid users who want to hide Tor from their ISP.
> (https://www.whonix.org/wiki/Hide_Tor_and_Whonix_from_your_ISP)]
> whonix-ws-kde-desktop-conf [kde folderview + desktop background]
> xchat-improved-privacy
>

--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[Patrick Schleizer]

Marek Marczykowski-Górecki:

>> anon-apt-sources-list [debian stable sources.list]
>
> On standard debian /etc/apt/sources.list isn't owned by any package.
> Is it really good idea to change that? IMO its better to provide
> only sources.list.d/ files.

This is more a question of distribution maintenance strategies rather
than naming. Of course, this package won't be a dependency for other
anonymity distributions. The more standard way would indeed be leaving
/etc/apt/sources.list alone and using sources.list.d/. The idea of
managing /etc/apt/sources.list for the user is, the Whonix distro
maintainers can decide when it is a better "change stable to oldstable",
"keep wheezy as long as we need to work out [eventual!] issues that
would break during upgrade to jessie" and such.

>> anon-apt-sources-tpo [torproject stable sources.list]

Recommended [not required] for building. Recommended [not required] to
have installed. To install torproject stable sources.list or not is
another question of distribution maintenance strategies. Some time ago
tor/torsocks in torproject's repository was newer/more bug free/more
functional compared to the version in Debian.

>> anon-banned-packages [packages better not installed on an anon
>> distro] anon-base-files anon-dist-chroot-sanity-checks [scripts
>> running inside chroot during build]
>
> Is that chroot used only for building?

Recommended only for building, but useful to ask the user to run as for
debugging, as integrity check, when a hdd hardware failure or something
like that is suspected.

> If so, perhaps better anon-dist-build-sanity-checks?

You tell me. :)

>> anon-gateway-dhcp-conf anon-gateway-dns-conf anon-gateway-firewall
>> [Not sure if we can make a general one or if this has to become
>> whonix-gateway-firewall]
>
> This can be rather hard to reuse, so probably better
> whonix-gateway-firewall.

Done.

>> anon-gateway-network-conf anon-gateway-sdwdate-conf
>
> Really that level of splitting is a good idea?

In this case the anon-gateway-sdwdate-conf package (which is just a
config file saying "don't run sdwdate on gateway so often, because we
haven't finished sclockadj [https://github.com/Whonix/Whonix/issues/169]
yet" hopefully won't be required for much longer.

> I don't know details of Whonix configs, but I don't see any use case
> where e.g. anon-gateway-dhcp-conf will be really useful without
> matching anon-gateway-network-conf. Perhaps "anon-gateway-configs"
> would be better (save some maintenance effort)?

I see your point.

anon-gateway-dhcp-conf only does "dhcp: don't touch /etc/resolv.conf!
(because we don't need functional system DNS on gateway for gateway,
because all gateway network applications are using stream isolation [tor
socks proxy settings or uwtwrapper] anyway)" Now, there are a few users
who disagree with me. I want to luxory of being able to say "sudo
apt-get remove anon-gateway-dhcp-conf" then.

I guess when I published the packages, there may indeed be some that
don't justify a separate package.

>> anon-gpg-tweaks [gpg.conf for improved privacy and security]
>> anon-gw-base-files anon-gw-chroot-upgrade-tor anon-gw-clearnet-user
>> [creates clearnet user on gateway] anon-gw-first-run-notice ["do
>> not use this gateway as a workstation", "do not show again"]
>> anon-gw-kde-startmenu [suggested kde start menu entries useful for
>> a gateay]
>
> IMHO its better to stick to one prefix - anon-gw or anon-gateway.

Agreed.

>> anon-shared-chroot-fix-grub anon-shared-chroot-inst-linux-486
>> anon-shared-chroot-inst-linux-686
>> anon-shared-chroot-inst-linux-amd64
>> anon-shared-chroot-log-build-version
>> anon-shared-chroot-remember-sources [remember sources.list used
>> for install for later download of gpl sources]
>> anon-shared-chroot-upgrade-torsocks anon-shared-chroot-vrms [check,
>> that there are no contrib, non-free packages installed]
>
> Same here about chroot.

Those are indeed exclusively required for building. Please restate your
suggestion on this point after me sharing additional information.

>> anon-torchat [torchat in anon distribution without Tor over Tor]
>

>> anon-workstation-dns-conf [/etc/resolv.conf only saying "nameserver
>> 192.168.0.10". DNS not explicitly configured to use stream
>> isolation, can use the Tor transparent proxying feature. (Not a
hypothetical question some users are asking:) Want to disable
transparent proxying? Uninstall anon-workstation-dns-conf on the
workstation and xxx on the gateway then.]
>> anon-workstation-firewall
[https://github.com/Whonix/Whonix/blob/Whonix8/man/whonix_workstation/whonix_firewall.8.ronn
; the plan is to not install it by default, and users who install it,
will get it enabled by default]
>> anon-workstation-network-conf [/etc/network/interfaces ;
https://github.com/Whonix/Whonix/blob/Whonix8/whonix_workstation/etc/network/interfaces.whonix
; probably too specific to become a general package anyway? Can we agree
on sane/shared [among anonymity distributions] IP ranges? Perhaps a
discussion for another thread.]
>
> Merge to anon-ws-configs (network-configs?)

I added some additional information what they do into [] above. Please
check if it still makes sense in your opinion to merge them.

>> anon-ws-base-files anon-ws-chroot-inst-tb [chroot script for
>> installing Tor Browser while building] anon-ws-kde-startmenu [start
>> menu favorites] anon-ws-kde-startmenu
>
> anon-ws vs anon-workstation.

Agreed.

>> anonymizer-config-gateway [torrc etc.]
>> anonymizer-helper-scripts
>> [check Tor enabled, check Tor bootstrap status, etc.]
>
> anon-proxy-*?

You mean:
anon-proxy-config-gateway
anon-proxy-helper-scripts
?

In sake of keeping the existing naming, what about
anon-gw-anonymizer-config
anon-shared-helper-scripts

?

>> apparmor-profile-anondist [apparmor-profile rules required when
>> having apparmor installed to work around a few diverted files]
>> apparmor-profile-torbrowser ... more apparmor profiles to come
>> [https://www.whonix.org/wiki/AppArmor] apt-longer-timeouts
>> apt-no-autoupdate [to prevent fingerprinting, no running at
>> predictable times, auto update check at randomized intervals is
>> implemented in whonixcheck] bootclockrandomization [prevent time
>> based fingerprinting by unlinking host/vm clock at boot]
>
> Those two:
>
>> console-autologin [usability]
>> control-port-filter [we discussed this on this list a while ago]
>
> IMHO have little sense as separate packages - so simple its more work
> to reuse that package compared to simply do this manually. So perhaps
> better merge to some other package containing configs
> (anon-gw-configs? anon-ws-configs? anon-common-configs?).

Not everyone likes control-port-filter. I like to have the luxury of
saying "sudo apt-get purge control-port-filter" then or "wanne
re-implement control-port-filter in python?" Making it seem like it is a
strong dependency to get an transparent/isolating Tor proxy ws/gw system
would be wrong.

console-autologin, well, I see this seems strange. There are a few reasons.
1) it's a dependency of rads (RAM Adjusted Desktop Starter]
2) it's usability feature in VMs (where is little point to password
protect your console, when you can password protect your host).
3) important messages from whonixcheck/timesync are written to tty1
[when available] and x [when available]. Without autologin, these
messages may be never seen.

Maybe console-autologin should be merged into rads?

>> curl-scripts [lib: curl-prgs for bash; curl exit codes to human
>> readable error messages] damngpl
>> [http://www.finnie.org/software/damngpl/damngpl]
>> desktop-icons-gateway desktop-icons-workstation dummytor [run Tor
>> Browser without Tor over Tor and without modifications right after
>> download and extract from torproject.org; prevent Tor over Tor by
>> installing Tor on the workstation;
>> https://www.whonix.org/wiki/Dev/Dummy_Tor]
>
> anon-ws-disable-stacked-tor?

Much more descriptive. Yes!

>> grub-enable-apparmor [+ verbose messages while booting]
>
>
>> ipv4-forward-disable [make sure no leaks]
>> ipv6-disable [don't have IPv6 firewall rules yet, very limited Tor
IPv6 support]
>
> Really separate packages? Those two are one-liners...

Indeed one-liners.

When someone wants to use IPv6 something or implement an IPv6 firewall,
I would like to luxory of saying "sudo apt-get purge ipv6-disable" then.
When doing this, ipv4-forward-disable should still be enabled in place.
Also some users like to enable IPv4 forwarding for some special custom
setups, in that case it's nice to say "sudo apt-get purge
ipv4-forward-disable" and enable IPv4 forwarding then.

> Underscores in package name instead of dashes as other packages?

I am afraid, package names including underscores aren't allowed in
Debian. Source:
- No examples of Debian packages are named that way:
http://popcon.debian.org/by_vote.gz
- search engine: debian package name underscore

Also I failed to build a package with an underscore in its name.

Otherwise I would likely agree. Unfortunately, I now have to
consistently use dashed in package names.

Thanks a lot for your feedback!

Cheers,
Patrick

[Marek Marczykowski-Górecki]

On 08.05.2014 16:14, Patrick Schleizer wrote:
> Marek Marczykowski-Górecki:
>>> anon-apt-sources-list [debian stable sources.list]
>>
>> On standard debian /etc/apt/sources.list isn't owned by any package.
>> Is it really good idea to change that? IMO its better to provide
>> only sources.list.d/ files.
>
> This is more a question of distribution maintenance strategies rather
> than naming. Of course, this package won't be a dependency for other
> anonymity distributions. The more standard way would indeed be leaving
> /etc/apt/sources.list alone and using sources.list.d/. The idea of
> managing /etc/apt/sources.list for the user is, the Whonix distro
> maintainers can decide when it is a better "change stable to oldstable",
> "keep wheezy as long as we need to work out [eventual!] issues that
> would break during upgrade to jessie" and such.

So perhaps its better to put dummy /etc/apt/sources.list as part if Whonix
installer and place actual files in sources.list.d? I would fear some
conflicts (even with user modifications) when maintaining main sources.list in
some package.

>>> anon-apt-sources-tpo [torproject stable sources.list]
>
> Recommended [not required] for building. Recommended [not required] to
> have installed. To install torproject stable sources.list or not is
> another question of distribution maintenance strategies. Some time ago
> tor/torsocks in torproject's repository was newer/more bug free/more
> functional compared to the version in Debian.
>
>>> anon-banned-packages [packages better not installed on an anon
>>> distro] anon-base-files anon-dist-chroot-sanity-checks [scripts
>>> running inside chroot during build]
>>
>> Is that chroot used only for building?
>
> Recommended only for building, but useful to ask the user to run as for
> debugging, as integrity check, when a hdd hardware failure or something
> like that is suspected.
>
>> If so, perhaps better anon-dist-build-sanity-checks?
>
> You tell me. :)

Se below.

>>> anon-gateway-dhcp-conf anon-gateway-dns-conf anon-gateway-firewall
>>> [Not sure if we can make a general one or if this has to become
>>> whonix-gateway-firewall]
>>
>> This can be rather hard to reuse, so probably better
>> whonix-gateway-firewall.
>
> Done.
>
>>> anon-gateway-network-conf anon-gateway-sdwdate-conf
>>
>> Really that level of splitting is a good idea?
>
> In this case the anon-gateway-sdwdate-conf package (which is just a
> config file saying "don't run sdwdate on gateway so often, because we
> haven't finished sclockadj [https://github.com/Whonix/Whonix/issues/169]
> yet" hopefully won't be required for much longer.

In that case its even better to have it as part of other package, not a
separate package - its much easier to update package (perhaps with some
dependency on sdwdate version) when said ticket will be solved, than removing
no longer needed package.

>> I don't know details of Whonix configs, but I don't see any use case
>> where e.g. anon-gateway-dhcp-conf will be really useful without
>> matching anon-gateway-network-conf. Perhaps "anon-gateway-configs"
>> would be better (save some maintenance effort)?
>
> I see your point.
>
> anon-gateway-dhcp-conf only does "dhcp: don't touch /etc/resolv.conf!
> (because we don't need functional system DNS on gateway for gateway,
> because all gateway network applications are using stream isolation [tor
> socks proxy settings or uwtwrapper] anyway)" Now, there are a few users
> who disagree with me. I want to luxory of being able to say "sudo
> apt-get remove anon-gateway-dhcp-conf" then.
>
> I guess when I published the packages, there may indeed be some that
> don't justify a separate package.

IMO better have them in one package with option to enable/disable parts -
either symlinks or /etc/default/ config.

>>> anon-gpg-tweaks [gpg.conf for improved privacy and security]
>>> anon-gw-base-files anon-gw-chroot-upgrade-tor anon-gw-clearnet-user
>>> [creates clearnet user on gateway] anon-gw-first-run-notice ["do
>>> not use this gateway as a workstation", "do not show again"]
>>> anon-gw-kde-startmenu [suggested kde start menu entries useful for
>>> a gateay]
>>
>> IMHO its better to stick to one prefix - anon-gw or anon-gateway.
>
> Agreed.
>>> anon-shared-chroot-fix-grub anon-shared-chroot-inst-linux-486
>>> anon-shared-chroot-inst-linux-686
>>> anon-shared-chroot-inst-linux-amd64
>>> anon-shared-chroot-log-build-version
>>> anon-shared-chroot-remember-sources [remember sources.list used
>>> for install for later download of gpl sources]
>>> anon-shared-chroot-upgrade-torsocks anon-shared-chroot-vrms [check,
>>> that there are no contrib, non-free packages installed]
>>
>> Same here about chroot.
>
> Those are indeed exclusively required for building. Please restate your
> suggestion on this point after me sharing additional information.

Still, I think the names with "build" instead of "chroot" would be much
clearer. Also anon-dist-chroot-sanity-checks ->
anon-shared-build-sanity-checks (I don't understand difference dist/shared here).

>>> anon-torchat [torchat in anon distribution without Tor over Tor]
>>
>>> anon-workstation-dns-conf [/etc/resolv.conf only saying "nameserver
>>> 192.168.0.10". DNS not explicitly configured to use stream
>>> isolation, can use the Tor transparent proxying feature. (Not a
> hypothetical question some users are asking:) Want to disable
> transparent proxying? Uninstall anon-workstation-dns-conf on the
> workstation and xxx on the gateway then.]
>>> anon-workstation-firewall
> [https://github.com/Whonix/Whonix/blob/Whonix8/man/whonix_workstation/whonix_firewall.8.ronn
> ; the plan is to not install it by default, and users who install it,
> will get it enabled by default]
>>> anon-workstation-network-conf [/etc/network/interfaces ;
> https://github.com/Whonix/Whonix/blob/Whonix8/whonix_workstation/etc/network/interfaces.whonix
> ; probably too specific to become a general package anyway? Can we agree
> on sane/shared [among anonymity distributions] IP ranges? Perhaps a
> discussion for another thread.]
>>
>> Merge to anon-ws-configs (network-configs?)
>
> I added some additional information what they do into [] above. Please
> check if it still makes sense in your opinion to merge them.

Still, I think it worth a single package with all the above files. Perhaps in
some separate directory and symlinked to the right place, so you can easily
enable/disable by manipulating the links (or even use /etc/alternatives?).

>>> anon-ws-base-files anon-ws-chroot-inst-tb [chroot script for
>>> installing Tor Browser while building] anon-ws-kde-startmenu [start
>>> menu favorites] anon-ws-kde-startmenu
>>
>> anon-ws vs anon-workstation.
>
> Agreed.
>
>>> anonymizer-config-gateway [torrc etc.]
>>> anonymizer-helper-scripts
>>> [check Tor enabled, check Tor bootstrap status, etc.]
>>
>> anon-proxy-*?
>
> You mean:
> anon-proxy-config-gateway
> anon-proxy-helper-scripts
> ?
>
> In sake of keeping the existing naming, what about
> anon-gw-anonymizer-config
> anon-shared-helper-scripts
> ?

Even better.

>>> apparmor-profile-anondist [apparmor-profile rules required when
>>> having apparmor installed to work around a few diverted files]
>>> apparmor-profile-torbrowser ... more apparmor profiles to come
>>> [https://www.whonix.org/wiki/AppArmor] apt-longer-timeouts
>>> apt-no-autoupdate [to prevent fingerprinting, no running at
>>> predictable times, auto update check at randomized intervals is
>>> implemented in whonixcheck] bootclockrandomization [prevent time
>>> based fingerprinting by unlinking host/vm clock at boot]
>>
>> Those two:
>>
>>> console-autologin [usability]
>>> control-port-filter [we discussed this on this list a while ago]
>>
>> IMHO have little sense as separate packages - so simple its more work
>> to reuse that package compared to simply do this manually. So perhaps
>> better merge to some other package containing configs
>> (anon-gw-configs? anon-ws-configs? anon-common-configs?).
>
> Not everyone likes control-port-filter. I like to have the luxury of
> saying "sudo apt-get purge control-port-filter" then or "wanne
> re-implement control-port-filter in python?" Making it seem like it is a
> strong dependency to get an transparent/isolating Tor proxy ws/gw system
> would be wrong.

Perhaps some setting, you know - there is something called "config files" ;)

> console-autologin, well, I see this seems strange. There are a few reasons.
> 1) it's a dependency of rads (RAM Adjusted Desktop Starter]
> 2) it's usability feature in VMs (where is little point to password
> protect your console, when you can password protect your host).
> 3) important messages from whonixcheck/timesync are written to tty1
> [when available] and x [when available]. Without autologin, these
> messages may be never seen.
>
> Maybe console-autologin should be merged into rads?

Good idea.

>>> curl-scripts [lib: curl-prgs for bash; curl exit codes to human
>>> readable error messages] damngpl
>>> [http://www.finnie.org/software/damngpl/damngpl]
>>> desktop-icons-gateway desktop-icons-workstation dummytor [run Tor
>>> Browser without Tor over Tor and without modifications right after
>>> download and extract from torproject.org; prevent Tor over Tor by
>>> installing Tor on the workstation;
>>> https://www.whonix.org/wiki/Dev/Dummy_Tor]
>>
>> anon-ws-disable-stacked-tor?
>
> Much more descriptive. Yes!
>
>>> grub-enable-apparmor [+ verbose messages while booting]
>>
>>
>>> ipv4-forward-disable [make sure no leaks]
>>> ipv6-disable [don't have IPv6 firewall rules yet, very limited Tor
> IPv6 support]
>>
>> Really separate packages? Those two are one-liners...
>
> Indeed one-liners.
>
> When someone wants to use IPv6 something or implement an IPv6 firewall,
> I would like to luxory of saying "sudo apt-get purge ipv6-disable" then.
> When doing this, ipv4-forward-disable should still be enabled in place.
> Also some users like to enable IPv4 forwarding for some special custom
> setups, in that case it's nice to say "sudo apt-get purge
> ipv4-forward-disable" and enable IPv4 forwarding then.

You can always place higher-preference file in /etc/sysctl.d.

>> Underscores in package name instead of dashes as other packages?
>
> I am afraid, package names including underscores aren't allowed in
> Debian. Source:
> - No examples of Debian packages are named that way:
> http://popcon.debian.org/by_vote.gz
> - search engine: debian package name underscore
>
> Also I failed to build a package with an underscore in its name.
>
> Otherwise I would likely agree. Unfortunately, I now have to
> consistently use dashed in package names.
>
> Thanks a lot for your feedback!
>
> Cheers,
> Patrick
>

[Patrick Schleizer]

Marek Marczykowski-Górecki:

>>>> anon-gateway-network-conf anon-gateway-sdwdate-conf
>>>
>>> Really that level of splitting is a good idea?
>>
>> In this case the anon-gateway-sdwdate-conf package (which is just a
>> config file saying "don't run sdwdate on gateway so often, because we
>> haven't finished sclockadj [https://github.com/Whonix/Whonix/issues/169]
>> yet" hopefully won't be required for much longer.
>
> In that case its even better to have it as part of other package, not a
> separate package - its much easier to update package (perhaps with some
> dependency on sdwdate version) when said ticket will be solved, than
removing
> no longer needed package.

I see what I can do. By the time I am getting there, I hope sclockadj is
finished and this whole issue is obsolete.

>>>> anon-shared-chroot-fix-grub anon-shared-chroot-inst-linux-486
>>>> anon-shared-chroot-inst-linux-686
>>>> anon-shared-chroot-inst-linux-amd64
>>>> anon-shared-chroot-log-build-version
>>>> anon-shared-chroot-remember-sources [remember sources.list used
>>>> for install for later download of gpl sources]
>>>> anon-shared-chroot-upgrade-torsocks anon-shared-chroot-vrms [check,
>>>> that there are no contrib, non-free packages installed]
>>>
>>> Same here about chroot.
>>
>> Those are indeed exclusively required for building. Please restate your
>> suggestion on this point after me sharing additional information.
>
> Still, I think the names with "build" instead of "chroot" would be much
> clearer. Also anon-dist-chroot-sanity-checks ->
> anon-shared-build-sanity-checks (I don't understand difference
dist/shared here).

Done. Using "build" instead of "chroot" now. Difference dist/shared
didn't make sense indeed. Now "shared".

>> console-autologin, well, I see this seems strange. There are a few
reasons.
>> 1) it's a dependency of rads (RAM Adjusted Desktop Starter]
>> 2) it's usability feature in VMs (where is little point to password
>> protect your console, when you can password protect your host).
>> 3) important messages from whonixcheck/timesync are written to tty1
>> [when available] and x [when available]. Without autologin, these
>> messages may be never seen.
>>
>> Maybe console-autologin should be merged into rads?
>
> Good idea.

Done.

>>>> anonymizer-config-gateway [torrc etc.]
>>>> anonymizer-helper-scripts
>>>> [check Tor enabled, check Tor bootstrap status, etc.]
>>>
>>> anon-proxy-*?
>>
>> You mean:
>> anon-proxy-config-gateway
>> anon-proxy-helper-scripts
>> ?
>>
>> In sake of keeping the existing naming, what about
>> anon-gw-anonymizer-config
>> anon-shared-helper-scripts
>> ?
>
> Even better.

Done

> On 08.05.2014 16:14, Patrick Schleizer wrote:
>> Marek Marczykowski-Górecki:
>>>> anon-apt-sources-list [debian stable sources.list]
>>>
>>> On standard debian /etc/apt/sources.list isn't owned by any package.
>>> Is it really good idea to change that? IMO its better to provide
>>> only sources.list.d/ files.
>>
>> This is more a question of distribution maintenance strategies rather
>> than naming. Of course, this package won't be a dependency for other
>> anonymity distributions. The more standard way would indeed be leaving
>> /etc/apt/sources.list alone and using sources.list.d/. The idea of
>> managing /etc/apt/sources.list for the user is, the Whonix distro
>> maintainers can decide when it is a better "change stable to oldstable",
>> "keep wheezy as long as we need to work out [eventual!] issues that
>> would break during upgrade to jessie" and such.
>
> So perhaps its better to put dummy /etc/apt/sources.list as part if Whonix
> installer and place actual files in sources.list.d? I would fear some
> conflicts (even with user modifications) when maintaining main sources.list in
> some package.

I see. Well, there were no conflicts until now. The file's comments
discourage user edits. Sure, users/scripts could miss it and use 'echo
"..." >> /etc/apt/sources.list' and thereby mess it up.

Current contents as in Whonix 8 can be seen here:
https://github.com/Whonix/Whonix/blob/master/whonix_shared/etc/apt/sources.list.whonix

Since I am looking for consensus here, I can make it a
/etc/apt/sources.list.d/debian.list.

I guess I could live with a few "There is no /etc/apt/sources.list -
look into /etc/apt/sources.list.d/" conversations.

What about default /etc/apt/sources.list then? None at all? Empty? Some
default comments hinting at /etc/apt/sources.list.d and/or
/etc/apt/sources.list.d/debian.list? Note, since unmanaged, that file
can never be updated.

>>>> anon-torchat [torchat in anon distribution without Tor over Tor]
>>>
>>>> anon-workstation-dns-conf [/etc/resolv.conf only saying "nameserver
>>>> 192.168.0.10". DNS not explicitly configured to use stream
>>>> isolation, can use the Tor transparent proxying feature. (Not a
>> hypothetical question some users are asking:) Want to disable
>> transparent proxying? Uninstall anon-workstation-dns-conf on the
>> workstation and xxx on the gateway then.]
>>>> anon-workstation-firewall
>> [https://github.com/Whonix/Whonix/blob/Whonix8/man/whonix_workstation/whonix_firewall.8.ronn
>> ; the plan is to not install it by default, and users who install it,
>> will get it enabled by default]
>>>> anon-workstation-network-conf [/etc/network/interfaces ;
>> https://github.com/Whonix/Whonix/blob/Whonix8/whonix_workstation/etc/network/interfaces.whonix
>> ; probably too specific to become a general package anyway? Can we agree
>> on sane/shared [among anonymity distributions] IP ranges? Perhaps a
>> discussion for another thread.]
>>>
>>> Merge to anon-ws-configs (network-configs?)
>>
>> I added some additional information what they do into [] above. Please
>> check if it still makes sense in your opinion to merge them.
>
> Still, I think it worth a single package with all the above files. Perhaps in
> some separate directory and symlinked to the right place, so you can easily
> enable/disable by manipulating the links (or even use /etc/alternatives?).

I am not sure here if anon-(gw/ws)-network-conf can be made generic.

/etc/network/interfaces uses a pre-up for /usr/bin/whonix_firewall. That
is pretty Whonix specific, unless we make that a
/usr/bin/anon_gw_firewall, which would be up to the individual projects
to ship them with whatever they think is best?

And IP's are Whonix specific as well. QubesOS TorVM is using different
IP (ranges). I am not sure we will be able to agree on IP's due to VBox
vs KVM vs physical vs Qubes.

Whonix uses static network config. 192.168.0.10 for gateway,
192.168.0.11 for workstation and recommends .12 etc. for additional
workstations. It doesn't conflict in VMs (isolated networks). Still,
that may not be the most wise choices someone has ever made. We had
recently had discussion about using better ranges but I didn't manage to
research further yet:
https://www.whonix.org/forum/index.php?topic=107.msg1192

Fixed IPs make setting up hidden services (which need to point to a
fixed IP, fixed workstation) easier.

Qubes uses non-fixed LAN IPs? How do internal LAN IPs get assigned to
TorVM / AppVMs?

>>> I don't know details of Whonix configs, but I don't see any use case
>>> where e.g. anon-gateway-dhcp-conf will be really useful without
>>> matching anon-gateway-network-conf. Perhaps "anon-gateway-configs"
>>> would be better (save some maintenance effort)?
>>
>> I see your point.
>>
>> anon-gateway-dhcp-conf only does "dhcp: don't touch /etc/resolv.conf!
>> (because we don't need functional system DNS on gateway for gateway,
>> because all gateway network applications are using stream isolation [tor
>> socks proxy settings or uwtwrapper] anyway)" Now, there are a few users
>> who disagree with me. I want to luxory of being able to say "sudo
>> apt-get remove anon-gateway-dhcp-conf" then.
>>
>> I guess when I published the packages, there may indeed be some that
>> don't justify a separate package.
>
> IMO better have them in one package with option to enable/disable parts -
> either symlinks or /etc/default/ config.

>>>> apparmor-profile-anondist [apparmor-profile rules required when
>>>> having apparmor installed to work around a few diverted files]
>>>> apparmor-profile-torbrowser ... more apparmor profiles to come
>>>> [https://www.whonix.org/wiki/AppArmor] apt-longer-timeouts
>>>> apt-no-autoupdate [to prevent fingerprinting, no running at
>>>> predictable times, auto update check at randomized intervals is
>>>> implemented in whonixcheck] bootclockrandomization [prevent time
>>>> based fingerprinting by unlinking host/vm clock at boot]
>>>
>>> Those two:
>>>
>>>> console-autologin [usability]
>>>> control-port-filter [we discussed this on this list a while ago]
>>>
>>> IMHO have little sense as separate packages - so simple its more work
>>> to reuse that package compared to simply do this manually. So perhaps
>>> better merge to some other package containing configs
>>> (anon-gw-configs? anon-ws-configs? anon-common-configs?).
>>
>> Not everyone likes control-port-filter. I like to have the luxury of
>> saying "sudo apt-get purge control-port-filter" then or "wanne
>> re-implement control-port-filter in python?" Making it seem like it is a
>> strong dependency to get an transparent/isolating Tor proxy ws/gw system
>> would be wrong.
>
> Perhaps some setting, you know - there is something called "config files" ;)

>>>> ipv4-forward-disable [make sure no leaks]
>>>> ipv6-disable [don't have IPv6 firewall rules yet, very limited Tor
>> IPv6 support]
>>>
>>> Really separate packages? Those two are one-liners...
>>
>> Indeed one-liners.
>>
>> When someone wants to use IPv6 something or implement an IPv6 firewall,
>> I would like to luxory of saying "sudo apt-get purge ipv6-disable" then.
>> When doing this, ipv4-forward-disable should still be enabled in place.
>> Also some users like to enable IPv4 forwarding for some special custom
>> setups, in that case it's nice to say "sudo apt-get purge
>> ipv4-forward-disable" and enable IPv4 forwarding then.
>
> You can always place higher-preference file in /etc/sysctl.d.

Next thing are dependencies. control-port-filter depends on
netcat-traditional and ucspi-tcp. The configs packages don't depend on
these.

Explaining how to apt-get purge is also simpler for me than
documenting/explaining how to use configs, /etc/alternatives or symlinks.

Users seem to prefer purging packages over editing config files. Looks
simpler. I got a great number of complaints from customizer type of
users, that certain features cannot be easily purged without leftovers.
And other complaints from customizer/auditor type of users, that there
is no well documented list of what is very basic, essential vs extra
feature. For example anon-gw-anonymizer-config, anon-gw-network-conf are
essential, while anon-gw-dns-conf, control-port-filter are features.

When I am done packaging and describing, I guess it will become clearer
where it makes sense to split/combine.

For now, package names are vastly improved. :)

Cheers,
Patrick

[Marek Marczykowski-Górecki]

I think there should be a comment which point the user to
sources.list.d/debian.list for default repositories, and the right place for
user additional repositories is main sources.list.

Perhaps its better to register whonix_firewall script with
/etc/network/if-pre-up.d, instead of interfaces file?

> And IP's are Whonix specific as well. QubesOS TorVM is using different
> IP (ranges). I am not sure we will be able to agree on IP's due to VBox
> vs KVM vs physical vs Qubes.

I also don't believe for that level of standardization...

>
> Whonix uses static network config. 192.168.0.10 for gateway,
> 192.168.0.11 for workstation and recommends .12 etc. for additional
> workstations. It doesn't conflict in VMs (isolated networks). Still,
> that may not be the most wise choices someone has ever made. We had
> recently had discussion about using better ranges but I didn't manage to
> research further yet:
> https://www.whonix.org/forum/index.php?topic=107.msg1192
>
> Fixed IPs make setting up hidden services (which need to point to a
> fixed IP, fixed workstation) easier.
>
> Qubes uses non-fixed LAN IPs? How do internal LAN IPs get assigned to
> TorVM / AppVMs?

QubesVm IP address is generated based on its netvm ID (subnet number) and the
said VM static ID, so unless user is switching netvm, the IP is pretty static.
We've chosen 10.137.<subnet-id>.<vm-id> which is quite exotic so conflicts
with real LAN are very rare (even if rather harmless in isolated network).

Perhaps you're right here. There is major difference between Fedora and Debian
approach here: in Fedora installed package means it is installed and
*possible* to configure+enable. In Debian installed package means "I want that
service/feature running now". Good example here is apache web server - in
Fedora you need to configure and enable it after installation, in Debian you
get apache running right after installation and its rather hacky to disable it
without removing the package.

> When I am done packaging and describing, I guess it will become clearer
> where it makes sense to split/combine.
>
> For now, package names are vastly improved. :)
>
> Cheers,
> Patrick
>

[Patrick Schleizer]

Marek Marczykowski-Górecki:

I'd like that very much. Unfortunately, we can not use
/etc/network/if-pre-up.d to load the firewall, because of a Debian
upstream bug.

interface comes up even if a script in /etc/network/if-pre-up.d/ fails:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700811

It's fixed in jessie (testing at time of writing), but not in wheezy
(stable at time of writing).

I am eager to do this when Whonix will be based on jessie.

[Patrick Schleizer]

Hi!

More progress has been made. Initial split of packages is done. They all
can be found here:
https://github.com/Whonix

They're not tested yet.

The full list of links can be found here:
https://github.com/Whonix/Whonix/issues/40#issuecomment-44753572

Cheers,
Patrick

Original message snippet:

Patrick Schleizer:

> [snip outdated package name list]