Mastodawn

@starchy does this also affect the toolchain for @linux / #Linux #Kernel?

Cuz I do set #kernel666 and the #initramfs for @OS1337 to be compressed with #xz and whilst it's statically compiled against @musl, I still want to enshure this isn't a #SupplyChainAttack affecting me or OS/1337.

#SupplyChain #OS1337

Vanta Puce Mar 30, 2024

@kkarhan My read is that musl builds wouldn't have triggered this backdoor, but I'm not an expert and @OS1337 should probably do their own investigation to rule it out

@starchy That's why I'm asking.

I am the maintainer of @OS1337 and I do want to enshure it's not affected by it...

After all, it uses @linux, @musl, #Toybox and #dropbear and for building it does utilize the #GCC since it seems.as if #Linux doesn't like being built by #LLVM...

Vanta Puce Mar 30, 2024

@kkarhan @OS1337 Ah, that's cool! The musl thing looks helpful, I have no idea how it might interact with the kernel compression, and my own two cents are that it wouldn't be a great idea to trust affected the version of xz

https://github.com/OS-1337/mlb/releases/tag/v0.0.1

@starchy I mean, I don't have #xz as a tool in it, I merely use xz compression for the #Linux #Kernel and #initramfs, and the latter one is scheduled to be integrated into the Kernel Build Pipeline to save space and being able to use #mlb instead of #syslinux so @OS1337 fits on a #1440kB #Floppy and neither @SweetAIBelle nor I are failing builds be a few kB...

#OS1337 #EmbeddedLinux #Distro

Release 20240312 · OS-1337/mlb

compiled against musl-cross i486 - ( thx @landley for providing that) running LDFLAGS=--static CROSS_COMPILE=./i486-linux-musl-cross CFLAGS="-Os" make ARCH=x86 in terminal. This should be used for ...

GitHub

@kkarhan @starchy @OS1337
The build scripts are broken at the moment anyways, so I wouldn't worry too much about it...

@SweetAIBelle @starchy @OS1337

I know...

I've to basically redo the entire build pipeline for #mlb because for that to work I've to integrate the #initramfs into the #kernel...

I just hope choosing #kernel666 for the #meme-factor doesn't bite me in the ass...

@kkarhan @starchy @OS1337
If you check the sb-dev branch, I didn't get it entirely working, but got it most of the way there. Think it's passing mlb the wrong parameters.

(Though there's a hack in there I did that should be replaced with something better eventually...)

@SweetAIBelle @starchy @OS1337

Yeah, I've barely built #mlb and sadly it seems like an abandoned project - I only pulled a fork so I can build the executeable and run it...

I also need to basically build everything except the FDD image, #linux #Kernel and mlb beforehand so I can just include the #initramfs.cpio into the kernel and finally shave ~ 200kB free...

Also thx for your continous contributions to OS/1337 ...

https://github.com/OS-1337/OS1337/issues/10

#OS1337

Boot: "CORE" Edition: Alternative to syslinux - saving up to ~200kB of space on FDDs. · Issue #10 · OS-1337/OS1337

As @landley pointed out, syslinux has perl as dependency and as per observation is consuming quite a lot of space. So far, thanks to @sweetaibelle the following options are on the table: mlb - Mini...

GitHub

@kkarhan
No problem.

Pretty much the branch corrects the name of the script you were calling to build it, fixes the build order (the working directory needs to be created before putting things in it!), gets rid of a buncha sudos, and some other things.

Trouble was I basically got it to the point where you can see the install program gets build and called, then it just spits out a help description because it's missing arguments, and, well, I've never used mlb, so I wasn't sure of the right arguments. :P

Also, I had to hack the name of the build folder into the kernel parameters, because it does not know where "$PWD/initramfs.cpio.xz" is. Doesn't seem like it expands env vars...

@kkarhan
Mostly I went to go work on the project, and it was broken, so I worked on the broken bits instead...

@SweetAIBelle thx.

Remind me to merge that...

@kkarhan
No problem.

What I consider a proper fix to the hack of putting the base folder name into the kernel config is to have the bash script edit it into the config file when you run it, btw, but that's one of these things where I'd have to figure out how to actually do it...