Anonymizing hostname doesn't work on Debian 11 minimal sys-net

[NobodySpecial256]

After following the instructions to anonymize my hostname, a test with Wireshark revealed my hostname wasn't being anonymized. Perhaps reverting https://github.com/Qubes-Community/Contents/commit/4ea74cec079439ac9ccc2054bfc4a11d69da4333 could be useful, as randomizing my hostname works for me without issue.

Additionally, hiding your hostname entirely might be counterproductive, as it's easier to spot a device that doesn't send any hostname than it is to spot devices with randomized hostnames. Especially since most Windows devices have randomized hostnames set at install time, random hostnames will be less suspicious in a PCAP

[tlaurion]

Relevant discussions ans posts

https://forum.qubes-os.org/t/change-mac-address-and-hostname-by-default/13182/10?u=insurgo

https://github.com/QubesOS/qubes-issues/issues/7701

[tlaurion]

Basically, what seems to be the conclusion here is that by default, Qubes is not shouting "I'm sys-net" anymore.

On a fingerprinting perspective, dhcp fingerprint will differentiate Fedora from Windows already (see p0f and other fingerprinting projects, FingerBank being another).

So the question here is "lowering presence disclosure" on the network.

How many Linux distributions don't expose hostname anymore? I do not know anymore. Before it was a thing and the hostname pattern was a thing to fingerprint people. Now if fedora defaults changed, most probably CentOS and RedHat reuses the same defaults.

So the real question here is who outside of Windows are still exposing hostname? And if randomizing hostname in a Windows fashion would be enough to lower automatic system classification from a NAC perspective.

As said elsewhere, when looking on my own DHCP logs and reported hostnames on my WiFi AP, lots of OSes are not exposing hostnames through dhcp calls. Nowadays, I see Windows devices and Android devices reporting hostnames. The other variates and I have not inspected those devices OS nor dhcp specifics.

But since all this BYOD movement, and back to the when p0f/dhcp fingerprinting was a thing, hostname alone was no more then a queue into information gathered for classification.

So basically: my take on this is that not disclosing hostname should be enough, where sys-net being disclosed was the real issue. Combined with MAC randomization on WiFi by default on 4.1 resolves the most problematic privacy issues that were present on Qubes presence.

After that, if we are worried that Fedora can be fingerprinted, or Linux on a larger level, a lot of other things should be done to accomplished that goal. Now, looking at the slowed pace of development on those fingerprinting technologies, I think it is safe to say that fingerprinting still occurs on many other levels, while hostname nondisclosure might be enough here, and where mimicking Windows, while looking as a good idea, might be totally useless in practice.

Would have to pop PacketFence, pay for their fingerbank subscription and play there to see if your device gets correctly fingerprinted. My intuition here would be that you would be classified as RedHat/Fedora/Centos because of dhcp quirks, not hostname.

[NobodySpecial256]

Basically, what seems to be the conclusion here is that by default, Qubes is not shouting "I'm sys-net" anymore.

That's why I opened the PR. When I applied the changes, Qubes still shared the hostname with the network. I verified this with Wireshark

So the real question here is who outside of Windows are still exposing hostname? And if randomizing hostname in a Windows fashion would be enough to lower automatic system classification from a NAC perspective.

Qubes, apparently. At least according to my Wireshark output

So basically: my take on this is that not disclosing hostname should be enough, where sys-net being disclosed was the real issue. Combined with MAC randomization on WiFi by default on 4.1 resolves the most problematic privacy issues that were present on Qubes presence.

It would be, if that were actually the behavior I got

Would have to pop PacketFence, pay for their fingerbank subscription and play there to see if your device gets correctly fingerprinted. My intuition here would be that you would be classified as RedHat/Fedora/Centos because of dhcp quirks, not hostname.

That's fair. But it's better to at least make the attacker work to identify your device

The process I used to test is pretty simple. I followed the instructions, then connected to my network with Wireshark running on a physically-separate system on the same network. Searching through the logs for my NetVM's hostname confirmed that my NetVM was, in fact, sending its hostname to the network. It's also worth noting that I tested on a Debian 11 template, since Fedora templates don't seem to detect my wireless card

[3hhh]

Hm interesting. I run on a debian 11 template as well and it works for me. I admit I checked on router level DHCP logs only though. I'll check with wireshark and report back...

[3hhh]

No, I cannot confirm this.

the DHCP communication I noticed (filter wireshark for bootp) consists of only 4 packets:

1. client --> router: discover
2. router --> client: offer
3. client --> router: request
4. router --> client: ack

None of these had my sys-net hostname inside. I rather noticed Server host name not given and Boot file name not given in wireshark and a bunch of zero bytes where it could have been.

I see a few reasons why your results might be different:

1. You didn't follow the instructions precisely, e.g. forgot the network manager configuration.
2. The network manager configuration isn't applied for some reason.
3. Do you use a minimal template? Maybe dhclient isn't included and NetworkManager falls back to some other implementation that sends the hostname. I think it's included in the isc-dhcp-client package on debian-11.

[NobodySpecial256]

1. I can confirm I followed the instructions exactly as explained in the guide (there aren't many instructions and I'm frankly somewhat insulted that this was even suggested as an option... Ok, I'm not actually insulted, but I probably should be)
2. I can confirm the NetworkManager configuration applied fine, since I made other changes to the NetworkManager config as well (maybe dhclient is ignoring my changes to dhclient.conf)
3. isc-dhcp-client is definitely installed in the template. I checked

[tlaurion]

The process I used to test is pretty simple. I followed the instructions, then connected to my network with Wireshark running on a physically-separate system on the same network. Searching through the logs for my NetVM's hostname confirmed that my NetVM was, in fact, sending its hostname to the network. It's also worth noting that I tested on a Debian 11 template, since Fedora templates don't seem to detect my wireless card

So Debian-11 behavior is not the same as Fedora, which is reported under #7701.

More specifically: https://github.com/QubesOS/qubes-issues/issues/7701#issuecomment-1221358272

The question here is if other templates offered by Qubes offer different hostname leaking behavior, which from the traces above shows that Debian template and others based sys-net qubes are probably leaking sys-net as of today.

So the issue here is to either have a dhcp-client.conf or not, and depending on the dhcp client deployed in template or not, a different behavior.

My point in that issue is that the behavior should be the same across all templates if Qubes OS wants to claim that hostname is not leaked, and then unifying the config (or lack thereof in case of Fedora vs Debian) so that randomization works on top of said different used DHCP clients, or that config not being needed by default. Putting a config in place doesn't mean its parsed not used, which seems to be the case here, and would require to dig back into what is deployed under which templates to make the point addressed by devels. So dhclient vs isc client must lead to different behaviors, different fingerprinting possibilities, and more documentation being produced to differenciate those templates needs for hostname randomization.

On Fedora's dvm sys-net:

[user@sys-net ~]$ sudo journalctl --boot 0 | grep -i dhcp
Oct 20 17:20:03 sys-net NetworkManager[495]: <info>  [1666300803.8714] dhcp-init: Using DHCP client 'internal'

So the behavior there comes plainly from NetworkManager, without any other client at play and without a dhcp-client.config What is your first line output on debian based sys-net @NobodySpecial256?

my guess is that @3hhh tested and reported from default Fedora template's based sys-net, which I also tested and report no hostname being leaked. I would recommend renaming the issue to scope to debian templates, or if you are willing to test other templates, extend the scope to non-Fedora templates based sys-net defaults (leak/non-leak defaults) and anonymizing hostname on those/proposing to change deployed dhcp client tools to being the same for all.

[3hhh]

Well, I'm sorry, but I cannot reproduce your issue.

[3hhh]

***@***.*** ~]$ sudo journalctl --boot 0 | grep -i dhcp
Oct 20 17:20:03 sys-net NetworkManager[495]: <info>  [1666300803.8714] dhcp-init: Using DHCP client 'internal'

Interesting. Mine on debian is

Oct 21 07:18:04 d-sys-net NetworkManager[500]: <info>  [1666329484.7053] dhcp-init: Using DHCP client 'dhclient'

[3hhh]

I double checked the salt state I apply to my debian-11 template used by sys-net-dvm:

It creates two root-owned 644 files:

/etc/NetworkManager/conf.d/use-dhclient.conf:

[main]
dhcp=dhclient

/etc/dhcp/dhclient.conf:

# Configuration file for /sbin/dhclient.
#
# This is a sample configuration file for dhclient. See dhclient.conf's
#       man page for more information about the syntax of this file
#       and a more comprehensive list of the parameters understood by
#       dhclient.
#
# Normally, if the DHCP server provides reasonable information and does
#       not leave anything out (like the domain name, for example), then
#       few changes must be made to this file, if any.
#

option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;

#disable hostname sending:
#send host-name = gethostname();
request subnet-mask, broadcast-address, time-offset, routers,
        domain-name, domain-name-servers, domain-search, host-name,
        dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn, dhcp6.sntp-servers,
        netbios-name-servers, netbios-scope, interface-mtu,
        rfc3442-classless-static-routes, ntp-servers;

#send dhcp-client-identifier 1:0:a0:24:ab:fb:9c;
#send dhcp-lease-time 3600;
#supersede domain-name "fugue.com home.vix.com";
#prepend domain-name-servers 127.0.0.1;
#require subnet-mask, domain-name-servers;
#timeout 60;
#retry 60;
#reboot 10;
#select-timeout 5;
#initial-interval 2;
#script "/sbin/dhclient-script";
#media "-link0 -link1 -link2", "link0 link1";
#reject 192.33.137.209;

#alias {
#  interface "eth0";
#  fixed-address 192.5.5.213;
#  option subnet-mask 255.255.255.255;
#}

#lease {
#  interface "eth0";
#  fixed-address 192.33.137.200;
#  medium "link0 link1";
#  option host-name "andare.swiftmedia.com";
#  option subnet-mask 255.255.255.0;
#  option broadcast-address 192.33.137.255;
#  option routers 192.33.137.250;
#  option domain-name-servers 127.0.0.1;
#  renew 2 2000/1/12 00:00:01;
#  rebind 2 2000/1/12 00:00:01;
#  expire 2 2000/1/12 00:00:01;
#}

[3hhh]

So all of the above needs to be applied to the base template, i.e. debian-11. That might be a bit unclear in https://github.com/Qubes-Community/Contents/blob/master/docs/privacy/anonymizing-your-mac-address.md#anonymize-your-hostname. Btw I also tested different owners. That worked for me, too.

[3hhh]

@tlaurion I just tested on fedora-36 as well and it gave me the dhcp-init: Using DHCP client 'dhclient' log entry. So maybe you got something wrong, too? Btw on Fedora the package dhcp-client seems to contain the ISC dhclient and probably needs to be installed.

I didn't create a tcpdump for fedora though.

EDIT: I didn't create the /etc/dhcp/dhclient.conf file on fedora.

[tlaurion]

@3hhh :

[user@sys-net ~]$ sudo rpm -q --whatprovides /etc/dhcp/dhclient.conf
error: file /etc/dhcp/dhclient.conf: No such file or directory

Might have removed it....?

[user@sys-net ~]$ cat /etc/os-release 
NAME="Fedora Linux"
VERSION="36 (Thirty Six)"
ID=fedora
VERSION_ID=36
VERSION_CODENAME=""
PLATFORM_ID="platform:f36"
PRETTY_NAME="Fedora Linux 36 (Thirty Six)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:36"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f36/system-administrators-guide/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=36
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=36
PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"

Files under /etc/NetworkManager

[user@sys-net ~]$ sudo find  /etc/NetworkManager/ -type f 
/etc/NetworkManager/NetworkManager.conf
/etc/NetworkManager/dispatcher.d/30-qubes-external-ip
/etc/NetworkManager/dispatcher.d/qubes-nmhook

What files are provided by which package:

[user@sys-net ~]$ find  /etc/NetworkManager/ -type f | while read file; do rpm -q --whatprovides $file; done | uniq
NetworkManager-1.38.4-1.fc36.x86_64
qubes-core-agent-network-manager-4.1.37-1.fc36.x86_64

File integrity deviation report from rpm on packages providing the files in question (and other files provided by such packages):

[user@sys-net ~]$ find  /etc/NetworkManager/ -type f | while read file; do rpm -q --whatprovides $file; done | uniq | while read package; do sudo rpm -V $package; done
S.5....T.  c /etc/NetworkManager/NetworkManager.conf

Extract from man rpm:

              S file Size differs
              M Mode differs (includes permissions and file type)
              5 digest (formerly MD5 sum) differs
              D Device major/minor number mismatch
              L readLink(2) path mismatch
              U User ownership differs
              G Group ownership differs
              T mTime differs
              P caPabilities differ              S file Size differs
              M Mode differs (includes permissions and file type)
              5 digest (formerly MD5 sum) differs
              D Device major/minor number mismatch
              L readLink(2) path mismatch
              U User ownership differs
              G Group ownership differs
              T mTime differs
              P caPabilities differ

So /etc/NetworkManager/NetworkManager.conf was touched after deployment, but I do not recall having removed anything... Sorry if I did?

files under /etc/dhcp:

[user@sys-net ~]$ sudo find  /etc/dhcp/ -type f
[user@sys-net ~]$

None.

Checking console history of fedora-36-dvm: I confirm I touched

• /etc/NetworkManager/NetworkManager.conf
• files under /usr/lib/NetworkManager

[user@sys-net ~]$ sudo find  /usr/lib/NetworkManager/ -type f | while read file; do sudo rpm -q --whatprovides $file; done 
qubes-core-agent-network-manager-4.1.37-1.fc36.x86_64
file /usr/lib/NetworkManager/conf.d/32-randomize-eth-mac.conf is not owned by any package
qubes-core-agent-network-manager-4.1.37-1.fc36.x86_64
dhcp-client-4.4.3-4.P1.fc36.x86_64
NetworkManager-pptp-1.2.10-1.fc36.x86_64
NetworkManager-ssh-1.2.12-3.fc36.x86_64
NetworkManager-openvpn-1.8.18-1.fc36.x86_64
NetworkManager-vpnc-1.2.8-1.fc36.x86_64
NetworkManager-openconnect-1.2.8-2.fc36.x86_64

Yes. I added ethernet mac randomization which fits my work use case (and to me is a safer default).

Other than that, the files there are as deployed per packages:

[user@sys-net ~]$ sudo find  /usr/lib/NetworkManager/ -type f | while read file; do sudo rpm -q --whatprovides $file; done | grep -v randomize| uniq | while read package; do sudo rpm -V $package; done
[user@sys-net ~]$

---

To be confirmed by others:

Uncommented content of that file on my side:

[user@sys-net ~]$ grep -v "^#" /etc/NetworkManager/NetworkManager.conf

[main]
dns=default
plugins=keyfile

[logging]
[keyfile]
unmanaged-devices=mac:fe:ff:ff:ff:ff:ff

EDIT: I didn't create the /etc/dhcp/dhclient.conf file on fedora.

What is the output of sudo rpm -q --whatprovides /etc/dhcp/dhclient.conf?

I'm sorry if my results are different, I might have modified something under my setup, but I do not remember doing so? sys-net Dispvm based on fedora-36-dvm...

[3hhh]

@tlaurion Maybe I'm missing something obvious here... but what is the point you want to make?

I'm asking because I can see from the below that you did not deploy the dhclient configuration at e.g. /etc/NetworkManager/conf.d/use-dhclient.conf or possibly incorrectly deployed it inside sys-net-dvm instead of fedora-36, i.e. I'm not surprised to see that dhclient isn't used according to your log from above.

Files under /etc/NetworkManager

[user@sys-net ~]$ sudo find  /etc/NetworkManager/ -type f 
/etc/NetworkManager/NetworkManager.conf
/etc/NetworkManager/dispatcher.d/30-qubes-external-ip
/etc/NetworkManager/dispatcher.d/qubes-nmhook

I have never tested whether the hostname is not sent without the dhclient configuration on fedora-36. I can test that as well, but it's a different topic IMHO.

Side note: My /etc/NetworkManager/NetworkManager.conf doesn't have the plugins=keyfile line.

[aronowski]

Especially since most Windows devices have randomized hostnames set at install time, random hostnames will be less suspicious in a PCAP

One can configure their workstation so ultimately sys-net will be named like a random Windows machine with each boot. I have such a configuration. Ultimately I believe it's easier to check, if everything's right since one can easily see their sys-net's name rather than inspecting packets and also it should always work - no matter if another release screws something up with dhclient or others. I can write documentation on that if you want, but it's up to the superiors if they even want it there.

[3hhh]

LOL. I just realized that neither debian-11 nor fedora-36 templates send the hostname anymore in their default configuration. I guess NetworkManager changed its behaviour.

It would be nice if someone could verify this, but I think @tlaurion already did it above for fedora-36.

I'll go back to the defaults and run them for a while.

If that's true, the guide can be removed entirely.

[tlaurion]

@tlaurion Maybe I'm missing something obvious here... but what is the point you want to make?

@3hhh let's remember the name of the issue here: "Anonymizing hostname doesn't work". Randomizing hostname is not the same as Anonymizing, which if hostname doesn't leak would fulfil this ticket purposes.

This is why I didn't reply yet: having faced weird behavior trying to install new templates from upstream documentation (qubes-dom0-update redirects to qvm-template and fails, currently). That is cheap justification on my side, I could restore templates from backup and go from there, but I'm reducing my involvements that cannot be replicated because upstream bugs are not fixed for the moment. Otherwise things cannot be properly replicated by anybody with additional efforts and knowledge, that should not be required. Consequently, I did not confirmed nor infirmed with prior replies, that Fedora 36 defaults are anonymizing hotstname (not leaking it) on default installation as of now. And I'm sorry for the confusion. My setup doesn't leak hostname. But that is not proof of anything.

Randomizing hostname is a different issue and should be dealt with separately.

My take here is that this issue should be closed when replicating and validating behavior from fresh downloaded templates is possible, confirming no hostname is leaked from sys-net through tcpdump at least on Qubes default deployed templates (Debian-11 Fedora-36), while some push should be done for other Qubes installable templates that could be used to create sys-net from.

My interest here is that defaults should do the right thing in regard of this issue.

[NobodySpecial256]

@tlaurion

What is your first line output on debian based sys-net @NobodySpecial256?

Oct 30 03:05:25 PC-11031 NetworkManager[478]: <info>  [1667099125.1243] dhcp-init: Using DHCP client 'dhclient'

That's the output I got, after following the instructions to not send hostnames on my sys-net. You can see I already had my hostname randomized prior to trying to hide thr hostname entirely

@aronowski

One can configure their workstation so ultimately sys-net will be named like a random Windows machine with each boot. I have such a configuration. Ultimately I believe it's easier to check, if everything's right since one can easily see their sys-net's name rather than inspecting packets and also it should always work - no matter if another release screws something up with dhclient or others.

Yeah, even if/when I get my sys-net to not send its hostname, I think I'm gonna keep hostname randomization in-place as a fallback in case something goes wrong with NetworkManager. It's also much easier to verify that a hostname is randomized, as opposed to verifying in a PCAP that it's not being sent

@3hhh

LOL. I just realized that neither debian-11 nor fedora-36 templates send the hostname anymore in their default configuration. I guess NetworkManager changed its behaviour.

It would be nice if someone could verify this, but I think @tlaurion already did it above for fedora-36.

I checked on my own sys-net in case maybe a recent update fixed this. Still no luck, it's sending the hostname just like it was when I created this issue. But after trying on a completely-unmodified Debian 11 standard template, it seems my hostname is indeed not being sent

So this issue appears to be specific to cases where sys-net is based on a minimal template.

[3hhh]

Well, it would be nice to identify the root cause of the different behaviour across templates then. At least on the NetworkManager end, the doc doesn't state any changes from previous behaviour and https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/584 doesn't provide news either.

[feffiboujike]

I discuss this issue in this thread https://forum.qubes-os.org/t/anonymizing-mac-address-documentation-clarification/14731/4

Based on my observations NetworkManager behaves differently to its documentation with regard to hostname sending. The current Qubes documentation for anonymizing hostname doesn't actually do anything on debian-11.

[3hhh]

@NobodySpecial256 Do you happen to have an /etc/hostname file in your sys-net?

@feffiboujike identified that having that file results in the hostname being sent by NetworkManager.

[feffiboujike]

The reason the hostname is not being sent on debian-11 is because /etc/hostname (the static hostname) file is missing (it needs to be present when NetworkManager service is started).

I can't confirm what is happening on Fedora or debian-11-minimal but I would say the reason hostname is or is not being sent is due to that file.

You can run the command nmcli general hostname to see what hostname NetworkManager is using. If the hostname is blank then nothing will be sent.

It is a good thing that this file is missing because I don't believe there is any other way to prevent the hostname being sent globally until https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/584 is resolved. The current method of switching to dhclient and commenting out the send host-name line is not a solution. If the /etc/hostname file is present then dhclient will still send a hostname, regardless of how dhclient is configured. There is another suggestion on the forums that removing dhclient.conf should prevent hostname sending, but this doesn't work either.

It would be good to alert the Qubes developers about this so that they don't introduce an /etc/hostname (at least not until the NM bug is resolved).

[ghost]

With PR #228 , should this issue be closed ?

It would be good to alert the Qubes developers about this so that they don't introduce an /etc/hostname (at least not until the NM bug is resolved).

(ping @fepitre / @unman / @marmarek)

[NobodySpecial256]

If the behavior is dependent on the hostname file being missing, would a missing hostname not be a giveaway that the user is running Qubes? Since every desktop Linux distro has a hostname file by default

For this reason, perhaps hostname randomization still makes sense to include

[3hhh]

If the behavior is dependent on the hostname file being missing, would a missing hostname not be a giveaway that the user is running Qubes? Since every desktop Linux distro has a hostname file by default

IIRC Qubes OS doesn't explicitly delete host OS files.

For this reason, perhaps hostname randomization still makes sense to include

If you still want it, generate a random /etc/hostname file before it is read by NetworkManager.

Anyway this issue can be closed unless the OP disagrees IMHO.

[NobodySpecial256]

I'm this issue's OP and I disagree. I still have some unaddressed concerns within the scope of this issue:

IIRC Qubes OS doesn't explicitly delete host OS files.

Even if Qubes doesn't explicitly delete the hostname file, the file's presence differs on Qubes vs bare-metal installs of the same OS a template is based on. This behavior difference can determine a user to be running Qubes regardless of the means by which the difference originated. So if we really want Qubes users to blend in with other users on a network (or at least other Linux users), it might make more sense to set the hostname to something plausible

If you still want it, generate a random /etc/hostname file before it is read by NetworkManager.

This is what I do currently with my sys-net. I have a script that randomizes the hostname on every boot (the old hostname randomization script, modified to use Windows-like hostnames). But without a standardized method of randomizing hostnames (some use Windows-like, others use the value of $RANDOM, and other implementations could pop-up), users could be made identifiable by differences in how hostnames are randomized on their individual systems

Putting a "standard" method of randomizing hostnames into this guide, something that isn't identifiably unique to Qubes users or people who follow the specific method, could solve this issue. Assuming that's the path taken, I might suggest Windows-style hostnames because it's easy to generate a convincingly Windows-like hostname, whereas most Linux distros ask users to specify hostnames at install-time, and defaults almost always contain information about the hardware running the OS. This makes it much more difficult to programmatically and randomly generate convincing hostnames

On a related note, I take issue with the randomization process this repo used to recommend. Almost nobody in the wild will have a hostname matching the pattern generated by the script, as no OS generates similar-looking hostnames by default. Users could easily be singled out by the fact that they run the hostname randomization script, without even basic effort to fingerprint systems. This is why I prefer Windows-style hostnames, and I consider it a basic requirement for the hostnames to at least look convincingly like some other OS

If the goal is to simply make all Qubes users look alike, allowing networks to see sys-net as the hostname makes perfect sense. But the explicit goal of changing hostnames was always to make Qubes users look like non-Qubes users

I might add that while the current behavior of NetworkManager is to hide hostnames when the hostname file is missing, it's already been established that this is undocumented behavior and can change in a future update without warning. Do we really want to rely on undocumented behavior? Do we expect users to re-check that their hostname is still anonymized every time NetworkManager receives an update?

[3hhh]

I believe we've already had that discussion multiple times and apparently we cannot come to a single conslusion.

So do what you like and feel free to document that as an alternative and maintain it. I won't do it for you though.

Anyway the original issue seems to be resolved as I haven't heard you state that the current /etc/hostname method doesn't work with debian-11-minimal.

[awokd]

Content moved to https://forum.qubes-os.org/c/guides/14.