In this article you will learn how TLS (Transport Layer Security) and SSH (Secure SHell) use public/private key-pairs to authenticate web servers you visit and linux machines you log in to. You will also learn how the TLS framework installed by default in mainstream web browsers fails to prevent MITM (Man In The Middle) attacks in critical ways. Then we will walk through setting up a private .FEDORA TLD (Top Level Domain), setting up your own private CA with the smallstep package, and using the acme-tiny package to issue certificates for a website under that private TLD.

I will not cover setting up a simple “Hello World” website using your favorite web server packaged with Fedora. This needs to be up and running on HTTP to follow along. For this article, the website will be named hello.fedora.

Sadly, we will also explain how this does not completely solve the MITM problem – but this is already a big article. Click here to skip the background and motivation and go directly to the HowTo.

How Public Keys Prevent Man-In-The-Middle Attacks

While NSA director Admiral Bobby revealed that intel agencies were aware of two key, or public-key cryptography since the 1960s, the first unclassified paper was published by Whitfield Diffie and Martin E. Hellman in 1976. In college, I remember playing with cryptosystems based on the knapsack problem. These had various vulnerabilities. What revolutionized the field was publication of the RSA algorithm in 1977. I vividly remember where I sat in the college library when I read the paper. There was some controversy over “you can’t patent algorithms”. However RSA patented their implementation (which is already protected by copyright – but that is another discussion). Yes, you can whip up a 1 line Perl implementation in a few minutes (we all did) – but a secure implementation that does not leak the private key through various side channels is NOT trivial.

The original concept of public keys was to look up a recipient’s pubkey in a directory, and use it to encrypt a message that only the possessor of the corresponding private key can decrypt. This can also be used to authenticate a correspondent via a protocol that proves they hold the corresponding private key. The basic idea is to encrypt a random token with a pubkey, the recipient decrypts the token and sends it back encrypted by your pubkey. The details are not trivial. The primary concern is MITM attacks. SSH and TLS support several widely accepted algorithms for authentication and key exchange.

The Directory of Pubkeys is Critical

If you think about it, that “directory” is all important. Suppose you have a “secure” phone app (without naming names) that uses a public directory to map telephone number to pubkey. Whoever runs that directory can return their own pubkey (likely a different one for each telephone number), decrypt the data, and send it on, re-encrypted to the real pubkey of the intended recipient (and the same for the other direction). I.e. – the classic MITM attack. This is why such secure applications usually provide a way to verify you have the real pubkey via an in-person meeting or alternate medium.

So how do you know the real pubkey for a secure (https) website? Websites provide a “certificate” saying “this pubkey is for these domain names” (and other information we are not concerned with here). Well, anyone can create such a certificate – in fact we will do so in this article – so how do you know it is truthful? The certificate is “signed” by a Certificate Authority (CA). Pubkeys can be used to sign data. For RSA, the basic concept is to compute a secure “hash” (e.g. SHA256) of the certificate data, and “decrypt” it using the private key of the CA. The signature can be verified by using the pubkey of the CA to “encrypt” the result, – which should match the hash of the signed data. RSA is nice in that decryption and encryption are symmetrical – verifying a signature is the same operation as encrypting the signature to the owner of the privkey for the pubkey . So now, instead of every web user maintaining a private database of pubkeys for domain names, the browser has a list of trusted CAs which sign website certificates after verifying them in some way. In case a private key is compromised, CAs publish a Revocation List (which regular people rarely use) and TLS certificates always have an expiration date.

Note that CAs can certify data other than domain names, like the name of a company or individual. Commercial CAs generally charge a premium for this, but there are also non-profit CAs like cacert.org that certify personal details via in-person meetings.

How Mainstream Browsers Know Which CAs to Trust

Regular Joes (“normies”) do not keep track of all this, so where does that “list of trusted CAs” come from? Well, there is a CA and Browser forum with representatives from popular browser software makers and commercial CAs. They maintain a list of trusted CAs, and changes are voted on in public meetings with minutes published on their web page. Fedora installs this list in /usr/share/pki. Browsers may have their own copy. Users may add additional trusted CAs to /usr/share/pki or /etc/pki/ca-trust and browsers may have their own way of adding additional trusted CAs.

This all sounds well and good, BUT. The critical flaw could be called serial reliability. The trusted CAs are trusted for any domain. So any trusted CA (including any you add) can forge a certificate for any website. DNS vulnerabilities (cache poisoning and such) are beyond the scope of this article. But we will set up a private CA which you could use to forge any website cert and fool anyone you convince to trust your CA (and can hack their DNS and/or IP routing). The cabforum is very careful about their list. As part of hostilities, forum CAs stopped certifying .RU domains (ISO TLD for Russia). Russia promptly put up their own national CAs, which anyone can add to their browser trust store. Normies were warned NOT to do this, as the Russian CAs could then forge certs for any domain. But a moment’s thought reveals that ANY cabforum CA could go “rogue” and do the same thing. It only takes one.

There are solutions to this blanket trust problem, but that will require another article.

Create a private TLD with bind

For illustration, we will create the .FEDORA TLD. Everyone following along will create a different instance of that TLD, and hostnames under .FEDORA will resolve to different IPs (or NXDOMAIN) depending on whose DNS server you point that TLD at. This was the motivation for creating ICANN – a worldwide centralized DNS root (list of official TLDs). This provides a consistent namespace at the expense of absolute power (to cancel domains and TLDs) invested in ICANN. Before ICANN, admins all maintained their own DNS root, and periodically updated (manually or automatically) nameservers for well known TLDs like .COM etc. ISO defined an official list of TLDs, including country code TLDs (like .US). That worked well. The problem came with more obscure TLDs like .FREE. Companies trying to be “cool” were upset that not all customers got the same IPs for .FREE hostnames. Also admins liked having “someone else” maintain the DNS root. Hence, ICANN. There is also Opennic which likewise has “someone else” (volunteers) maintain a root zone, with fallback to ICANN, and has its own “forum” (existing TLDs vote) to approve new TLDs.

Here is a bind zonefile for .FEDORA:

$TTL 2H
; hello.fedora
@               IN      SOA     ns1     hostadmin.hello.fedora. (
                        2025122600 ; serial
                        1H ; refresh
                        15M ; retry
                        14D ; expire
                        6H ; default_ttl
                        )
@               IN      NS      ns1.fedora.
@               IN      TXT     "v=spf1 -all"
hello		IN      A	192.168.100.31
ns1		IN	A	192.168.100.31
ca		IN	A	192.168.100.31

But that was a bait and switch. Setting up DNS for a private TLD is its own article. If you know how to add such a zone to your self hosted DNS – then do so. For the rest, we’ll use an even older hostname/IP map that predates DNS: as root, edit the file /etc/hosts on the system you will run step-ca on and append these lines:

# smallstep article
192.168.100.31	hello.fedora
192.168.100.31	ca.fedora

Replace 192.168.100.31 with the IP of the system you are trying all this out on. Step-ca must be able to lookup the hello.fedora hostname it is certifying to do the ACME protocol. We will use the /.well-known/acme-challenge method, which does not require real DNS. The system you run acme-tiny on also needs to lookup ca.fedora.

Run a private CA with step-ca

If the smallstep package is still under review when you read this, you’ll need to enable the copr repo (otherwise skip this step):

sudo dnf copr enable @fedora-review/fedora-review-2418762-smallstep

Create root CA

First, we need to create our root CA. In production, this should be on a separate offline machine. For small operations, the secondary CAs can be automated, and you sign the certificates for these secondaries manually with the root CA. I would keep the root CA password on paper – can’t be hacked (but watch out for cameras). Do NOT skip the password for the root CA. Some number of systems will trust that CA for any domain. If the private key leaks, you end up with a situation like Dell faced in 2015.

Let’s put the manual root CA in /etc/pki/CA and generate the root cert. Openssl will ask you for a key passwd, and what x509 calls “subject identifiers”. I left the state and email blank, and set city to Fedora City, organization to Fedora Project, organizational unit to ca, and common name to ca.example.org. The “-days 3650” sets the expiration to 10 years from now. The second command shows the “Issuer” information end-users will see when they ask for the issuer in an app like Firefox. The common name should normally be the hostname of the root CA, but it doesn’t really matter when the root CA is offline – and example.org is coincidentally offline by convention.

$ sudo mkdir /etc/pki/CA
$ cd /etc/pki/CA
$ sudo install --mode=644 /dev/stdin root_ca.fedora.ext <<EOF
subjectAltName=DNS:ca.example.org
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:1
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
EOF
$ sudo mkdir -m 0700 private
$ sudo openssl req -new -keyout private/root_ca.key -out root_ca.csr
...
$ sudo openssl x509 -req -in root_ca.csr -key private/root_ca.key -out root_ca.crt -days 3652 -sha256 -extfile root_ca.fedora.ext
Enter pass phrase for private/root_ca.key:
Certificate request self-signature ok
subject=C=US, L=Fedora City, O=Fedora Project, OU=ca, CN=ca.example.org

Create intermediate certificate and install smallstep

Then install the smallstep package with step-ca binary and supporting files:

$ sudo dnf install smallstep

The package installs a skeleton config for a step-ca service in /var/lib/step-ca. Let’s flesh out the config as step-ca and generate an intermediate cert request (“csr”).

$ cd /var/lib/step-ca
$ sudo -u step-ca bash -l
$ ls
certs  config  db  secrets  templates
$ cp /etc/pki/CA/root_ca.crt certs
$ openssl req -new -keyout secrets/intermediate_ca.key -out intermediate_ca.csr
...
$ nano config/ca.json
$ exit

Again, openssl will ask for subject identifiers. I used the same as for the root CA, but with the common name ca.fedora. Use your favorite text editor; “nano” is beginner friendly. Change MYCABAL to FEDORA and ca.mycabal.org to ca.fedora. If you provided a password for intermediate_ca.key, put it in the “password” field of ca.json. Do not set the password in ca.json to the empty string. This will make step-ca try to prompt for it at startup – which is not allowed under systemd, and fails with an error opening /dev/tty. For the intermediate cert, the common name is important. Smallstep will auto generate a host cert for “ca.fedora” (it is, after all, a certificate authority), and it must match the hostname ACME clients use to sign certs. Now we need to sign the intermediate cert with the root CA. 1825 days is 5 years. Intermediate certs should be shorter lived than the root CA. Not too short, if you are manually resigning the certs.

$ cd /etc/pki/CA
$ sudo install --mode=644 /dev/stdin ca.fedora.ext << EOF
subjectAltName=DNS:ca.fedora
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
EOF
$ sudo openssl x509 -req -in /var/lib/step-ca/intermediate_ca.csr -CA root_ca.crt -CAkey private/root_ca.key -CAcreateserial -out intermediate_ca.crt -days 1825 -sha256 -extfile ca.fedora.ext
$ sudo -u step-ca cp intermediate_ca.crt /var/lib/step-ca/certs
$ sudo systemctl start step-ca
$ sudo systemctl status step-ca
...
Mar 31 15:18:56 test.gathman.org step-ca[2814912]: 2026/03/31 15:18:56 Serving HTTPS on :9000 ...

Use httpd to serve hello.fedora web page

Running a web server was a prerequisite. I’ll use apache as an example, and hopefully users of nginx and others can translate. First, /etc/httpd/conf.d/hello.conf

<VirtualHost *:80>
ServerName      hello.fedora
DocumentRoot    "/var/www/html/hello"
#RedirectMatch ^((?!\/\.well-known\/).*)$ https://hello.fedora$1
<Location "/.well-known/acme-challenge/">
        Options -Indexes
        Order allow,deny
        Allow from all
</Location>
   <Location "/">
        Options FollowSymLinks Indexes
        Require all granted
    </Location>
</VirtualHost>

The redirect is commented out until we have a signed cert. Assuming httpd is already running, use sudo apachectl graceful to load the changes. Then a simple document in /var/www/html/hello/index.html

<html>
	<head>
		<title> Hello Fedora </title>
	</head>
	<body>
		<h1> Hello Fedora! </h1>
	</body>
</html>

Use acme-tiny to sign a TLS cert with step-ca

Add private root CA

Acme-tiny needs to trust the root CA to use the ACME service. The step-ca service provides a handy API to fetch the root ca:

$ cd /etc/pki/ca-trust/source/anchors
$ sudo curl https://ca.fedora:9000/roots.pem -o fedora_ca.crt
curl: (60) SSL certificate problem: unable to get local issuer certificate

Ooops! Catch 22. You need the root CA to use the handy API that gets the root CA. So we’ll have to tell curl to accept the strange root cert. (Or use rsync, cp on the same machine, copy/paste between terminal windows, or other more secure method.)

$ sudo curl -k https://ca.fedora:9000/roots.pem -o fedora_ca.crt
$ sudo update-ca-trust extract

Now, we are ready to run acme-tiny. Once again, openssl req will prompt for subject identifiers. The only one browsers care about is Common Name, which should be “hello.fedora”. However, users may care about the other fields when they use browser features to inspect certs.

$ sudo dnf install acme-tiny
$ sudo apachectl graceful
$ cd /var/lib/acme
$ sudo -u acme bash -l
$ ls
certs  csr  private
$ /usr/libexec/acme-tiny/sign  # NOTE: generates account.key if needed
$ ls private
account.key
$ openssl req -new -passout pass:'' -keyout private/hello.key -out csr/hello.csr
$ /usr/sbin/acme_tiny --account-key private/account.key --csr csr/hello.csr --acme-dir /var/www/challenges/ --ca https://ca.fedora:9000/acme/FEDORA >certs/hello.crt
$ exit
$ sudo nano /etc/httpd/conf.d/hello.conf

Now uncomment the Redirect Match and append the below SSL virtual host definition to hello.conf. Use apachectl graceful to load the changes.

<VirtualHost *:443>
ServerName      hello.fedora:443
SSLEngine on
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite HIGH:3DES:!aNULL:!MD5:!SEED:!IDEA
DocumentRoot    "/var/www/html/hello"
SSLCertificateFile /var/lib/acme/certs/hello.crt
SSLCACertificateFile /var/lib/acme/certs/hello.crt
SSLCertificateKeyFile /var/lib/acme/private/hello.key
CustomLog logs/ssl_request_log \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
   <Location "/">
        Options FollowSymLinks Indexes
    </Location>
</VirtualHost>

The current acme-tiny package auto-renews certs only for the letsencrypt.org CA. That should be extended soon. Meanwhile, feel free to add something hacky. (I’ll try to have it lookup tlds in /etc/sysconfig or something to get custom CA url.)

Use a browser to display the web page

On the machine with your web browser, you need 2 things: the new root CA and some way to lookup names in the .FEDORA TLD, either by pointing DNS to the server you set up with the private zone, or by appending the lines to /etc/hosts for ca.fedora and hello.fedora.

Now the curl should work without -k. And your browser should work to display https://hello.fedora, although you might have to restart it. If it doesn’t read Fedora ca-trust store on startup, you might need to find an option to import CA on the browser menu.

$ curl https://hello.fedora
<html>
	<head>
		<title> Hello Fedora </title>
	</head>
	<body>
		<h1> Hello Fedora! </h1>
	</body>
</html>

Now, that your root CA is up and running, don’t lose sight of what can be done by having it go rogue. Get lots of people to install it so they can access your cool new TLDS. Then start forging certs for arbitrary web sites, and conquer the world!! Bwa! ha! ha! (A future article can address PKCS#11 and restricting how you trust CAs in browsers and other software.)

The Fedora CoreOS and QA teams are gearing up for Fedora 44, and we need your help! We are organizing a Test Week running from March 23 to March 27, 2026.

This event is a nice opportunity for the community to test Fedora CoreOS (FCOS) based on Fedora 44 content before it officially reaches the testing and stable streams. By participating, you help us ensure a smooth and reliable experience for all users.

How does a Test Week work?

A Test Week is an event where anyone can help verify that the upcoming release works as expected. If you’ve been looking for a way to get started with Fedora contribution, this is the perfect entry point.

To participate, you simply need to:

• Download the FCOS test images.
• Follow the step-by-step test cases provided.
• Report whether the tests passed or failed on your hardware or VM.

The Wiki Page is your primary source of information for this event. Once you have completed your tests, please log your results here! Your contribution, big or small, makes a huge difference. Let’s work together to make this release a great one. Happy testing!

Join the Live Sync Session

Want to chat with the team? We are hosting a virtual in-person session on Tuesday, March 24, from 3:00 PM – 4:30 PM UTC. Drop in to ask questions and get help with testing!

Video Meeting: meet.google.com/ufp-bwsb-zwh

We are happy to announce the general availability of Fedora Asahi Remix 43. This release brings Fedora Linux 43 to Apple Silicon Macs.

Fedora Asahi Remix is developed in close collaboration with the Fedora Asahi SIG and the Asahi Linux project. This release incorporates all the exciting improvements brought by Fedora Linux 43. Notably, package management is significantly upgraded with RPM 6.0 and the new DNF5 backend for PackageKit for Plasma Discover and GNOME Software ahead of Fedora Linux 44. It also continues to provide extensive device support. This includes newly added support for the Mac Pro, microphones in M2 Pro/Max MacBooks, and 120Hz refresh rate for the built-in displays for MacBook Pro 14/16 models.

Fedora Asahi Remix offers KDE Plasma 6.6 as our flagship desktop experience. It contains all of the new and exciting features brought by Fedora KDE Plasma Desktop 43. It also features a custom Calamares-based initial setup wizard. A GNOME variant is also available, featuring GNOME 49, with both desktop variants matching what Fedora Linux offers. Fedora Asahi Remix also provides a Fedora Server variant for server workloads and other types of headless deployments. Finally, we offer a Minimal image for users that wish to build their own experience from the ground up.

You can install Fedora Asahi Remix today by following our installation guide. Existing systems running Fedora Asahi Remix 41 or 42 should be updated following the usual Fedora upgrade process. Upgrades via GNOME’s Software application are unfortunately not supported. Either KDE’s Plasma Discover or DNF’s System Upgrade command must be used.

Please report any Remix-specific issues in our tracker, or reach out in our Discourse forum or our Matrix room for user support.

Introduction

Writing a real-time audio plugin on Linux often conjures up images of a complex environment: C++, toolchains, CMake, CLAP / VST3 / LV2 SDK, ABI…

However, there is a much simpler approach : JSFX

This article offers a practical introduction to JSFX and YSFX on Fedora Linux: we’ll write some small examples, add a graphical VU meter, and then see how to use it as an CLAP / VST3 plugin in a native Linux workflow.

JSFX (JesuSonic Effects – created by REAPER [7]) allows you to write audio plugins in just a few lines, without compilation, with instant reloading and live editing.

Long associated with REAPER, they are now natively usable on Linux, thanks to YSFX [3], available on Fedora Linux in CLAP and VST3 formats via the Audinux repository ([4], [5]).

This means it’s possible to write a functional audio effect in ten lines, then immediately load it into Carla [8], Ardour [9], or any other compatible host, all within a PipeWire / JACK [11] environment.

A citation from [1] (check the [1] link for images):

In 2004, before we started developing REAPER, we created software designed for creating and modifying FX live, primarily for use with guitar processing.

The plan was that it could run on a minimal Linux distribution on dedicated hardware, for stage use. We built a couple of prototypes.

These hand-built prototypes used mini-ITX mainboards with either Via or Intel P-M CPUs, cheap consumer USB audio devices, and Atmel AVR microcontrollers via RS-232 for the footboard controls.

The cost for the parts used was around $600 each.

In the end, however, we concluded that we preferred to be in the software business, not the hardware business, and our research into adding multi-track capabilities in JSFX led us to develop REAPER. Since then, REAPER has integrated much of JSFX’s functionality, and improved on it.

So, as you can see, this technology is not that new. But the Linux support via YSFX [3] is rather new (Nov 2021, started by Jean-Pierre Cimalando).

A new programming language, but for what ? What would one would use JSFX for ?

This language is dedicated to audio and with it, you can write audio effects like an amplifier, a chorus, a delay, a compressor, or you can write synthesizers.

JSFX is good for rapid prototyping and, once everything is in place, you can then rewrite your project into a more efficient language like C, C++, or Rust.

JSFX for developers

Developing an audio plugin on Linux often involves a substantial technical environment. This complexity can be a hindrance when trying out an idea quickly.

JSFX (JesuSonic Effects) offers a different approach: writing audio effects in just a few lines of interpreted code, without compilation and with instant reloading.

Thanks to YSFX, available on Fedora Linux in CLAP and VST3 formats, these scripts can be used as true plugins within the Linux audio ecosystem.

This article will explore how to write a minimal amplifier in JSFX, add a graphical VU meter, and then load it into Carla as a CLAP / VST3 plugin.

The goal is simple: to demonstrate that it is possible to prototype real-time audio processing on Fedora Linux in just a few minutes.

No compilation environment is required: a text editor is all you need.

YSFX plugin

On Fedora Linux, YSFX comes in 3 flavours :

• a standalone executable ;
• a VST3 plugin ;
• a CLAP plugin.

YSFX is available in the Audinux [5] repository. So, first, install the Audinux repository:

$ dnf copr enable ycollet/audinux

Then, you can install the version you want:

$ dnf install ysfx
$ dnf install vst3-ysfx
$ dnf install clap-ysfx

Here is a screenshot of YSFX as a VST3 plugin loaded in Carla Rack [8]:

You can :

• Load a file ;
• Load a recent file ;
• Reload a file modified via the Edit menu ;
• Zoom / Unzoom via the 1.0 button ;
• Load presets ;
• Switch between the Graphics and Sliders view.

Here is a screenshot of the Edit window:

The  Variables  column displays all the variables defined by the loaded file.

Examples

We will use the JSFX documentation available at [4].

JSFX code is always divided into section.

• @init : The code in the @init section gets executed on effect load, on samplerate changes, and on start of playback.
• @slider : The code in the @slider section gets executed following an @init, or when a parameter (slider) changes
• @block : The code in the @block section is executed before processing each sample block. Typically a block is the length as defined by the audio hardware, or anywhere from 128-2048 samples.
• @sample : The code in the @sample section is executed for every PCM (Pulse Code Modulation) audio sample.
• @serialize : The code in the @serialize section is executed when the plug-in needs to load or save some extended state.
• @gfx [width] [height] : The @gfx section gets executed around 30 times a second when the plug-ins GUI is open.

A simple amplifier

In this example, we will use a slider value to amplify the audio input.

desc:Simple Amplifier
slider1:1<0,4,0.01>Gain

@init
gain = slider1;

@slider
gain = slider1;

@sample
spl0 *= gain;
spl1 *= gain;

slider1, @init, @slider, @sample, spl0, spl1 are JSFX keywords [1].

Description:

• slider1: create a user control (from 0 to 4 here);
• @init: section executed during loading;
• @slider: section executed when we move the slide;
• @sample: section executed for each audio sample;
• spl0 and spl1: left and right channels.
• In this example, we just multiply the input signal by a gain.

Here is a view of the result :

An amplifier with a gain in dB

This example will create a slider that will produce a gain in dB.

desc:Simple Amplifier (dB)
slider1:0<-60,24,0.1>Gain (dB)

@init
gain = 10^(slider1/20);

@slider
gain = 10^(slider1/20);

@sample
spl0 *= gain;
spl1 *= gain;

Only the way we compute the gain changes.

Here is a view of the result :

An amplifier with an anti-clipping protection

This example adds protection against clipping and uses a JSFX function for that.

desc:Simple Amplifier with Soft Clip
slider1:0<-60,24,0.1>Gain (dB)

@init
gain = 10^(slider1/20);

@slider
gain = 10^(slider1/20);
function softclip(x) (
  x / (1 + abs(x));
);

@sample
spl0 = softclip(spl0 * gain);
spl1 = softclip(spl1 * gain);

Here is a view of the result :

An amplifier with a VU meter

This example is the same as the one above, we just add a printed value of the gain.

desc:Simple Amplifier with VU Meter
slider1:0<-60,24,0.1>Gain (dB)

@init
rms = 0;
coeff = 0.999; // RMS smoothing
gain = 10^(slider1/20);

@slider
gain = 10^(slider1/20);

@sample
// Apply the gain
spl0 *= gain;
spl1 *= gain;
// Compute RMS (mean value of the 2 channels)
mono = 0.5*(spl0 + spl1);
rms = sqrt((coeff * rms * rms) + ((1 - coeff) * mono * mono));

@gfx 300 200 // UI part
gfx_r = 0.1; gfx_g = 0.1; gfx_b = 0.1;
gfx_rect(0, 0, gfx_w, gfx_h);

// Convert to dB
rms_db = 20*log(rms)/log(10);
rms_db < -60 ? rms_db = -60;

// Normalisation for the display
meter = (rms_db + 60) / 60;
meter > 1 ? meter = 1;

// Green color
gfx_r = 0;
gfx_g = 1;
gfx_b = 0;

// Horizontal bar
gfx_rect(10, gfx_h/2 - 10, meter*(gfx_w-20), 20);

// Text
gfx_r = gfx_g = gfx_b = 1;
gfx_x = 10;
gfx_y = gfx_h/2 + 20;
gfx_printf("Level: %.1f dB", rms_db);

The global structure of the code:

• Apply the gain
• Compute a smoothed RMS value
• Convert to dB
• Display a horizontal bar
• Display a numerical value

Here is a view of the result :

An amplifier using the UI lib from jsfx-ui-lib

In this example, we will use a JSFX UI library to produce a better representation of the amplifier’s elements.

First, clone the https://github.com/geraintluff/jsfx-ui-lib repository and copy the file ui-lib.jsfx-inc into the directory where your JSFX files are saved.

desc:Simple Amplifier with UI Lib VU
import ui-lib.jsfx-inc
slider1:0<-60,24,0.1>Gain (dB)

@init
freemem = ui_setup(0);
rms = 0;
coeff = 0.999;
gfx_rate = 30; // 30 FPS

@slider
gain = 10^(slider1/20);

@sample
spl0 *= gain;
spl1 *= gain;
mono = 0.5*(spl0 + spl1);
rms = sqrt(coeff*rms*rms + (1-coeff)*mono*mono);

// ---- RMS computation ----
level_db = 20*log(rms)/log(10);
level_db < -60 ? level_db = -60;

@gfx 300 200
ui_start("main");

// ---- Gain ----
control_start("main","default");
control_dial(slider1, 0, 1, 0);
cut = (level_db + 100) / 200 * (ui_right() - ui_left()) + ui_left();

// ---- VU ----
ui_split_bottom(50);
ui_color(0, 0, 0);
ui_text("RMS Level: ");
gfx_printf("%d", level_db);
ui_split_bottom(10);
uix_setgfxcolorrgba(0, 255, 0, 1);
gfx_rect(ui_left(), ui_top(), ui_right() - ui_left(), ui_bottom() - ui_top());
uix_setgfxcolorrgba(255, 0, 0, 1);
gfx_rect(ui_left(), ui_top(), cut, ui_bottom() - ui_top());
ui_pop();

The global structure of the example:

• Import and setup: The UI library is imported and then allocated memory (ui_setup) using @init;
• UI controls: control_dial creates a thematic potentiometer with a label, integrated into the library;
• Integrated VU meter: A small graph is drawn with ui_graph, normalizing the RMS value between 0 and 1;
• UI structure: ui_start(“main”) prepares the interface for each frame. ui_push_height / ui_pop organize the vertical space.

Here is a view of the result :

A simple synthesizer

Now, produce some sound and use MIDI for that.

The core of this example will be the ADSR envelope generator ([10]).

desc:Simple MIDI Synth (Mono Sine)
// Parameters
slider1:0.01<0.001,2,0.001>Attack (s)
slider2:0.2<0.001,2,0.001>Decay (s)
slider3:0.8<0,1,0.01>Sustain
slider4:0.5<0.001,3,0.001>Release (s)
slider5:0.5<0,1,0.01>Volume

@init
phase = 0;
note_on = 0;
env = 0;
state = 0; // 0=idle,1=attack,2=decay,3=sustain,4=release

@slider
// Compute the increment / decrement for each states
attack_inc = 1/(slider1*srate);
decay_dec = (1-slider3)/(slider2*srate);
release_dec = slider3/(slider4*srate);

@block
while (
  midirecv(offset, msg1, msg23) ? (
    status = msg1 & 240;
    note = msg23 & 127;
    vel = (msg23/256)|0;
    // Note On
    status == 144 && vel > 0 ? (
      freq = 440 * 2^((note-69)/12);
      phase_inc = 2*$pi*freq/srate;
      note_on = 1;
      state = 1;
    );
    // Note Off
    (status == 128) || (status == 144 && vel == 0) ? (
      state = 4;
    );
  );
);

@sample
// ADSR Envelope []
state == 1 ? ( // Attack
  env += attack_inc;
  env >= 1 ? (
    env = 1;
    state = 2;
  );
);

state == 2 ? ( // Decay
  env -= decay_dec;
  env <= slider3 ? (
    env = slider3;
    state = 3;
  );
);

state == 3 ? ( // Sustain
  env = slider3;
);

state == 4 ? ( // Release
  env -= release_dec;
  env <= 0 ? (
    env = 0;
    state = 0;
  );
);

// Sine oscillator
sample = sin(phase) * env * slider5;
phase += phase_inc;
phase > 2*$pi ? phase -= 2*$pi;

// Stereo output
spl0 = sample;
spl1 = sample;

Global structure of the example:

• Receives MIDI via @block;
• Converts MIDI note to frequency (A440 standard);
• Generates a sine wave;
• Applies an ADSR envelope;
• Outputs in stereo.

Here is a view of the result :

Comparison with CLAP / VST3

JSFX + YSFX

Advantages of JSFX:

• No compilation required;
• Instant reloading;
• Fast learning curve;
• Ideal for DSP prototyping;
• Portable between systems via YSFX.

Limitations:

• Less performant than native C++ for heavy processing;
• Less suitable for “industrial” distribution;
• Simpler API, therefore less low-level control.

CLAP / VST3 in C/C++

Advantages:

• Maximum performance;
• Fine-grained control over the architecture;
• Deep integration with the Linux audio ecosystem;
• Standardized distribution.

Limitations:

• Requires a complete toolchain;
• ABI management/compilation;
• Longer development cycle.

Conclusion

A functional audio effect can be written in just a few lines, adding a simple graphical interface, and then loaded this script as an CLAP / VST3 plugin on Fedora Linux. This requires no compilation, no complex SDK, no cumbersome toolchain.

JSFX scripts don’t replace native C++ development when it comes to producing optimized, widely distributable plugins. However, they offer an exceptional environment for experimentation, learning signal processing, and rapid prototyping.

Thanks to YSFX, JSFX scripts now integrate seamlessly into the Linux audio ecosystem, alongside Carla, Ardour, and a PipeWire-based audio system.

For developers and curious musicians alike, JSFX provides a simple and immediate entry point into creating real-time audio effects on Fedora Linux.

Available plugins

ysfx-chokehold

A free collection of JS (JesuSonic) plugins for Reaper.

Code available at: https://github.com/chkhld/jsfx

To install this set of YSFX plugins:

$ dnf install ysfx-chokehold

YSFX plugins will be available at /usr/share/ysfx-chokehold.

ysfx-geraintluff

Collection of JSFX effects.

Code available at: https://github.com/geraintluff/jsfx

To install this set of YSFX plugins:

$ dnf install ysfx-geraintluff

YSFX plugins will be available at /usr/share/ysfx-geraintluff.

ysfx-jesusonic

Some JSFX effects from Cockos.

Code available at: https://www.cockos.com/jsfx

To install this set of YSFX plugins:

$ dnf install ysfx-jesusonic

YSFX plugins will be available at /usr/share/ysfx-jesusonic.

ysfx-joepvanlier

A bundle of JSFX and scripts for reaper.

Code available at: https://github.com/JoepVanlier/JSFX

To install this set of YSFX plugins:

$ dnf install ysfx-joepvanlier

YSFX plugins will be available at /usr/share/ysfx-joepvanlier.

ysfx-lms

LMS Plugin Suite – Open source JSFX audio plugins

Code available at: https://github.com/LMSBAND/LMS

To install this set of YSFX plugins:

$ dnf install ysfx-lms

YSFX plugins will be available at /usr/share/ysfx-lms.

ysfx-reateam

Community-maintained collection of JS effects for REAPER

Code available at: https://github.com/ReaTeam/JSFX

To install this set of YSFX plugins:

$ dnf install ysfx-reateam

YSFX plugins will be available at /usr/share/ysfx-reateam.

ysfx-rejj

Reaper JSFX Plugins.

Code available at: https://github.com/Justin-Johnson/ReJJ

To install this set of YSFX plugins:

$ dnf install ysfx-rejj

And all the YSFX plugins will be available at /usr/share/ysfx-rejj.

ysfx-sonic-anomaly

Sonic Anomaly JSFX scripts for Reaper

Code available at: https://github.com/Sonic-Anomaly/Sonic-Anomaly-JSFX

To install this set of YSFX plugins:

$ dnf install ysfx-sonic-anomaly

YSFX plugins will be available at /usr/share/ysfx-sonic-anomaly.

ysfx-tilr

TiagoLR collection of JSFX effects

Code available at: https://github.com/tiagolr/tilr_jsfx

To install this set of YSFX plugins:

$ dnf install ysfx-tilr

YSFX plugins will be available at /usr/share/ysfx-tilr.

ysfx-tukan-studio

JSFX Plugins for Reaper

Code available at: https://github.com/TukanStudios/TUKAN_STUDIOS_PLUGINS

To install this set of YSFX plugins:

$ dnf install ysfx-tukan-studio

YSFX plugins will be available at /usr/share/ysfx-tukan-studio.

Webography

[1] – https://www.cockos.com/jsfx

[2] – https://github.com/geraintluff/jsfx

[3] – https://github.com/JoepVanlier/ysfx

[4] – https://www.reaper.fm/sdk/js/js.php

[5] – https://audinux.github.io

[6] – https://copr.fedorainfracloud.org/coprs/ycollet/audinux

[7] – https://www.reaper.fm/index.php

[8] – https://github.com/falkTX/Carla

[9] – https://ardour.org

[10] – https://en.wikipedia.org/wiki/Envelope_(music)

[11] – https://jackaudio.org

What are GNOME Shell extensions?

Imagine that Fedora Workstation is your desk, and GNOME Shell extensions are small accessories you add to make it feel more personal. It’s like placing a pencil case on the right side, a lamp that helps you focus, or a small cabinet to keep your things from getting scattered. It’s the same desk—GNOME stays clean and minimal—but a few additions can make your routine more comfortable.

Extensions work on the GNOME interface: the top panel, the way you open applications, how notifications appear, and small details that usually stay hidden. These simple changes can be enough to make your Fedora Workstation feel different. With just one extension, you can make Fedora feel more “you.”

But like any accessories, choose only what truly helps—don’t install everything. Too many extensions can clutter your desktop or make things feel unstable. The goal isn’t to chase excitement, but to find a few small add-ons that better fit the way you work in Fedora Workstation.

Note: The user will need to enable Flathub/Third Party Repos in order to get Extension Manager.

Why use Extension Manager?

Once you see extensions as small “accessories” for GNOME, a question comes up fast: how do you install them without the hassle? This is where Extension Manager helps.

Instead of opening many browser tabs, you can do everything in one place. You can browse extensions. You can search for what you need. You can also read a short description before installing. As a result, the whole process feels calmer and more familiar.

More importantly, Extension Manager makes it easier to experiment safely. For example, you can try one extension to make the top panel more useful. If it doesn’t feel right, you can simply turn it off. Or you can uninstall it in seconds. That way, you stay in control.

Also, you’re not “modding” your whole system. You’re only adding small features. And if you change your mind, you can always go back to GNOME’s clean default look.

In short, Extension Manager is like a small drawer on your desk. It keeps your extensions in one spot. So they’re easy to find, easy to try, and easy to tidy up again.

Install Extension Manager

Let’s move to the easiest part: installing Extension Manager with just a few clicks. Open the Software app on Fedora Workstation, then search for Extension Manager using the search bar. Select the app and click Install. That’s it.

Once the installation is complete, open it from the app menu—look for Extension Manager. Now you’re ready to customize. Start slowly: try one extension first, then see if it fits your daily routine.

Find and Install an Extension

After you open Extension Manager, it can feel like opening an “accessories shop” for your Fedora Workstation. There are many options, from small tweaks to extensions that can change how you work.

Start with the search bar. Think about what you most often need in your day-to-day routine. For example, you might want quicker access to apps, tray icons for indicators, or a more informative top panel. When you find an extension that looks interesting, open its page for a moment. Read the short description, look at the screenshots, and then ask yourself whether it will really help your work flow.

If you’re sure, just click Install. In a few seconds, it will be installed, and you’ll notice the change right away. However, if it doesn’t feel right, don’t hesitate to uninstall it. At this stage, you’re simply trying things out—like picking the accessories that best fit your desk.

Enable/disable and adjust settings

After you install a few extensions, you don’t have to stick with all of them. Sometimes an extension is useful, but you don’t need it all the time. That’s the nice thing about Extension Manager: you can enable or disable extensions at any time, without any drama.

Think of it like accessories on your desk. Some days you need a desk lamp to help you focus. On other days, you want your desk to stay clean and simple. Extensions work the same way. You can turn one on when you need it, and turn it off when you’re done.

If an extension has options, you’ll usually see a Settings or Preferences button. From there, you can tweak small details to match your style—icon placement, button behaviour, panel appearance, and more. This is what makes extensions feel personal. You’re not just installing something and forgetting it; you’re shaping it around your workflow.

And if one day your Fedora starts to feel too crowded, don’t panic. Just open the list of installed extensions and disable the ones you don’t need. Take it slow. The best customization isn’t about how many extensions you have, but how well they fit your daily activities.

Keep it safe: a few practical tips

At this point, you might start thinking, “Wow, there are so many things I can change.” And that’s true. However, if you want Fedora Workstation to stay light and comfortable, there are a few simple habits worth keeping in mind.

First, install extensions the same way you choose tools: only when you truly need them. If you stop using an extension after a few days, it’s better to disable it or remove it. A comfortable desktop isn’t the most crowded one—it’s the one with fewer distractions.

Second, try extensions one by one. If you install many at once, it’s hard to tell which one causes a problem. On the other hand, if you take it slowly, you can quickly feel what fits and what doesn’t.

Finally, remember that GNOME keeps evolving. Sometimes after a major update, an extension may not be ready yet. If something feels odd after an update, the safest move is simple: open Extension Manager and disable the extension you suspect. Once things are back to normal, you can wait for an update or choose an alternative.

In the end, Extension Manager isn’t a ticket to customize without limits. It’s more like a clean toolbox. If you use it with care and focus on what you really need, customization can stay enjoyable—without losing the clean, stable feel of Fedora Workstation.

Wrapping up: share your favorite extensions

Now you know how to customize your Fedora Workstation with Extension Manager. You’ve learned how to install the app, try a few extensions, and adjust their settings. And here’s the fun part: everyone ends up with a different mix of extensions, because we all have different needs and work styles.

If you have a favorite extension, share it. Which one do you rely on most, and what do you use it for? Maybe it helps you stay focused during presentations. Or maybe it makes the top panel more informative, brings back tray icons, or simply speeds up your work flow. Tell us why you like it, so others can picture the benefit.

Who knows—your list might inspire someone else. And you might also discover a new extension that fits your daily routine even better.