Some thoughts without any particular direction
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
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
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:
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, I faced an issue where curl (and browsers) couldn't resolve a hostname, but other tools like dig and nslookup worked fine. I want to share how I solved this problem in a simple way.
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
Error: Failed to download metadata for repo 'appstream': Cannot prepare internal mirrorlist: No URLs in mirrorlist
So now we have the same issues that we had for Centos 6. And therefore we can fix it like it was described in previous post.
$ sed -i 's,baseurl=http://vault.centos.org,baseurl=http://vault.epel.cloud|g' /etc/yum.repos.d/CentOS-Linux-*
Another post to the “suffering journal”. Experienced a lot of hardware fails:
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.
TLDR: Dockerised Syncthing using NFS mounted folder is a bad idea.
I've spent almost two weeks without a laptop and very restricted mobile internet. When I sat at the keyboard again, there was no that excitement level as it used to be, even close. Maybe I'm just so tired after more or less hardcore trailing experience.
That place is a nice tool for writing by the way. It could be a neat tool to draft post ideas and tidy up formatting. But such short posts should not exist as a blog post and it fits tweet format which is not my intention.