[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [CONTRIBUTE] [DONATE]

Issue T181: Audit of Proposed qubes-whonix 9.6-1

Great! :smiley:

Right. Understood.

And we should also look to independently make the best choices for the package before putting code in Patrick’s hands.

Right. Understood.

[quote=“nrgaway, post:19, topic:872”]3) I know you are trying to play the ‘devils advocate’ here which is fine but one thing I am noticing in some of you recent posts is the narrow-focus on the qubes-whonix package for security hardening. While I agree that this is important I think it may also be just as important to expand this to other packages installed as well.

For instance we can spend a lot of time making sure every byte of code in qubes-whonix can not initiate some type of indented compromise or fingerprint, but what about all the other hundreds of Debian packages? Maybe the vim program has some backdoor that opens up some security hole (I sure hope it doesn’t).[/quote]

Right.

I did generalize the concept in my discussion for all of Whonix’s packages.

And I think I mentioned other Linux packages as well.

What got this discussion initially started was the “enable-iptables-logging” script, but it has expanded further in scope, and now the “enable-iptables-logging” script is basically just being referenced as an original example of the greater code security concept in question.

So this qubes-whonix package audit thread context is becoming somewhat inadequate for this discussion now. Partly why I recently established a new tracker ticket for this issue to try to abstract away.

Patrick mentioned not thinking that the presence of extra test code/scripts in Whonix being a viable threat vector, since we can easily know if they are invoked or not, citing that for Bash code we would notice the script strings or would raise red flags if using creative methods.

I’m not convinced of this, personally, and think I may have an innocent looking approach to invoke such test scripts. And I’m no expert at covert code exploits at all, so realizing the limits of my own expertise, and seeing ways to pull this off, I take an even more conservative approach, than just basing my conclusions on the certainty in my own personal expertise. Again, this conservative mindset goes double for me when keeping good people’s mission critical anonymity in mind around the world.

Also, while integrity of anonymity & security is the primary concern when auditing a platform like Qubes + Whonix, I was also looking to make the process of doing so more time-efficient.

I view test code/scripts as often working against this purpose. Because, often, test code/scripts do things counter to the goals of the production code (in order to test systems in alternate non-production states). This is the nature of test code/scripts. To modify the normal intended production of systems.

Philosophically, and often concretely…

PRODUCTION CODE == INTENDED SAFE PRODUCTION SYSTEM STATE

TEST CODE == ALTERED POTENTIALLY UNSAFE NON-PRODUCTION SYSTEM STATE

That’s why I was simply suggesting, since were dealing with real live anonymity systems here, to exclude such test code/scripts by default, but offer them as user optional add-on packages if need be.

Also, no one can audit all the other code used beyond the Whonix project. And, I don’t currently have the time to audit all of Whonix-proper itself or Qubes-proper itself. Hopefully, I’ll get more time for diving into the code of Whonix and Qubes in general down the line.

I do AT LEAST want to ensure that my administration of the Qubes + Whonix project involves auditing the code contributions that are specific to Qubes + Whonix, now that we aren’t just porting stock Whonix with stock Qubes anymore, but rather establishing a newly blended third inter-project platform of sorts.

Patrick also threw out a point about how default included tests for Whonix-proper may have more fundamental utility, like in situations where people’s internet is down. Can’t deny the principle of such scenarios. But can still advocate for security conservatism and minimalism.

So, with resistance experienced to this concept, and my personal audit-time capacity being much smaller than all of the packages involved, I thought I’d try to establish something first with the qubes-whonix package and then maybe expand out from there.

Like I mentioned, with regards to code for Qubes + Whonix, I’m personally okay with us simply omitting all test code/scripts. Or alternatively, as Patrick said he didn’t mind us doing, we could put any tests into a separate non-default-installed package, maybe “qubes-whonix-tests” or something else. Either way.

Made this ticket: https://phabricator.whonix.org/T191

Personally – with code I haven’t personally written – I find it tedious to see production code that makes sense for the intended normal operational functions, but then also see “test code/scripts” existing side-by-side, and then have to go down the rabbit hole hunting for and auditing all the potential ways to confirm whether the test code is invoked by default or not.

Especially since our Qubes + Whonix platform now involves code inside of two separate parent project repos. In my view, it just makes thorough auditing that much more time-inefficient and potentially insecure. Not to mention the lingering security concerns of such non-production code.

But, I think it would be good to establish a precedent for the Qubes + Whonix platform, and not have to debate it with each bit of test code of every single release going forward. Especially as more people start writing code for Qubes + Whonix in the future.

Don’t know about the “verify every other installed Debian package” part, as this doesn’t seem feasible to me. But I do like the overall direction you’re going in here. :smiley:

Love this idea. :smiley:

Without further detail of what you mean by this, this statement hits me as a very bad security idea.

AFAIK, the Gateway treats the Workstation more like an untrusted domain. Allowing the Workstation to have direct control over the domain where the Tor networking configuration and real IP exists seems like bad isolation architecture.

I like this idea. This is another layer of some protection, and certainly a good thing.

But, as a caveat, if the VM gets compromised, then such periodic verification results may not be trustworthy, and be simply forged by whatever exploited occurred. But, not all exploits would design themselves to adapt for this, especially non-Whonix specific ones, and so it could still probably catch and warn of some compromises.

I’m actually involved in developing a new Qubes application that will be doing this for Qubes + Whonix going forward. It would not interfere with this specific implementation though, as it is separate from our Qubes + Whonix codebase. Just work as additional verification to this.

[quote=“nrgaway, post:19, topic:872”]Now in relation to the qubes-whonix package I think the most important thing to concentrate on at this moment are the firewall rules. Not only the only I added, also making sure that the default whonix rules work as expected with qubes. The Whonix firewall rules seems overly complex to me, so therefore I would also like to see:

D) Simplify whonix gateway firewall rules making them more easily human readable. Currently these rules are applied or not applied based on many criteria and sometimes rules can be added from other sources as well. What I would like to see is the whonix_firewall be automatically generated and only show the rules that apply right now. So move existing whonix_firewall rules to whonix_firewall.template; create a script that will generate /usr/bin/whonix_firewall that contains ONLY the rules that will be set (no conditional statements based on ENV, or var, just exactly the rules that will be applied)

If someone changes an option, in the whonix_firewall.template, or configuration files it reads, they would run ‘generate-whonix-firewall’ which would re-create it again. This would allow someone to easily audit the firewall rules and the order of applying them and would not have to worry about some ENV variable being set by accident, or not by accident.

Anyway, that’s pretty much my thoughts today. In importance of A, B, C and D, I would like to really see ‘D’ implemented first as currently it is very difficult to know which firewall rules will be applied and there are too many spots that can be modified to change that behaviour with or without the user knowing about it.[/quote]

Simplification is almost always good, especially in key parts of the system.

I’m not familiar enough with that component of Whonix’s codebase to comment on any potential pitfalls of this proposed undertaking right now.

Firewall simplification sounds good in general to me.

I was wondering about this also. It’s hard to decide what’s absolutely required and what not for minimal.

Whonix could be created in so many different ways. Even with just instructions only. (That’s how it all started.)[/quote]

I figure only packages to allow the gateway to run and be configured. For instance Fedora and install a minimal base system with about a dozen packages. Then add the required packages for tor, etc.

Ideally, most of Whonix's functionality would be installable from Debian's repository. I'd love to find (co-)maintainer(s) for every package who ideally review the package, upload to Debian, so I would just be upstream. (https://www.whonix.org/wiki/Contribute#Maintainer)

Ideally, Whonix would not be a Debian derivative, but a Debian Pure Blend. (https://wiki.debian.org/DebianPureBlends) Therefore build by Debian servers. Deterministically! Tails devs, don’t attempt this, even though intrigeri is a Debian Developer, because Tails has a 6 week release cycle and because it needs quite some time for packages to migrate from Debian unstable to testing or even stable. It could work better for Whonix. While I think, neither stable nor testing would be really suited for Whonix in the fast changing anonymity world. Rolling Debian distribution would work best. There was an attempt, CUT (Constantly Usable Testing). Unfortunately, it looks like that effort has been abandoned.

Ideally, Qubes would not be a distribution, but an alternative Debian kernel package + other supporting packages. Just as you can install the freebsd kernel as alternative to the linux kernel on Debian, the same would be technically possible with Qubes.

Needless to say, that it’s a hell of a lot work ahead. Likely, this never happens.

a) This would involve a protocol between gateway and workstation that comes with its own issues.
b) The workstation should not be trusted for that purpose. Changes in the workstation should not allow configuring the gateway in any malicious way such as using colluding bridges.

Yes, I agree; maybe another type of utility then that is solely used to configure gateway if users require a gui to configure gateway; just to get rid of xwindows, etc

[quote]C) Have a utility on Gateway that periodically checks for un-authorized changes to packages and configuration files. There are a few out there that already do this. Find a unauthorized or unexpected change? shutdown gateway. [/quote] This supposed a compromised gateway. But if it was compromised, with today's malware, it can do malicious stuff and make sure you won't find out. (kernel rootkit, skipping certain backdoor files in kernel file system access, etc.) Compromised (malware infected) = game over. No way around that. (For analysis however, someone could write a VM that analyzed the gateway file system or even RAM for malicious things.)

Related, see “Script to System Check Integrity against Debian Package Repository”:
https://lists.debian.org/debian-security/2013/09/msg00053.html

A fine TODO in the Libre Software security world.

I actually believe one could detect even the most sophisticated malware on a gateway if the gateway was configured a bit differently. First off, the root partition can set be read-only. Modifiable configuration files can be kept in a rw directory. Now since these are VM’s, we can write an external utility to checksum the filesystems, where we do not rely on any code within the gateway VM to do the verification. Since the malware would only infect the VM, it is then therefore detectable.

For example, I would run a utility that checksums /root, /rw, /boot partitions from the host computer. Any /tmp directorys will be trashed and recreated so are not needed to be checksumed. If the external checksum differs from the expected result; you have reason to suspect a compromised system. Updates to system can be applied in a special manner that would startvm with no services running with something like systemd-nspawn and update system, create new checksum and it ready for use again.

It would take a bit of a thought process to work out, but I think doable.

[quote]There are traffic monitoring tools which can also be used to do same.[/quote] Traffic monitoring can work against simpler kinds of malware, but not against sophisticated ones. (That introduce delays to communicate through them or something similarly creative.)

Yeah. That’s a big issue. Those packages are much harder to grasp. Better don’t do actual research on how many people audited their code. I am sure, results would be devastating.

Problem is, with C(++) code, backdoors can look the very same as usual security bugs.

Also look up the “Debian OpenSSL debacle”.

Solution?

  1. Todays programming and script languages have been invented by geeks. Thanks for getting us started. Not by people who understand usability on the top level. Invent brain friendly programming and script languages, that are hard to hide backdoors, use aid from brain researches, do actual usability studies. That would allow a much bigger crowd to program and audit.
  2. Use as little code as possible written in difficult languages. Minimal code that very few people are capable of auditing (assembler, C(++)).
  3. Rewrite pretty much everything we got so far.

Very likely to happen during my life time. Most people are happy with stuff as is. Only a minority of the Libre Software community is interested hardcore security. Once a solution works fine for most, there is little incentive to rewrite just to make backdoors much more unlikely.

Got any specific ideas for that? Looks hard to me. Probably not possible without sacrificing functionality such as stream isolation or configurability.

I find any solution that auto generates code from code difficult. It adds up complexity. Then one cannot just get the code from git and review. They can, but they’d need another process in their head “how would the final result look like when the generator finished”. Something to constantly explain and defend.

What about…

? That’s a compiled list, no?

Before making changes to a firewall (any, be it Whonix or otherwise), I run “sudo iptables --list > old”. Then make changes to the firewall script. Then load the new firewall rules. (Or reboot,.) Then store the new rules also within a file. “sudo iptables --list > new”. Then diff them. “diff old new”.

That works too, but I do not find the current whonix_firewall simple since I have no idea what vars are actually enabled. It is much easier to see what the firewall is supposed to create than to be only auditing the iptables list. It would be a very difficult task to relate iptables to rules that were set, compared to just seeing what rules are being used to create the iptables list.

My suggestion only creates another step, the one to create whonix_firewall from whonix_firewall.template, where the template is the actually the original whonix_firewall script, so you can still review that to see what options are available and once you generate the whonix_firewall from it you can compare to make sure only the expected configuration was generated.

All you would need to do to convert the whonix_firewall to whonix_firewall.template is:

  1. mv whonix_firewall whonix_firewall.template
  2. create a function something like:
generate() {
  echo -e $* >> whonix_firewall
}
  1. place generate in front of all the iptables rules, and even comment sections

So now, when whonix_filrewall.template is run, you can see exactly the firewall rules it created.

The main reason for doing this was is to be review the actual rules that would be used which can be of benefit to identity rules that are enabled that the user was unaware of.

Also what currently would happen if an ENV var was set before whonix_firewall is run, say ‘GATEWAY_ALLOW_INCOMING_SSH=1’. Does the Whonix script make sure that the external ENVironmental vars are sanitized before running the firewall?

Personally, if I had a need to use Whonix, that would be one of the first things I did, but it could only be me that would have a concern like this. Once I had confirmed the whonix_firewall rules to contain what I wanted them to contain , I would then do as you suggested and copy iptables list, and check against that every so often to make sure nothing else of modifying them.

Do you use another anonymity system instead or just simply don’t care to make personal use of anonymity tools?

Curious what motivates you to specifically develop for the Whonix platform?

BTW, thanks for doing so!

[quote=“WhonixQubes, post:23, topic:872”][quote author=nrgaway link=topic=961.msg7122#msg7122 date=1425005231]
Personally, if I had a need to use Whonix
[/quote]

Do you use another anonymity system instead or just simply don’t care to make personal use of anonymity tools?

Curious what motivates you to specifically develop for the Whonix platform?

BTW, thanks for doing so![/quote]
I find it interesting and have used it on occasion, but I do find Tor slow so I prefer to use clearnet. I have not really tried out any other systems as they do not seem to have clearnet gateways. I also filter my open WiFi though Tor.

I like learning new things and since privacy seems to be a big issue these days, that had prompted me into learning more about it. I actually found out about Qubes through this web site and I am totally loving it.

[quote=“nrgaway, post:24, topic:872”][quote author=WhonixQubes link=topic=961.msg7123#msg7123 date=1425009969]

Do you use another anonymity system instead or just simply don’t care to make personal use of anonymity tools?

Curious what motivates you to specifically develop for the Whonix platform?

BTW, thanks for doing so!
[/quote]
I find it interesting and have used it on occasion, but I do find Tor slow so I prefer to use clearnet. I have not really tried out any other systems as they do not seem to have clearnet gateways. I also filter my open WiFi though Tor.

I like learning new things and since privacy seems to be a big issue these days, that had prompted me into learning more about it. I actually found out about Qubes through this web site and I am totally loving it.[/quote]

Jason,

Got it.

Yeah, for myself, the big reason for developing the Qubes + Whonix platform is about further checking oppressive and immoral political establishments.

I do get that there are a number of more casual use cases for the platform too.

Ultimately, I launched the project for the hope that the more serious security isolation of Qubes and the tailored anonymity environment of Whonix could help meaningfully push forward the status quo of the underdeveloped privacy/anonymity computing industry to offer better solutions to good people in need of true mission critical anonymity.

Even if your own motives are more casual and educational, I’m very thankful for the contributions you’re able to make that additionally help towards this bigger mission.

Beyond the core Tor software/protocol, I see the following as being very important to more critical privacy/anonymity needs…

    1. Whonix’s isolated TwoVM implementation of Tor
    1. Qubes’s hardcore host-level security isolation
    1. Generic fingerprint-resistant anonymous OS environment
    1. Usability for people to make consistent and efficient use of best practices
    1. More open and secure computer hardware

And supporting an open, transparent, collaborative, well documented and audited development process for everything.

Thanks to our combined Qubes + Whonix efforts over the past 7+ months, we’ve gone from position #1 before last year to now fulfilling position #2 since last year.

I’m working towards trying to fix what is sorely lacking for positions #3 and #4 with Qubes + Whonix this year.

Thank you for being a meaningful part of this great project! :smiley:

No, the env vars do not get sanitized. I see no need for that. It’s a feature. Yes, there has been a terrible bash env var vulnerability, but no reason to freak out and go crazy about it and ditch env vars everywhere. It was never applicable to local scripts of that type. To set environment variables, one needs local access. Once malware has local access, it can do a lot worse stuff than tampering with env vars, so it wouldn’t help there anyhow. The only one who can set env vars is the user and as well are files on the disk the are shipped by packages. The user cannot be protected from itself anyhow. And files on the disk that come from packages need to be audited the usual way anyhow. Now, if for example the xchat-improved-privacy would ship a file to set some strange env var, that would raise a red flag.

[hr]

If you want to know environment variables set on your system, login root (or user, depends) and type “env”. Or add “env” to the beginning of some script you’re interested in and echo and/or redirect it anywhere you prefer.

There is also a very limited number of places where global env vars can be set.

[hr]

Which variables for Whonix Firewall are set gets clear by having a look at /etc/whonix_firewall.d/. Files in that folder are sourceed in lexical order (as per firewall script, section “source config folder”). There aren’t that many in that folder.

You can also write a small script based on the parsing code to show them.

#!/bin/bash

set -e
set -x

for i in /etc/whonix_firewall.d/*; do
   if [ -f "$i" ]; then
      ## If the last character is a ~, ignore that file, because it was created
      ## by some editor, which creates backup files.
      if [ "${i: -1}" = "~" ]; then
         continue
      fi
      ## Skipping files such as .dpkg-old and .dpkg-dist.
      if ( echo "$i" | grep -q ".dpkg-" ); then
         true "skip $i"
         continue
      fi
      bash_n_exit_code="0"
      bash_n_output="$(bash -n "$i" 2>&1)" || { bash_n_exit_code="$?" ; true; };
      if [ ! "$bash_n_exit_code" = "0" ]; then
         echo "Invalid config file: $i
bash_n_exit_code: $bash_n_exit_code
bash_n_output:
$bash_n_output" >&2
         exit 1
      fi
      source "$i"
   fi
done

Alternative:

#!/bin/bash

set -e

for i in /etc/whonix_firewall.d/*; do
   if [ -f "$i" ]; then
      ## If the last character is a ~, ignore that file, because it was created
      ## by some editor, which creates backup files.
      if [ "${i: -1}" = "~" ]; then
         continue
      fi
      ## Skipping files such as .dpkg-old and .dpkg-dist.
      if ( echo "$i" | grep -q ".dpkg-" ); then
         true "skip $i"
         continue
      fi
      bash_n_exit_code="0"
      bash_n_output="$(bash -n "$i" 2>&1)" || { bash_n_exit_code="$?" ; true; };
      if [ ! "$bash_n_exit_code" = "0" ]; then
         echo "Invalid config file: $i
bash_n_exit_code: $bash_n_exit_code
bash_n_output:
$bash_n_output" >&2
         exit 1
      fi
      set -x
      source "$i"
      set +x
   fi
done

Example output from my test system:

+ source /etc/whonix_firewall.d/30_default
++ GATEWAY_ALLOW_INCOMING_FLASHPROXY=0
++ FLASHPROXY_PORT=9000
++ WORKSTATION_TRANSPARENT_TCP=1
++ WORKSTATION_TRANSPARENT_UDP=0
++ WORKSTATION_TRANSPARENT_DNS=1
++ WORKSTATION_ALLOW_SOCKSIFIED=1
++ CONTROL_PORT_FILTER_PROXY_ENABLE=1
++ GATEWAY_ALLOW_INCOMING_DIR_PORT=0
++ GATEWAY_ALLOW_INCOMING_OR_PORT=0
++ DIR_PORT=80
++ OR_PORT=443
++ GATEWAY_TRANSPARENT_TCP=0
++ GATEWAY_TRANSPARENT_UDP=0
++ GATEWAY_TRANSPARENT_DNS=0
++ ALLOW_GATEWAY_ROOT_USER=0
++ ALLOW_GATEWAY_USER_USER=0
++ GATEWAY_ALLOW_INCOMING_SSH=0
++ NO_REJECT_INVALID_OUTGOING_PACKAGES=0
++ GATEWAY_ALLOW_INCOMING_ICMP=0
+ set +x
+ source /etc/whonix_firewall.d/50_user
++ WORKSTATION_TRANSPARENT_TCP=1
++ WORKSTATION_TRANSPARENT_DNS=1
++ GATEWAY_IPv4_DROP_INVALID_INCOMING_PACKAGES_POST_HOOK='echo test'
+ set +x

[hr]

As for the iptables generator… I’d find it terrible to document “by default you cannot see in the source code how the firewall script will look like, because first you need to run the generator, and then you can look the the generated result”. Seems more complex than currently to me.

It indeed wouldn’t be hard to write instead of “iptables” some “function-name”. That function could, depending on some setting, either directly apply the iptables rule (as is currently) (and/)or create a compiled firewall script with iptables rules. It would increase the size of the xtrace, though. And also depending on some setting, a to-be-written- wrapper could either directly load /usr/bin/whonix_firewall or /var/cache/whonix-gw-firewall/compiled. Write a pull request?

I implemented lots of feature requests for Whonix Firewall. Now your feature request basically is, “strip all the features, make it bar bone”. Needless to say, that there is no way to make everyone happy. There could be an alternative whonix-simple-fw package that only implements what the current defaults are with no options. They when one or another fw gets changed, the other one would have to be updated as well. That is a concept that works bad, it is often forgotten. And if someone wants to use some feature, the answer would be “use whonix-gw-firewall”. And then there would be a feature request to add the VPN_FIREWALL feature to whonix-simple-fw. And a debate on which one is best and if both could/should be combined to have advantages of all. There is no perfect solution either way.

What about comments and new lines in the compiled firewall list? Just none? And how/why would this compiled firewall rules list be any better than “iptables --list”?

[hr]

I am not convinced of removal of unit tests and whatnot without seeing an example of creative hidden invocation. Scary stuff that applies to C(++) that’s often in the news often does not apply to scripts. It’s useful to stay on top of vulnerabilities, understand them and then try imagine if it could be modified/applied for any scripts as well, sure. But often it doesn’t.

Most times it’s best to follow existing standards and conventions. When accepting patches you usually want them to run the test suite. And to extend the test suite if applicable. Now, when you receive a patch and you start answering, “oh, but did you get the test suite from that other repository and followed instructions on how to set it up” you’ll make things actually more difficult.

For a while, whonix-developer-meta-files wasn’t part of the Whonix source code. An unlinked extra repository that depended on the main source code. Setting that up caused confusion. (https://github.com/Whonix/Whonix/issues/337)

Telling, other interested contributors “but you also need xyz”, looks like a non-standard mess and worsens ability and motivation to get into it at all.

Vastly increasing the number of packages with -test packages doesn’t seem to me like a good way to make things simpler.

There are a lot more low hanging fruits that would improve the stability and auditability.

  • For Whonix in general, for example, I would like to get rid of the giant code duplication by adding the generic makefile and make-helper.bash to all the packages without the packages being standalone. Getting the generic makefile into Debian so it could be pulled as a build dependency would do the trick.

  • For Qubes specifically, rather than with test scripts and creative invocation of them, I am much more concerned about the current “creativity” of the qubes-whonix package as I said here: https://www.whonix.org/forum/index.php/topic,841.msg7019.html#msg7019 Turning the qubes-whonix package into a sort of jack of all trades device rather than the “do one thing, do it well” paradigm (installing systemd, custom package selection) and all the non-standard things and hacks (using systemd on wheezy, custom systemd code in Debian maintainer scripts, not using default debhelper code and a lot other hacks that mostly or even all have tickets already) concerns me a lot more, since it provides a lot more room for “creativity” and bugs.

[hr]

I hope I addressed all points.

[quote=“Patrick, post:26, topic:872”]I am not convinced of removal of unit tests and whatnot without seeing an example of creative hidden invocation. Scary stuff that applies to C(++) that’s often in the news often does not apply to scripts. It’s useful to stay on top of vulnerabilities, understand them and then try imagine if it could be modified/applied for any scripts as well, sure. But often it doesn’t.

Most times it’s best to follow existing standards and conventions. When accepting patches you usually want them to run the test suite. And to extend the test suite if applicable. Now, when you receive a patch and you start answering, “oh, but did you get the test suite from that other repository and followed instructions on how to set it up” you’ll make things actually more difficult.

For a while, whonix-developer-meta-files wasn’t part of the Whonix source code. An unlinked extra repository that depended on the main source code. Setting that up caused confusion. (https://github.com/Whonix/Whonix/issues/337)

Telling, other interested contributors “but you also need xyz”, looks like a non-standard mess and worsens ability and motivation to get into it at all.

Vastly increasing the number of packages with -test packages doesn’t seem to me like a good way to make things simpler.[/quote]

This is ultimately ok, as I can additionally focus on mitigating the potential issue through an independent app and we can keep tests in for all the other packages in the original Whonix codebase.

I would wonder how this app would operate, but feel free to cook it up.

Just simply by stripping out extra test code/scripts that are potentially not good for production anonymity if run.

That wouldn’t need an app. Also because the files the app deletes gets recreated when the package that ships the undesired file is upgraded.

Use config-package-dev’s hide operation. Link:
http://debathena.mit.edu/config-packages/
Available from Debian repository, stable, used by some Whonix packages.

Here is a simple example package, that hides a single file [equally easy to hide multiple files]:
https://github.com/Whonix/knetattach-hide

[quote=“Patrick, post:30, topic:872”]That wouldn’t need an app. Also because the files the app deletes gets recreated when the package that ships the undesired file is upgraded.

Use config-package-dev’s hide operation. Link:
http://debathena.mit.edu/config-packages/
Available from Debian repository, stable, used by some Whonix packages.

Here is a simple example package, that hides a single file [equally easy to hide multiple files]:
https://github.com/Whonix/knetattach-hide[/quote]

I will be sure to check it out and see if it will work as desired. Thanks! :smiley:

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]