04 Feb 2025 2:00pm GMT

BalCCon 2k24 - Invisible Path

Fedora had a booth at BalCCon for the 8th time in a row. I'm personally very happy that we kept this streak as the first BalCCon where Fedora had presence is when I first became Ambassador in Serbia . I'm not aware of any other booths that had such a strong presence.

For those unaware of this conference, it is focused on: hacking, information security, privacy, technology & society, making, lock-picking, and electronic arts. For a sharp eye, these are well-rounded topics for Free Software-oriented people and that makes it rather important conference in the region.
In addition to all that, people that organize these events are extremely welcoming and heart-warming people! Working in tandem: founders, volunteers, and speakers - all show teamwork in very challenging times, both now as well as in the past… For an untrained eye it would seem that every BalCCon is a smooth sailing, but the truth is that there is a lot of effort and sacrifice required in realizing it. Every single person behind it, is a devoted, humble, and passionate contributor to the event.

Attendees range from teenagers, students, younger and older adults all interested in learning, sharing and socializing with each others. In other words, the conference is not solely focused on lectures and workshops, but also on bringing similar-minded people together and providing them a safe place to connect.

Fun is also huge part of the event as there is a karaoke evening (don't miss that one ) and a rakia tasting and sharing night adequately named "Rakija leaks".

At Fedora booth we try to engage people and encourage questions, to better understand what people like and dislike, to provide them guidance and invite them to join the community. We always keep the positive attitude towards all Free and Open Source Software and never fuel or support distro-wars. We love Fedora, but that doesn't exclude love towards other distros as well (it just may not be as strong ).

This approach had an impact that many non-Fedora users liked to talk to us and stuck around. That relationship grown to constructive discussions about strengths of Fedora and their OSes of choice. Many of them converted over time , or at least found a perfect sweet-spot for Fedora in their everyday life.

Due to the import customs in Serbia, swag has been a hit and miss sometimes, but we try to keep the booth entertaining even in the absence of much-adored stickers.

This year we've had a revamp of our booth with new Fedora logo for the roll-up banners and the table cloth. And it was at a perfect time, as Fedora booth was visible in an article of country's most popular printed IT magazine Svet Kompjutera.

This was all due to the amazing support from jwflory who displayed great amount of innovative and pro-active energy!

Booth appearance has evolved over the years and become more and more inviting to everyone. An organizing volunteer even approached me to say that people've been asking if Fedora will have a booth again this year, as they found it very interesting - not only from the Project's aspect, but also because, since the first year we tried to bring something that would draw people to come and talk to us.

To give some examples:

• Awesome demo of touchless gaming concept by our dear thunderbirdtr (2015)
• Fedora on handheld touchscreen devices (2018)
• AAA Gaming on Fedora out-of-the box (with RPM Fusion only) (2022)
• Introduction of Fedora cookies (2023)
• Fedora baby (2024)

There are plans and ideas for future booths too, such as SyncStar setup, SELinux challenge box, DIY pin machine, other quizes, …

Here is the timeline in photos from 2015 - 2024 (there are missing photos due to, either COVID, or just an unfortunate oversight on my end):

Huge thanks for the support from jwflory, thunderbirdtr, nmilosev, nsukur, bitlord, and especially to my dear wife littlecat that makes the booth incredibly appealing.

If you've never been to Serbia, Novi Sad, or BalCCon, you should definitely consider visiting and we'll do our best to be good hosts and dedicate some of our times just for you!

The post Balkan Computer Congress, Novi Sad, Serbia appeared first on Fedora Community Blog.

04 Feb 2025 10:00am GMT

03 Feb 2025 7:30pm GMT

03 Feb 2025 7:30pm GMT

January has gone by pretty fast. Here's some longer form thoughts about a few things that happened this last week.

01 Feb 2025 5:49pm GMT

When it comes to the Linux desktop experience, one thing remains constant: the occasional frustration with mouse scrolling. Whether you're navigating through web pages, sifting through documents, or coding in your favorite editor, smooth and predictable scrolling is essential. Unfortunately, not all Linux desktop environments handle mouse scroll events gracefully. This is where imwheel steps in to save the day.

The Scrolling Conundrum on Linux

Despite the significant strides in Linux desktop environments like GNOME, KDE Plasma, and Xfce, inconsistencies in mouse scroll behavior persist. Users frequently encounter issues such as:

• Slow or Unresponsive Scrolling: Certain applications, particularly web browsers and terminal emulators, often exhibit sluggish scroll speeds that can make navigation a chore.
• Inconsistent Behavior Across Applications: Some programs adhere to the system-wide scroll settings, while others stubbornly ignore them, leading to an uneven user experience.
• Lack of Customization: The default settings provided by many desktop environments rarely offer the granular control needed to fine-tune scrolling to individual preferences.
• Hardware Compatibility Issues: High-DPI mice and those with tilt-scroll functions sometimes don't play well with the underlying system, resulting in erratic or hyper-sensitive scrolling.

These issues can be a significant hindrance, especially for users who demand precision and efficiency in their workflow.

Enter imwheel

imwheel is a lightweight utility that intercepts and modifies mouse wheel input on the fly, giving users the power to adjust the scroll behavior at a granular level. Here's why it remains an indispensable tool:

Customization at Your Fingertips

With imwheel, you can tailor your mouse scroll settings to perfectly suit your needs. Whether you need to ramp up the speed for faster navigation or dial it down for precision work, imwheel allows you to modify scroll sensitivity with ease. You can even set up custom scrolling profiles for different applications, ensuring that every piece of software behaves just the way you want it to.

Bridging the Gap

While modern desktop environments offer various settings to adjust scroll behavior, they often fall short of providing the detailed control that imwheel offers. Many of these environments have default configurations that may work well for most users but leave little room for customization when things go awry. imwheel bridges this gap by giving you a simple yet powerful way to tweak scroll acceleration and sensitivity, enhancing compatibility across a wide range of applications and hardware.

Wide-Ranging Compatibility

Even as Linux transitions toward newer display protocols like Wayland, a significant number of users still rely on X11. imwheel continues to be a vital tool for X11 users, ensuring that even on legacy systems, you can achieve consistent and smooth scrolling. Its ability to work across various distributions and desktop environments further cements its relevance.

Installing and Configuring imwheel

Getting started with imwheel is straightforward. Here's a quick guide to installation and configuration on some popular Linux distributions:

Installation

• Debian/Ubuntu-based distros: sudo apt install imwheel
• Fedora: sudo dnf install imwheel
• Arch Linux: sudo pacman -S imwheel

Configuration

Once installed, you can customize imwheel by editing the ~/.imwheelrc file. Here's an example configuration that increases vertical scroll speed:

".*"
None, Up, Button4, 4
None, Down, Button5, 4

In this configuration, the number 4 specifies the scroll acceleration. Adjusting this value allows you to fine-tune the scrolling speed to your liking. After updating the configuration, apply the changes by restarting imwheel:

imwheel -kill

For convenience, you can add the imwheel -kill command to your startup applications to ensure that imwheel is automatically launched when you log in.

Conclusion

In the ever-evolving landscape of Linux desktop environments, the need for precise control over hardware behavior remains paramount. imwheel continues to be a relevant and invaluable tool for those who find themselves frustrated by inconsistent mouse scroll behavior. By offering detailed customization options and bridging the gap left by default system settings, imwheel ensures that your scrolling experience is as smooth and responsive as it should be.

If you've ever found yourself fighting with your mouse scroll settings on Linux, give imwheel a try. It might just be the fix you need to enhance your workflow and reclaim the fluidity of your desktop experience.

The post Why imwheel Is Still Relevant for Linux Users in 2025 appeared first on Hamradio.my - Amateur Radio, Tech Insights and Product Reviews by 9M2PJU.

01 Feb 2025 7:47am GMT

The kernel team is working on final integration for Linux kernel 6.13. This version was just recently released, and will arrive soon in Fedora Linux. As a result, the Fedora Linux kernel and QA teams have organized a test week from Sunday,February 02, 2025 to Sunday, February 09, 2025. The wiki page in this article contains links to the test images you'll need to participate. Please continue reading for details.

How does a test week work?

A test week is an event where anyone can help ensure changes in Fedora Linux work well in an upcoming release. Fedora community members often participate, and the public is welcome at these events. If you've never contributed before, this is a perfect way to get started.

To contribute, you only need to be able to do the following things:

• Download test materials, which include some large files
• Read and follow directions step by step

The wiki page for the kernel test week has a lot of good information on what and how to test. After you've done some testing, you can log your results in the test week web application. If you're available on or around the days of the event, please do some testing and report your results. We have a document which provides all the necessary steps.

Happy testing, and we hope to see you on one of the test days.

31 Jan 2025 2:43pm GMT

This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.

Week: - 27th January - 31th January 2025

Infrastructure & Release Engineering

The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It's responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.).
List of planned/in-progress issues

Fedora Infra

• In progress:
  • Planned Outage - updates / reboots - 2025-01-29 21:00UTC
  • [CommOps] Open Data Hub on Communishift
  • retire easyfix
  • bvmhost-p09-03 ends in emergency mode
  • Add StartInstanceRefresh permission for fedora-ci-testing-farm user in AWS
  • Deploy Element Server Suite operator in staging
  • Create CentOS calendar
  • Pagure returns error 500 trying to open a PR on https://src.fedoraproject.org/rpms/python-setuptools-gettext
  • a real domain name for konflux
  • Retirement of `monitor-dashboard` tracker
  • Create a POC integration in Konflux for fedora-infra/webhook-to-fedora-messaging
  • Retirement of `monitor-gating` tracker
  • maubot-meetings bot multi line paste is cut
  • setup ipa02.stg and ipa03.stg again as replicas
  • Manage our new testing.farm domain via AWS Route53
  • Add support for creating RDS instances under `testing-farm-` prefix
  • Move OpenShift apps from deploymentconfig to deployment
  • The process to update the OpenH264 repos is broken
  • httpd 2.4.61 causing issue in fedora infrastructure
  • Support allocation dedicated hosts for Testing Farm
  • fedorapeople.org directory listing theme needs refreshing
  • EPEL minor version archive repos in MirrorManager
  • vmhost-x86-copr01.rdu-cc.fedoraproject.org DOWN
  • Add yselkowitz to list to notify when ELN builds fail
  • Cleaning script for communishift
  • rhel7 eol
  • move resultsdb-ci-listener deployment pipeline
  • rhel7 EOL - github2fedmsg
  • Move from iptables to firewalld
  • Help me move my discourse bots to production?
  • fedmsg -> fedora-messaging migration tracker
  • rhel9 adoption
  • Create monitoring tool for rabbitmq certificates
  • Replace Nagios with Zabbix in Fedora Infrastructure
  • Migration of registry.fedoraproject.org to quay.io
  • Commits don't end up on the scm-commits list
• Done:
  • Can we get passkey auth support for FAS logins
  • fedora-messaging times out when pushing to a fork on src.f.o
  • Problem with adding new admin to a star project
  • Messages sent to test-request@lists.fedoraproject.org are failing to arrive
  • Please generate the Fedora 44 gpg key
  • Opt-in for AWS region to mx-central-1 acct:125523088429
  • Opt-in for AWS region to ap-southeast-7 acct:125523088429
  • Need help investigating cfp.fedoraproject.org email delivery failure to michel@michel-slm.name (pretalx.com works fine)
  • distgit-bugzilla-sync poddlers in both staging and prod downloading a lot from production
  • Bodhi is being flooded with invalid requests
  • builds failing due to full disks
  • Inactive packagers policy for the F41 release cycle
  • reinstall memcached instances with rhel9
  • many CentOS Stream repos on mirrors have bad hashes
  • Impossible to push/share new AMIs (CentOS Stream) due to reached quota
  • Direct database access to message bus date for Greg Sutcliffe
  • Fedora group on Gitlab.com requires 2FA
  • RFE: fedoras container image register change
  • rpm-ostree error (503) from hetzner to

CentOS Infra including CentOS CI

• In progress:
  • Adapt zabbix-agent ansible role for new hardware raid controller
  • Setup hyperscale 10 image build tags
  • [spike] : investigating options/alternatives for the upcoming DC move
  • Zuul CI namespace
  • Testing Jenkins - c10s x86_64 metal doesn't provision
  • Release Improvements
• Done:
  • Please whitelist mirror.plusline.net (formerly ftp.plusline.net)
  • Setup hyperscale-kernel tag for c10s

Release Engineering

• In progress:
  • please remove unwanted rpmdevtools commit accidentally pushed to rawhide branch
  • 300+ F42FTBFS bugzillas block the F41FTBFS tracker
  • Unretire tachyon
  • Unretire ethos
  • Fedora 42 Mass Rebuild Tracker
  • Quay.io repository for fedora-bootc-tier-x
  • Missing rawhide branch for recently created package 'pybind11-json'
  • F42 Self-Contained Change: Switch to EROFS for Live Media
  • Please remove two branches from octave-iso2mesh
  • Send compose reports to a to-be-created separate ML
  • .sqlite metadata missing in f41-updates and f41-updates-testing repositories
  • F42 system-wide change: GNU Toolchain update for F42 https://fedoraproject.org/wiki/Changes/GNUToolchainF42
  • Delete "firefox-fix" branch in xdg-desktop-portal
  • please create epel10 based el10-openjdk tag
  • Could we have fedoraproject-updates-archive.fedoraproject.org for Rawhide?
  • Investigate and untag packages that failed gating but were merged in via mass rebuild
  • a few mass rebuild bumps failed to git push - script should retry or error
  • Renaming distribution media for Fedora Server
  • Package retirements are broken in rawhide
  • Implement checks on package retirements
  • Untag containers-common-0.57.1-6.fc40
  • orphan-all-packages.py should remove bugzilla_contact entries from fedora-scm-requests as well
  • Packages that fail to build SRPM are not reported during the mass rebuild bugzillas
  • When orphaning packages, keep the original owner as co-maintainer
  • Create an ansible playbook to do the mass-branching
  • RFE: Integration of Anitya to Packager Workflow
  • Cleaning old stuff from koji composes directories
  • Fix tokens for ftbfs_weekly_reminder. script
  • Update bootloader components assignee to "Bootloader Engineering Team"for Improved collaboration
• Done:
  • Stalled EPEL package request: python-pytest-cov
  • Create missed Rawhide (F42) update for miniupnpd
  • Merge side tag f42-build-side-103691
  • untag qt5-5.15.16-2.fc42 and qt5-qtbase-5.15.16-2.fc42
  • No Fedora Budgie Atomic compose since 41.20241114.0
  • Make ppc64le Server_KVM image build not take two hours

If you have any questions or feedback, please respond to this report or contact us on #redhat-cpe channel on matrix.

The post Infra and RelEng Update - Week 05 2025 appeared first on Fedora Community Blog.

31 Jan 2025 10:00am GMT

Release Candidate versions are available in the testing repository for Fedora and Enterprise Linux (RHEL / CentOS / Alma / Rocky and other clones) to allow more people to test them. They are available as Software Collections, for a parallel installation, the perfect solution for such tests, and also as base packages.

RPMs of PHP version 8.4.4RC2 are available

• as base packages in the remi-modular-test for Fedora 39-41 and Enterprise Linux ≥ 8
• as SCL in remi-test repository

RPMs of PHP version 8.3.17RC1 are available

• as base packages in the remi-modular-test for Fedora 39-41 and Enterprise Linux ≥ 8
• as SCL in remi-test repository

ℹ️ The packages are available for x86_64 and aarch64.

ℹ️ PHP version 8.2 is now in security mode only, so no more RC will be released.

ℹ️ Installation: follow the wizard instructions.

ℹ️ Announcements:

• PHP 8.4.4RC2 available for testing
• PHP 8.3.17RC1 available for testing

Parallel installation of version 8.4 as Software Collection:

yum --enablerepo=remi-test install php84

Parallel installation of version 8.3 as Software Collection:

yum --enablerepo=remi-test install php83

Update of system version 8.4:

dnf module switch-to php:remi-8.4
dnf --enablerepo=remi-modular-test update php\*

Update of system version 8.3:

dnf module switch-to php:remi-8.3
dnf --enablerepo=remi-modular-test update php\*

ℹ️ Notice:

• version 8.4.4RC2 is in Fedora rawhide for QA
• EL-10 packages are built using RHEL-10.0-beta
• EL-9 packages are built using RHEL-9.5
• EL-8 packages are built using RHEL-8.10
• oci8 extension uses the RPM of the Oracle Instant Client version 23.7 on x86_64 or 19.25 on aarch64
• intl extension uses libicu 74.2
• RC version is usually the same as the final version (no change accepted after RC, exception for security fix).
• versions 8.3.17 and 8.4.4 are planed for February 13th, in 2 weeks.

Software Collections (php83, php84)

Base packages (php)

31 Jan 2025 6:35am GMT

31 Jan 2025 5:44am GMT

I run a home server since many decades ago with multiple services such as:

• Jellyfin media server
• NextCloud for family file storage
• Samba file server
• Home Assistant for home automation and bridge with Apple Home
• Virtual machines and Podman containers with various other services

Hardware setup is:

• Fedora Linux 40 on Intel NUC11TNBi3 with 16GB RAM and 256GB SSD
• Terramaster D6-320 storage enclosure with 6 SATA HDD, connected to computer by a USB-C cable; no RAID, just a bunch of disks I sporadically add whenever I need more space
• Autorsync daily backup to an old OpenWRT Buffalo router with a 6TB external HDD, located off-site, in the home of a relative

This server is critical for my family, yet several hard drives failed during all these years (that is why I have setup automated backups).

It was not until recently that I learned how to monitor the health of these HDDs using SMART. Get it installed with package smartmontools.

HDD manual health self-tests

When you get a new HDD, after connecting but before putting it into production, you must run a self-health check with command:

smartctl -t long /dev/sdz

Where /dev/sdz is the device name of your new HDD. This test will take more than 10 hours and can be done even with the HDD in use, but it will degrade performance, so I prefer to unmount all filesystems first.

You should run this health check sporadically from time to time.

You can also run 10 minutes health checks without bothering to take your services offline:

smartctl -t short /dev/sdz

To see results of these tests, I prefer using Alexander Shaduri's GSmartControl GUI, even if smartctl command can also display results. Here is the view of one HDD with the completion status of the health checks we triggered by the smartctl commands above, the Self-Tests tab.

As a general good practice, you must immediately stop using a HDD if you get many errors in the Error Log tab.

SMART error messages are very confusing and proprietary, and I have seen HDDs marked as healthy even if they present many error messages. So again, as a general good practice, if smartctl -l error /dev/sdz output is very long and is not a simple No errors logged, it is time to migrate data off of the HDD and replace it.

Automated health tests

The smartmontools package also installs a service that checks HDD health daily and sends a report by e-mail. On Fedora Linux this is activated by simply installing the package, but is useless if your system can't send e-mails, which is the way reports are delivered. So make sure you enable your server to send e-mails. There are many ways of doing this, the simplest one is using Gmail as relay.

If your HDD is starting to fail, you'll get an e-mail from the SMART daemon. If that happens, you must run more extensive health checks as described above. And check your backups and move your data off of the failing HDD.

Also, you should check the warranty of your HDDs. The more premium product lines of Seagate (IronWolf) and Wester Digital (Red) offer 3-year warranty and you should make sure you'll get these when you buy it. Use your HDD serial number to check if warranty coverage is still valid on Seagate and Western Digital websites. You can fill some forms and on the manufacturer's website to get a brand new replacement HDD.

30 Jan 2025 6:57pm GMT

29 Jan 2025 9:52pm GMT

29 Jan 2025 9:48pm GMT

29 Jan 2025 9:00pm GMT

Many users trust in a variety of VPN solutions to securely protect their privacy or access to personal or company's resources when connecting from an untrusted network. This may be an airport or cafe's WiFi network. This article describes how to use NetworkManager to improve that security.

Some months ago, researchers disclosed the TunnelVision vulnerability with ID CVE-2024-3661. The CVE describes a way to redirect traffic outside of the encrypted channel of a large number of VPN solutions. The attack is trivial for malicious agents with access to the network to which the user connects. They don't even need to exploit any obscure bug or hidden vulnerability. They only need to reconfigure one standard feature of the DHCP protocol.

The attack is based on DHCP installing some routes to your system. Let's begin by investigating what DHCP and routing are and how the attack makes use of them. If you only wish to know the solution, jump to the "Policy routing to the rescue" section, below. Jump to the "Configure NetworkManager" section to see how to effectively apply the mitigation in your system when configuring your VPN with NetworkManager.

DHCP

DHCP stands for Dynamic Host Configuration Protocol. It is a protocol to automatically assign IP addresses and other IP related configurations to hosts that connect to a network. When you connect to your home network and automatically get a private IP address, instead of having to configure it manually, it is very likely that it is thanks to a DHCP server running in your router, as DHCP is the most widely used method for this purpose.

The typical pieces of configuration that a host gets from DHCP are the host's IP address, the network mask, and the gateway. These three settings are normally enough to figure out how to reach other hosts in the same private network and to the Internet.

SLAAC normally replaces DHCP for IPv6, but it works similarly.

Basic explanation about routing

Routing is how your host decides where to send each packet depending on the destination IP address. With the ip route command you can see some of the routes that your system is using. They look something like this (simplified):

192.168.1.0/24 dev eth0 src 192.168.1.10
172.16.0.0/16 dev eth1 src 172.16.1.2
10.0.0.0/8 via 192.168.1.25 dev eth0 src 192.168.1.10
default via 192.168.1.1 dev eth0 src 192.168.1.10

Note: the definition of subnets in the format 192.168.1.0/24 is following the CIDR notation. See here if you don't know what does it mean.

First we see a direct route instructing to send packets directed to IP addresses within the 192.168.1.0/24 subnet through eth0. Then, a direct route instructing to send packets directed to IP addresses within the 172.16.0.0/16 subnet through eth1. Direct routes are used for packets directed to the same subnet as the host, since they are directly reachable. The kernel uses the routes to decide what the right device to send the packet is. It would be a mistake to send a packet directed to 192.168.1.20 by the eth1 interface, which is connected to a different physical network.

The third route contains via 192.168.1.25. This is a next hop, and is used to send packets to destinations not directly reachable by our system. Instead they are sent via an intermediate device with the IP address 192.168.1.25. This must be a router with capability to forward the packet to other networks where the destination is reachable.

The last one is known as a default route. The kernel uses it to send packets that didn't match any other route. They are typically used to configure the gateway, the next hop address to which to route all the packets that we don't explicitly know the route to. This is how our packets reach the Internet.

How the attack works

Most of the VPN clients are routing-based VPNs. This type of clients establish a tunnel to the VPN network by creating a virtual device. This is typically named tun0 or something similar. The VPN program encrypts all the traffic routed through that virtual device and sends it to the other end of the tunnel. The idea is that, although the traffic still goes through the potentially compromised network, it now does so as encrypted data.

To select what traffic to send through the tunnel interface, some routes are added to your system. At a minimum, a route similar to 10.0.0.0/8 dev tun0 is created. This routes the traffic directed to other systems inside the same VPN. For those who want to route all the traffic through the VPN, a default route similar to default via 10.11.12.13 dev tun0 is added, as well.

When you connect to a network using DHCP or SLAAC, the received IP configuration might contain some routes to install in your system. This has legitimate uses that we won't dig into in this article, but it is also what attackers use to bypass the VPN's configurations.

What happens when 2 routes overlaps in a way that a destination IP address matches with both of them? For example, the address 10.0.0.1 is within both subnets 10.0.0.0/8 and 10.0.0.0/24. Then, the route with the greater prefix wins. In this case, 10.0.0.0/24. This is because it is a more specific route, as it defines a smaller range of addresses, so they are a subset of the other which is more general.

Malicious agents with access to the network can take advantage of this. They can configure their DHCP server to send 2 routes with greater prefix than those configured by your VPN. This makes your system use the higher prefix and not send the traffic through the virtual tunnel device, so it goes unencrypted.

10.0.0.0/8 dev tun0   <-- route from VPN client
10.0.0.0/9 dev eth0   <-- route from DHCP
10.128.0.0/9 dev eth0 <-- route from DHCP

A default route can also be shadowed. Default is equivalent to 0.0.0.0/0, so the routes for 0.0.0.0/1 and 128.0.0.0/1 would overrule it, as they have a greater prefix. This means that the attacker can redirect all the traffic.

Policy routing to the rescue

We can use policy routing to mitigate the TunnelVision attack and other similar attacks like TunnelCrack. Policy routing is a technique for making routing decisions based on custom policies. In Linux based distros like Fedora we can see the policies with the command ip rule.

To prevent the attack, we can use policy routing to move the VPN routes to a dedicated routing table with higher priority than the table that contains the routes configured by DHCP.

Do this by creating a policy rule that looks up a custom routing table, for example table 75, for all the outgoing packets. Use a lower priority value than the main table, which is 32766, to ensure that our routes match first. Note that lower values mean higher priority.

ip rule add to all table 75 pref 32000

Then recreate the same routes as the VPN in the new table.

ip route add 10.0.0.0/8 dev tun0 table 75
...(etc)...

Check that the rule is in place with the ip rule command. Inspect that the routes have really been added to the table with ip route list table 75.

That's it. If any route from our custom table is applicable, it is used. Otherwise, the main table is checked as usual. Since routes from DHCP are added to the main table by default, they are unable to override the VPN's routes.

Configure NetworkManager

At this point, most readers might have already noticed that manually configuring this every time is going to be very tedious and error prone. Also, non expert users might have lot of difficulties to determine which are the VPN routes among all the others. Moreover, routes for a device that doesn't exist cannot be added, so we need to wait until the VPN device (i.e. tun0) is created. Once created, it is normally brought up immediately. This presents the risk of leaking data before the policy routing is configured.

If you are managing the VPN connection with NetworkManager, you can instruct it to configure the policy routing. The following command will perform the configuration. You only need to run it once and it will set this as a permanent configuration (even after a reboot).

nmcli connection modify MY_VPN_CONNECTION_NAME \
    ipv4.route-table 75 \
    ipv4.routing-rules "priority 32000 from all table 75" \
    ipv6.route-table 75 \
    ipv6.routing-rules "priority 32000 from all table 75"

Tip: find what the connection name is with the nmcli connection command.

Now deactivate and reactivate the connection. With these settings, NetworkManager will add the rules and put the routes in the specified table.

These are pretty advanced configurations, thus they are normally not available in your desktop's GUI settings panel.

Note: Due to a bug in NetworkManager, these settings were partially ignored for VPN connections. This is fixed in development version 1.51.6. The newest versions in Fedora 40 and 41 also contain the fix. Update Fedora and ensure that you have at least NetworkManager version 1.46.6-1 or 1.50.2-1.

Possible side effects

People use VPN to securely access resources inside the VPN itself. Optionally, they use it to route all the traffic through the VPN, mainly for privacy reasons. This behavior can be enabled with the "use only for resources in this connection" option (called never-default in nmcli).

When the VPN is used to route all the traffic, the explained policy routing configuration routes all the traffic through the VPN. Even the traffic directed to the local network (i.e. to 192.168.1.20) that, as a consequence, will stop working. Captive portals like those used to login to hotels' WiFi network won't work, either. This is because a default route like default via VPN_ADDRESS is added to the new table with higher priority. If this happens, you might need to disable this configuration. If you are experienced enough, you may add some custom routes to the table to fix it.

Any other connection that also needs to add routes might stop working, and you will need to tweak its route-table and routing-rules configurations to create a rule with higher priority than the other.

Even with the potential drawbacks, this is a very robust configuration that should protect you from any data leak based on these kinds of routing attacks.

29 Jan 2025 3:43pm GMT

A project I work on is preparing to pilot our initial version. As part of that preparation, we needed to decide on a versioning scheme. Someone proposed using calendar versioning and we all agreed. "Okay," I asked, "what does that actually mean?" Unlike Semantic Versioning (SemVer)'s defined standard, Calendar Versioning (CalVer) is an umbrella of many possible date-related schemes.

What is Calendar Versioning?

Calendar Versioning is release numbering based on a calendar date of some kind. Most CalVer schemes involve the year in either two- or four-digit form. Sometimes, the next part is more date. For example, Ubuntu releases are numbered based on the two-digit year and two-digit month. Other times, the next part is a incremented identifier. The tzdata time zone database uses the year plus a lowercase letter.

Choosing a CalVer scheme

The first question is, of course, if you should use CalVer at all. CalVer works well when time is more important than communicating compatibility. This might be because compatibility isn't a relevant concept, like with data or standards, or because compatibility is hard to define, like a Linux distribution.

The next question to ask is "how predictable are releases?" If you expect to have a few well-spaced releases a year, using the month number is a good choice. If you expect to have more than one per month regularly, then adding the month and day is a good approach. If releases could happen at any moment, an incremented system is a better approach. Time zone boundaries and daylight saving time observances can change whenever one of hundreds of nations decide to make a change, so it makes sense for the tzdata project to not go with a higher resolution date than the year.

No matter what CalVer variant you choose, you need to clearly indicate how you identify your releases. Simply saying "CalVer" does not set clear expectations for your users.

This post's featured photo by Towfiqu barbhuiya on Unsplash.

The post CalVer is many schemes appeared first on Duck Alignment Academy.

29 Jan 2025 12:00pm GMT