Ariel Millennium Thornton @arielmt@computerfairi.es

I don't expect it matters to too many other people, but I'm excited and happy. Anyway, a screenie (croppped) of xcal running and partly customized on my PC: https://computerfairi.es/media/W40bNZdWr2Bhudlybqw

(My window manager is x11-wm/wmx.)

It built, it installed, and it works exactly on my new FreeBSD 11.1-RELEASE #Unix PC like it did on my old Debian Jessie #Linux PC!

Have the fruits of my labor: http://files.thornton2.com/packages/unix/xcal-4.1-patched-for-freebsd.tar.gz

Inside is the unpatched xcal 4.1 source tarball from Debian Sid (as of last week), my patch file, and my notes for applying the patch.

(Packages screenies & desc: https://screenshots.debian.net/package/xcal )

(Also, no, because I set DESTDIR to my staging directory name, I didn't run `make install` as root.)

So I installed it into a staging directory and ran it, and it ran exactly as expected. But attempting to install it into the staging directory revealed another Makefile showstopper: an extra space between $(DESTDIR) and $(XAPPLOADDIR) in the install:: XCal.help make target. So close yet so far.

Hey! It compiles! Ship it!

Me taking a break from tech support:
*sees call for tech support in local TL*
*sees helpful tech support in local TL*
*sees successful resolution no matter the causes*
*does NOT see any blaming*
*basically, sees computer fairies being computer fairies in local TL*

Have I mentioned yet that I love this place? :3

#Linux ransomware in the wild: https://forums.gentoo.org/viewtopic-t-1060828.html

Linux-based malware not only exists but has existed for longer than most Linux users realize.

Also, not running anything as root that doesn't need root helps with defense in depth, but especially don't run as root anything *designed* to download & run completely unvetted code, like Web browsers do.

Sadly, spoiler: Flash Player was suspected but never confirmed as the ransomware entry vector.

Wow, it's been ages since I used diff and patch. Anyway, I'm making progress.

And finding that GCC is apparently happy with non-void C functions using `return;` without a value, while clang (rightly, IMO) throws an error.

I was reminded that PHP is still the only programming language in which a version deployed into production gave "Hello, world!" at least one RCE vulnerability. The one I have in my notes is CVE-2012-1823.

I'm not the only one who uses and customizes xterm. I am absolutely delighted. :3

After hand-patching and creating a new diff comes getting it to compile in clang.

Because absolutely NOTHING I do to the Imakefile is creating Makefiles with "CC = gcc" in them. No matter what, they're all "CC = cc", which is clang's C compiler.

The patch file is a unified diff that contains at least one unified diff nested within.

I sure hope patch processes files in lines from first to last, because that's how I'm making and skipping the hand-editing. :/

"It's the CIA, Charlie Brown"
https://botsin.space/@TheSoundOfBot/785328

If we're going to reuse nonces in WPA2, then we need a way to better verify their integrity. Thankfully, my favorite rag, Hacking Gibsons, was on it four years ago. :V
https://computerfairi.es/media/UkWau8OkX4iwA542ytQ

xcalpr.c:89:21: error: initializer element is not constant
static FILE *fout = stdout;

Everything I'm reading says that hasn't been valid C since before ANSI standardization way back in the '80s.

Oh, duh. The Debian package page has a diff file downloaded separately, and some of them are patches to the C files fixing the compiler error I'm getting. Guess I should read it, edit the source, and re-diff them.

The latest date in xcal's CHANGES file is 1995-09-13.

I don't. Using cpp6 installed by the gcc package works.