DNS questions (which necessarilly include IP addresses) are personally
indentifying information in the sense of GDPR
(https://gdpr.eu/eu-gdpr-personal-data/ explicitly lists IP address as
PII). Sending those packets to Google or Cloudflare is "forwarding"
this PII to them. GDPR says that information which is not enough to
identify individuals still needs to be protected because it may be
combined with other information or processed with improved technology
later. So even though the information in DNS alone it not very big, it
may be interpreted as protected information in various scenarios.
When Fedora is installed by an end-user, they must have the reasonable
expectation that Fedora will contant Fedora servers for updates and
status checks and such. But the case of DNS packets is different,
because the dns servers are not under our control. While most of the
time the information leak through DNS is negligible, we can't rule out
scenarios where it could be considered more important.
Another thing to consider is that ISP and other local internet access
mechanisms are probably worse overall for privacy compared to google and
cloudflare dns servers. Nevertheless, they are more obvious to users and
fit better in the regulatory framework, because there are local laws
that govern them and implicitic or explicit agreements for their use.
Whereas US-based servers are foreign and are covered by different rules.
The fallback DNS servers don't matter most of the time because
NetworkManager will include the servers from a DHCP lease. So
hopefully users will not see any effect from the change done in this
patch. Right now I think it is better to avoid the legal and privacy
risk. If it turns out this change causes noticable problems, we might
want to reconsider. In particular we could use the fallback servers
only in containers and such which are not "personal" machines and there
is no particular person attached to them.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3C4KESHIMZDB6XCFO4EOBEDV4Q2AVVQ5/
I think we could provide a default dns server list more reasonably if
there was some kind of privacy policy published by Fedora and users
could at least learn about those defaults. Sadly, we don't have any
relevant privacy policy (https://pagure.io/Fedora-Council/tickets/issue/53).
There were some things left in the main package that should have
been in the sub package (including networkd.conf). This is an attempt
to make the list of files in the networkd package more correct.
It explicitly tries to leave sytemd-network-generator and the network
targets in the main package.
This way, if one wants to opt-out of resolved, installing a preset
that disables the service is enough. Previously that would only disable
the service, but a dangling symlink would be created.
I'm not entirely sure if this is the right form...
Is Conflicts? useful when we have Obsoletes?
Seem to work OK. I tested:
dnf --installroot=... install x86_64/systemd-standalone-sysusers-246.6-2.fc34.x86_64.rpm x86_64/systemd-standalone-tmpfiles-246.6-2.fc34.x86_64.rpm
→ succeeds with a new installation
→ fails if the installroot already had systemd installed
dnf --installroot=... install x86_64/systemd{,-libs,-pam}-246.6-2.fc34.x86_64.rpm noarch/systemd-noarch-246.6-2.fc34.noarch.rpm
→ uninstalls the two standalone packages
These packages include binaries that link to a static version of
libsystemd-shared, so they don't depend on the systemd-libs package at
runtime.
These packages are intended to expose systemd-tmpfiles and systemd-sysusers
to non-systemd systems, such as container images.
Note that static linking only pulls in the small subset of functions from
libsystemd-shared that are actually used by the binaries, so the total size of
a statically linked binary is much smaller than the sum of the shared binary
with the shared library. The resulting binaries on an x86_64 build have 272KB
(tmpfiles) and 180KB (sysusers).
This commit relies on the -Dstandalone-binaries=true build configuration that
was pushed upstream in PR 16061 and released in systemd v246.
We need to disable it by default in resolved so that it doesn't fight
with avahi for the port when both are started up in parallel.
I also moved nss-files before nss-resolve. This is unfortunate because
resolved cached files and with the move, the file will be re-read on each
query. Nevertheless, we want nss-files to have higher priority than nss-mdns
to honour local config. Fortunately, only some people put lots of entries
in /etc/hosts, so the inefficiency incurred by this isn't important for
most users.
nss-myhostname is moved after nss-files, following the change in
upstream recommendations.
error: line 639: Trigger fired by the same package is already defined in spec file: %post libs
It's not clear what rpm is complaining about here, but the two %triggerun's
for the same package seem to be the most likely offender.
I wanted to avoid applying to preset reset twice, alas.
The default line is
> hosts: files dns myhostname
Some people might insert mymachines, most likely as:
> hosts: mymachines files dns myhostname
The scriptlet for nss-mdns inserts mdns before dns:
> hosts: ... files mdns4_minimal [NOTFOUND=return] dns ...
The scriptlet replaces 'files dns myhostname' with
> resolve [!UNAVAIL=return] myhostname files dns
This follows the upstream recommendation. myhostname is ordered earlier
because
a) it's more trustworthy than files or especially dns
b) resolve synthetizes the same answers as myhostname, so it doesn't
make much sense to have myhostname at any other place than directly
after resolve, so that if resolve is not available, we get answers for
the names that myhostname is able to synthesize with the same priority.
See https://fedoraproject.org/wiki/Changes/systemd-resolved.
The acl package is not present in the buildroots when building
in bootstrap mode, but test-acl-util needs /usr/bin/getfacl.
Thus it should be an explicit build-time dependency.
Also only execute the fallback when we're upgrading the RPM package.
Add a comment to indicate the actual bug in systemd v239 we're trying to
fix with this fallback.
Tested: Upgraded from v239 on a machine and confirmed that running
`sudo systemctl status` was working as expected after the upgrade, rather
than failing with "Access denied."
