I was wondering about this before but I didn’t thought I’d get to ever develop a solution for it, so no ticket created. Maybe you’d like to contribute?
dpkg -S /etc/apt/sources.list.d/*
anon-apt-sources-list: /etc/apt/sources.list.d/debian.list
dpkg-query: no path found matching pattern /etc/apt/sources.list.d/derivative.list
qubes-core-agent: /etc/apt/sources.list.d/qubes-r4.list
As for GitHub - Kicksecure/repository-dist an option --onion
seems very doable to do. Probably best to have mandatory switches? One of the following three:
--clearnet
(TLS only. For Kicksecure. Opt-in.)--torified
(I don’t really like that name--torified
since--onion
is also torified. But other names such as--torplus
also seems misleading. Sounds like a fork of Tor. And--torplustls
would be correct but a bit long and weird to type.--onion
/etc/apt/sources.list.d/debian.list
is a “managed” file. Managed for the benefit of the user. Package anon-apt-sources-list
is updated whenever required, specifically on release upgrade to the next major version of Debian.
If that script was modified by the user or by a script (which looks to APT as if modified by the user) this would cause an interactive dpkg conflict resolution dialog which I can tell from support experience is very confusing for users, generating lots of support requests.
Configuration file `/etc/apt/sources.list.d/debian.list’
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer’s version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : background this process to examine the situation
The default action is to keep your current version.
*** interfaces (Y/I/N/O/D/Z) [default=N] ? N
Therefore maybe a new package anon-onion-sources-list
would be better? The APT onionizer tool could then recommend to:
sudo apt install anon-onion-sources-list
andsudo apt purge anon-apt-sources-list
.
Maybe even systemcheck --verbose
would include a hint but that can be considered at the end.
/etc/apt/sources.list.d/qubes-r4.list
is the worst offender currently. Not even using tor+
. Not an anonymity risk but error handling would be better. File is managed by qubes-core-agent
. Therefore also if that file was edited there would also be an interactive dpkg conflict resolution issue. Furthermore, this file is managed by Qubes, not Whonix. That file must not be installed in Non-Qubes-Whonix.
What could be done?
- Request that file to be moved to a separate Qubes package, then create an alternative package with the onion version?
- config-package-dev
hide
/etc/apt/sources.list.d/qubes-r4.list
and create an alternative package with the onion version? Ideally Qubes would maintain that file/package after initial contribution to Qubes. Otherwise could become very messy with maintenance lapses.
We can always create an issue on Issues · QubesOS/qubes-issues · GitHub to discuss this with Qubes upstream.
Could you send a friendly ping please?
I cannot open that link currently.
Not sure what could be done. fasttrack might not be too important yet. Non-VirtualBox users could probably disable it. APT onionizer could mention it (always) and suggest to disable it for Non-VirtualBox users (both VM and host).
related:
How about user custom added repositories? I was wondering if an APT onionizer would have a set of clearnet repositories mapped to onion repositories and then with one command line option / wizard could upgrade/downgrade from one version to another.
What about extrepo
?
Would this feature fit there? Could be contributed to upstream?
Yeah. Quite complex, right? That’s why I never before wrote this up.