False Gems

In all my years of working with Git, this seems to be the first time I’ve run into this error. It’s trivial, but I’ll document it in my dev log anyway. This morning, I couldn’t run git pull:

error: Unable to create ‘[REDACTED]/.git/index.lock’: File exists.
Another Git process seems to be running in this repository, or the lock file may be stale

The typical “someone else is working on your repository” message. Is it a cron job, an IDE, or did I leave a terminal open somewhere? You can check it like this

$ ps aux | grep [g]it        # no active git processes
$ ls -la .git/index.lock     # -rw-r--r-- 1 rinat users 0 Aug 28 19:01
$ date                       # Mon Aug 31 09:09

A three-day-old abandoned lock. That means I can “fix” it by editing the file directly

$ rm .git/index.lock
$ git pull

I keep scripts in one place and use desktop entries so Rofi can launch them.

~/Sync/scripts/
├── lock.sh
├── argo-translate.sh
├── backup.sh
└── applications/
    ├── lock.desktop
    ├── argo-translate.desktop
    └── ...

Rofi's drun mode uses XDG desktop entry directories. To include my custom applications folder, I used XDG_DATA_DIRS:

XDG_DATA_DIRS="$HOME/Sync/scripts:$XDG_DATA_DIRS" rofi -show drun

Recently we had deployed a Flask application on a RHEL9 server where FIPS mode was enabled. It started find but refused to serve any requests. The logs were filled with Unsupported DigestmodError messages.

FIPS (which stands for Federal Information Processing Standards) mode will not allow you system-wide to use any hashing algo that is considered to be insecure. But vanilla Flask (and it's batteries) often using sha1. We have stumbled upon two cases.

A standard Flask stack often uses sha1 by default in two key places

flask sessions

The default secure cookie sessions are using itsdangerious for signing, which can default to sha1. The fix was easy: fask's session interface is designed to be subclassed. We can create a custom session class inheriting it from SecureCookieSessionInterface and tell it to use sha256 as the digest method

flask-wtf

Serializing and signing CSRF token here also uses itsdangerious, that again, defaults to sha1. This is the trickier part. As for now, flask_wtf does not provide a simple config option to change the digest method. We have to create a custom CSRFProtect implementation forcing it to use sha256 serializer.

I was writing a simple server in arm64 assembly and was trying to bind port 300 (spartan).

.hword 0x012c  // htons(300)

The server would bind fine, but to an odd port like 11265. The issue was byte order (endianness?).

My “discoveries” are:

• Network byte order is big-endian
• ARM64 is little-endian

I was storing 0x012c as .hword on ARM64 The kernel reads bytes 2c 01 as big endian, interpreting it as 0x2c01 = 11265

The solurtion was to explicitly define the order:

.byte 0x01, 0x2c

The htons() function will handle it properly, but with assembly you have to do it manually.

aspe:keyoxide.org:6Y7KI4OG4YF5X3X5ASKPTXTRJ4

Recently, after a system update, I became not able to run some of the system tools written on Rust, like exa and bat

$ bat --version                                                                ~
bat: error while loading shared libraries: libgit2.so.1.4: cannot open shared object file: No such file or directory

The fix was easy: rebuild a binary

$ cargo install exa bat --force

Another post to the “suffering journal”. Experienced a lot of hardware fails:

• SSD disks become read-only or other IO errors
• Video card do not start while power on. Had to restart each time.
• Other system freezes of unknown origin.

It happened for a month, and I tried to replace SATA cables, disable “spoiled” disks, do memory checks, use the rest of the voodoo too. Started scaring myself with a shopping list if the motherboard broke.

It was a power unit. No visible signs like an inflated capacitor or burn marks, though. Took a chance and bought a new PU. All problems are gone.