Skip to main content

react-scripts and npm audit

Written by michael

Running the npx script create-react-app installs the react-scripts module when it does its work, but the various scripts therein often have one or more vulnerabilities in them, according to npm audit. This is a bit distracting, because you would normally never want to see any warnings or errors from an audit, especially when you haven’t even written any code.

People regularly report these problems to the create-react-app developers, but it turns out to be unnecessary in most cases. The developers close most of the reports, with the following explanation.

The npm audit tool runs over all of the installed npm modules that you have, but it really only needs to be run against the code that would run in production, not all of the npm modules. It’s not really a denial-of-service vulnerability, for example, if a module only executes when you occasionally run it during development on your machine. The react-scripts is just such a module of scripts, and it should be excluded from both production dependencies and production audits.

For the first, in your package.json file, move react-scripts from the dependencies section to a new section called devDependencies:

"devDependencies" : {
    "react-scripts" : "4.0.3"
}

Then, when you run your audit, specify the –production option:

npm audit --production

Hopefully, if you’re running a modern version of the modules, your audit should be clean after these changes.

dailygrind, Uncategorized, utilities

Video Driver Mess

Written by michael

Ever since I upgraded to version 22, I’ve been encountering infrequent and mysterious video and mouse lockups on my Fedora box. Things will be running just fine and then – blam – everything just freezes and the only way to reset is by leaning on the power button for a hard reboot. Sound keeps working, but the everything else becomes unresponsive.

My first instinct, which lasted for about 3 weeks, was to ignore the problem and just live with the resets. Problems like GUI hangs are rarely simple things, there’s usually some version mismatch in a driver or some strange hardware incompatibility, and they often seem to require some deep machine fu to debug and understand. It seemed the only thing I could do was to try to describe and post the problem somewhere and maybe get lucky that someone responds. In my experience, helpful responses are rare, so I kept procrastinating.

But then I thought, even if nothing comes of it, maybe someone would see it and maybe it might end up helping someone. Unlikely, for sure, but possible. And then I reflected that part of being in an open source community is trying to identify and help resolve problems as best you can. How many times have you found questions and answers on forums or StackExchange that helped you figure something out? What if those people had all just figured help was unlikely, shrugged their shoulders, and lived with their difficulties?

So, I took a deep breath and headed on over to the Fedora Project forum to see what I could find out. The deep breath was needed because the first time venturing into a forum is usually a bit overwhelming. There are usually a bunch of sticky threads that you are expected to read through to understand the forum structure, the searching expressions, and the posting rules. Every forum seems to be a bit different and there is little to do about it except just get stuck in and spend the time needed.

Then comes the overwhelming scale of many forums. There are hundreds and thousands of threads, many of them years old, and many of them kind of similar but not the same as your issue. The thing you have to do is start to look for keywords and patterns in both the titles and posts of possibly related threads until you begin to get a feel for the right way to describe and frame your particular problem. Then, you go back and search again, this time looking for more focused results and adding in time filters to keep it to reasonably recent threads. I like a sieve of about 3 months, which is recent enough to weed out solutions to previous software versions but is still recent enough to cast a reasonable wide net.

So, while I originally went in looking for “gui hang”, after some time I realized that “freeze” was much more prevalent and that a large percentage of freeze-related threads were also about “nvidia” driver problems. A quick check of my PCI devices revealed that I did, indeed, have an nVidia video card in my box.

> lspci -k
...snip...
01:00.0 VGA compatible controller: NVIDIA Corporation NV41 [GeForce 6800] (rev a2)
Subsystem: NVIDIA Corporation Device 0245
Kernel driver in use: nouveau
Kernel modules: nouveau
...snip...

I could see the nVidia card and also that I was using the default Fedora nouveau driver. Many of the threads mentioned that there were, apparently, aspects of nVidia cards that are not accounted for by the nouveau driver, so the recommendation is to use a driver supplied directly by nVidia.

I went to the nVidia site and entered the information for my video card, and was able to figure out that I needed a driver from the 304 series of drivers. You can try to install drivers yourself, but it turns out that they are already packaged properly for dnf install on the nonfree side of the RPMFusion repository (including installation instructions).

> dnf -y update
> dnf install akmod-nvidia-304xx xorg-x11-drv-nvidia-304xx
> reboot

When I tried to reboot, however, the graphics would no longer start up correctly. It turns out there is one more step required to get the akmod you just installed to be rebuilt correctly. Since the graphics are now busted, you need to ssh into the machine and force the rebuild.

> akmods --force
> reboot

At this point, my graphics came up correctly, although the boot process for the GNOME shell seems glitchy, often crashing the shell. Fortunately, if I just wait a moment, eventually everything refreshes and the shell restarts and everything seems to run properly thereafter. I have not had any more screen freezes since I installed the driver, but only time will tell if the issue is properly fixed.

I am also a bit concerned that when I next run a dnf update that I will have to go through some or all of the process again to make the drivers work properly with any newer kernel, but that is material for a future post.

linux, utilities

Code Snippets in WordPress

Written by michael

It turns out that adding code snippets into WordPress is somewhat difficult and, surprisingly, there are no good “official” solutions for what must be a fairly common need. Recall that a WordPress page is just HTML markup, so you have to suitably encode a snippet and embed everything inside the right HTML tags to avoid the snippet being interpreted as code, not text. Most wiki software programs provide macros and functions that take care of the low level details of this process, but WordPress does not.

However, you can go to the WordPress site and hunt for plugins that will do the trick for you. After a bit of research, it seems that the Code Prettify plugin, which is based on the Google Code Prettify library, is the consensus choice for this sort of work.

All you have to do is download and install the plugin from the WordPress dashboard and thereafter all snippets included within <pre> and <code> tags will be displayed correctly.

For example:

int main() {
    std::cout << "Hello world" << std::endl;
    return 0;
}
utilities