The Speakup modules are part of the official Linux kernel source tree
and are built along with the kernel. That means they're not external (I
think). Right?
I do not think this can represent a security risk because all you need
to do to get speech is to load a kernel module that's already in the
kernel source code. I cannot speak to the security of the modules
themselves but presumably, that's already been satisfied or they
wouldn't be part of the kernel source code.
The kernel has to recognize your video card and load the appropriate
module, right? Surely, modules for all possible video cards aren't
compiled into the kernel. I think there is even some mechanism for it
to know if there's a monitor connected to the video card. What we need,
if possible, is an analogous process to recognize hardware speech synths.
On 3/4/26 11:19 AM, Feli Flitzberg wrote:
For my two cents: it appears to me that most of the pushback relates
to the kernel mod. If that kernel mod is external, other admins think
it's an inherent security risk. If it just needs to be loaded, they're
likely assuming there's a security risk from loading a new mod and
potentially extra software to support a "fringe"/"niche" accessibility
situation.
However, if it's a thought of security, they should say it out loud,
not as a rude half-comment or as hand-wringing over which project
implements it. It's a single udev rule, systemd has precedent for
including udev rules, and it only triggers *when the synth is plugged
in*. Why not just make a pull request that includes the rule? Then if
it's really not accepted, make pull requests to distros instead.
There's my cents, good luck with whatever you do!
Feli Flitzberg
-------- Original Message --------
On Wednesday, 03/04/26 at 09:59 Barry Scott <[email protected]>
wrote:
On 4 Mar 2026, at 16:22, John G. Heim <[email protected]> wrote:
It's no different than a monitor.
I am a little disappointed by the amount of pushback I'm getting
on this. What if you had to log in and load a kernel module to
get your monitor to work? You're a server admin, you go into the
server room to look at a down server. You plug in a monitor and
it's just blank. You have to log in and type in a commend -- with
the monitor blank -- to get started. Of course, if the machine
isn't even at the login prompt, and it's probably not, just
trying to blindly type in your login credentials isn't going to
do anything.
This is real life for a blind systems admin or systems engineer.
People's jobs depend on this. This is how I put food on the table
for my entire career.
Instead of thinking up reasons to *not* do it, how about if we
try to figure out ways to get it done?
I agree this is a real life issue.
I'm not sure if systemd or the distros are best placed to solve
this issue.
You might find that asking the distros to add the udev rule would
work to get this going.
Barry
On 3/4/26 1:59 AM, Windl, Ulrich wrote:
…unless some other admin considers that to be a security risk…
Kind regards,
Ulrich Windl
*From:*systemd-devel<[email protected]>*On
Behalf Of*John G. Heim
*Sent:*Wednesday, February 25, 2026 11:26 PM
*To:*Adrian Vovk<[email protected]>
*Cc:*[email protected]
*Subject:*[EXT] Re: [systemd-devel] Udev rules for hardware
speech synths
*/[Windl, Ulrich] (…)/*
If we can get the kernel to recognize hardware speech synths, a
blind systems engineer will be able to walk up to any Linux
server, plug in his hardware synth, and listen to it boot.
*/[Windl, Ulrich] (…)/*
