<farkuhar>
I did see that you got a response from emmett1 about the cruxbridge. Thanks for passing that along.
<farkuhar>
Heh, the tiktok video uses as background music a very-slowed-down version of "In the End" by Linkin Park. I almost didn't recognize it at first.
<SiFuh>
farkuhar: Heh, it was very obvious.
<SiFuh>
Very interesting video though.
<SiFuh>
farkuhar: I bought a battery operated reciprocal saw. Tomorrow I plan to cut down two trees.
<SiFuh>
her mother has been complaining about them going to grow too big and break the waterpipes. Last week, I see the roots in the drain and around the waterpipes.
<farkuhar>
Any news on the vulnerabilities reported for CUPS and CUPS-filters? It's been rather quiet in #crux after the initial commentary by frinnst and leah2.
<SiFuh>
Cutting is the easy part. Digging up the stump is going to be fun without my truck
<SiFuh>
farkuhar: None that I am aware of
<farkuhar>
Stump removal, heh. I was part of a four-man team that used a rental backhoe to get rid of a pesky stump in 2017.
<SiFuh>
I usually put a rope around the stump, loop off of a tree and then at an angle away from the tree, drive the stump out of the ground with a petrol engine on 4 wheels.
<SiFuh>
But this is going to be tricky because the stump has grown around the waterpipes. So I might be out there like an archaelogist slowly chipping away for a day
<farkuhar>
Some commentators are saying that the CUPS vulnerabilities are overblown, relying on too much social engineering to achieve remote command execution. If you pay close enough attention to the printers that appear in a print dialog, you'll be safe from any exploit.
<SiFuh>
farkuhar: Use a wired network, and stand guard with a shotgun.
<farkuhar>
The backhoe in the 2017 stump removal only played a part at the very end, after chipping away like archaeologists with pickaxes and shovels. I remember there was some rope involved, but I forget whether we tied it to a truck or to the backhoe.
<SiFuh>
You maybe had it tied to the boom
<SiFuh>
You don't tie it to a vehicle and drive, it is how you end up with a smashed in back or or a broken back window.
<SiFuh>
That's why we use a tree and loop off of it at an angle. So if it flies it heads to the tree and not the vehicle.
<farkuhar>
I have some photos of the event. Maybe they reveal more details than my hazy memory can reconstruct.
<SiFuh>
Cool
<farkuhar>
Ever tried using fire to burn the stump away?
<SiFuh>
Yes
<SiFuh>
And cook a meal over it
<SiFuh>
But I am sure this one is toxic.
<SiFuh>
So even if I did start a fire inside of the trunk and dried it out as it was burning away. The fumes will probably be dangerous to breath.
<SiFuh>
This will be a fresh stump when I cut it.
<SiFuh>
Oh and I have two not just one
<farkuhar>
Arbitrary command execution is claimed to be possible through cups-filters because of all the convoluted tricks needed to transform the original data into something the printer understands (=> no restrictions on the contents of PPD files). As for the vulnerability in cups-browsed, I didn't read those details too closely. On CRUX the cups-browsed is a separate port that I never install.
<SiFuh>
So is there a team of monkeys working on an obituary for this arbitrary command execution?
<farkuhar>
Only the usual suspects who monitor the latest CVEs. If you consider them a team of monkeys, then yes.
<SiFuh>
farkuhar: Maybe all Tranny monkeys now.
<farkuhar>
The CUPS that we take for granted today was descended from work done at Apple, eventually open-sourced. The latest CVEs might be cited by anyone with an anti-Apple bias, but the connection is rather weak at this point.
<SiFuh>
farkuhar: I use cups. But I have it setup so that I don't need it on the client. I only have it on the NFS server.
<SiFuh>
Bit of voodoo ;-) Don't see the point of having a cups client and a cups server.
<farkuhar>
Heh, building iproute2#6.11 gives a new error this time: initialization of 'int' from 'void *' makes integer from pointer without a cast. https://0x0.st/Xgqy.log
<SiFuh>
farkuhar: What does that me "pointer without a cast?"
<SiFuh>
mean*
<farkuhar>
The compiler message is a bit more helpful this time. Previously it looked as if it couldn't recognize equivalent types, but that was only because the superficially identical type declarations were not in the same scope, so the compiler treated them as independent.
<farkuhar>
I think the latest error means that the compiler insists on an explicit casting of the pointer to an integer type.
<SiFuh>
Sounds all Greek to me
<ukky>
for 64-bit Linux, you cannot assign pointer to an int. Pointer is 8 bytes, and int is 4 bytes.
<SiFuh>
ukky: Makes more sense. Thanks
<ukky>
for 32-bit Linux program, you can do that, but C forces you to do 'cast'.
<farkuhar>
I wonder why I didn't hit that error on the last build. Somehow I got a successful build of iproute2#6.11 on CRUX-MUSL, but that was a week ago and some other packages might have been updated since then.
<SiFuh>
I'd like to see error messages in Layman English. Just like I'd like a Schizophrenic GPS that argues with itself.
<ukky>
You might have 'permissive' warnings. If you treat all warnings as errors, compilation will fail.
* farkuhar
checks /etc/pkgmk.conf for possible changes to CFLAGS
<farkuhar>
Nope, don't see any new flags that would elevate warnings to errors.
<farkuhar>
Maybe I should just insert 'cast' in the arpd.c file itself, rather than trying to mess with CFLAGS.
<ukky>
farkuhar: try to compile like this: make EXTRA_CFLAGS=' -v ' V=1 -j1
<ukky>
Check which C flags gcc has for arpd.c
<ukky>
And you need to check arpd.c:442 to see what is there. Simple (int) might work, but you need to see what gets initialized by that int.
<farkuhar>
Apparently it's using -Wall. That means all warnings get treated as errors?
<ukky>
yes, -Wall treats all warnings as errors. Well, not all, but most.
<farkuhar>
The other flags used for arpd.c are: -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wold-style-definition -Wformat=2
<farkuhar>
Weird that the default CFLAGS would have changed between September 22 (the date of the successful build) and today. I never touched /etc/pkgmk.conf, and the iproute2 tarball is the same one used when building a week ago.
<ukky>
I was wrong. -Werror treats all warnings as errors. Plus -Werror=warning-name. So, there should be something else that triggers error.
<ukky>
farkuhar: did you install berkley db after 9-22?
<farkuhar>
Well, I got past the arpd.c error by inserting (int) for the explicit cast, but now gcc is complaining about some similar implicit casting under the rdma directory. This release has to be the most poorly-tested in the history of iproute2.
<farkuhar>
ukky: berkeley db hasn't been updated since September 2023, so the same version of db would have been present both now and at the time of the successful iproute2 build. I don't think the error can be blamed on Berkeley db.
<ukky>
Well, arpd.c isn't compiled if Berkley DB is not installed.
<farkuhar>
How could Berkeley DB not be installed? It's both a core port *and* an explicit dependency of iproute2.
<farkuhar>
Oh, and the rdma.c error is more than just converting without an explicit cast. There must have been some missing #includes, because gcc did not recognize 'basename' as a valid function at rdma.c:110.
<ukky>
I compiled iproute2 from my own amd64-glibc crux ISO, using temporary i386-musl toolchаin
<farkuhar>
Now I need to figure out which header in musl provides the 'basename' function, so gcc will stop complaining about the implicit function declaration at rdma.c:110.
<ukky>
There is a bug in arpd.c when using musl. They initialize msghdr structure using init array, {...}. That is not portable and initializes wrong structure members in musl libc.
<farkuhar>
As I said, the most poorly-tested release in the history of iproute2.
<ukky>
You cannot simply cast pointer to int in that case, as it initializes wrong structure items.
<ukky>
You can see structure msghdr here: /usr/include/sys/socket.h
<ukky>
glibc defines that structure differently: /usr/include/bits/socket.h
<farkuhar>
I'll get back to iproute2 later. There's still a few hours of daylight that I'd like to spend outside. Thanks for your help, ukky!
<ukky>
You are welcome
galambo has joined #crux-social
ppetrov^ has quit [Quit: Leaving]
lavaball has quit [Remote host closed the connection]
<farkuhar>
The iproute2 git repo has a few recent commits that sound promising: "arpd: use designated initializers for msghdr structure" (9c9824b) and "bridge: mst: fix a musl build issue" (6a77aba).
<farkuhar>
I'm glad they're back to prioritizing code correctness, rather than focusing on cosmetic issues like "non-inclusive language" in the man-pages and the source code comments.
galambo has quit [Quit: Leaving]
<farkuhar>
Finally, I got a successful build of iproute2 on CRUX-MUSL using the latest git checkout. I still had to insert a few #includes into libnetlink.h, though (endian.h and libgen.h).