All posts by Michal Luščon

DNF in the time of NSA

Thanks to Michal Sherer, a big computer security enthusiast, the DNF users are now able to enhance the privacy and the security of their systems using Tor network for metadata and packages downloading. For those of you who are not familiar with the basic concepts of Tor networking there is a short introduction available on the project pages. Hiding your identity during the communication with mirrors reduces the ability of potential sniffing attacker to determine the exact applications and their versions used on your system and most likely secures your downloading from the attacks like quantum insert.

Since this feature has been introduced in DNF-1.1.6-1, it should be already available in your supported up to date Fedora installations and it can be enabled in the following four easy steps:

1, Installation

First of all, you have to install tor package from your distribution repository. You can do so via your favorite package manager by executing ‘dnf install tor', that will install tor and torsocks packages into your system.

2, Configuration of Tor

By default, the Tor SOCKS proxy is configured to run in a client mode listening on your localhost port 9050. This default configuration might be altered by editing the torsocks.conf file located inside /etc/tor/ directory.

3, Activation of Tor service

Start the Tor proxy by systemct start tor and enable it permanently by systemctl enable tor.  Check whether Tor service is up and properly running by systemct status tor .

4, Configuration of DNF

On the DNF side of configuration, the only required step is to simply add proxy=socks5h:// line into your /etc/dnf/dnf.conf. From this point, any upcoming DNF communication with remote servers will be routed through the Tor network.

P.S.: I guess that even more of Tor awesomeness is coming soon in DNF plugins extras.


Mark command usecase

Dear DNF users,

it is an honor for me to introduce to you our newly implemented  mark command. If you are now wondering what was the motivation behind implementing this feature and also expecting some tidbits from DNF development, you are in the right spot. So prepare your favorite hot beverage and stay tuned. The story now begins:

In the early days of DNF development, the original members of  the team decided that the cool feature called clean_requirements_on_remove should have been enabled by default . This is exactly that feature of DNF which prevents your system from overblooting by installed, but no longer needed dependencies of packages.

Unfortunately, the world of rpm distribution is not always as bright and shiny as it might seen for the first look. There are situations where a manual user intervention is necessary, so lets take a look at a few of them:

PROBLEM: I used package manager incompatible with DNF for installation of packages A and B. Consequently DNF wants to autoremove these packages.

SOLUTION: Packages that user wants to preserve in his system can be marked as installed by user via following command dnf mark install A B.

PROBLEM: I installed package A alongside with his dependencies B and C. Now I want to remove package A but keep the package C.

SOLUTION: Mark package C as user installed by dnf mark install C.

PROBLEM: I installed package A and consequently installed package B which depends on package A. Now I decided to remove package A but it is not possible without removal of package B.

SOLUTION:  Mark package A for removal by dnf mark remove A and package A will be autoremoved once there are no packages dependent on package A.

Thank you for your attention.