
Re: Re. OpenBSD's partitioning scheme
You can float the idea to Theo, just don your asbestos underpants beforehand.
17 publicly visible posts • joined 30 Apr 2024
This wasn't really anything to do with storing secrets in the repository, if that was the case anyone could just clone a public repository and pick through it. Good advice nonetheless though.
GitHub provides safe secret storage, (it's all based on public key crypto if you peek under the hood), but at some point you have to provide those secrets to your pipeline(s), in the clear, unless every tool knows how to directly speak to your chosen secrets manager.
Normally what happens is any GitHub secrets used automatically install a filter such that any time that secret value is logged, it gets ***'d out, which can be mildly amusing if you're testing things and set the secret value to something fairly commonplace that occurs naturally in your logs, i.e. set a secret with a value of "test", anywhere "test" appears in your logs, even if it's nothing to do with that secret, it gets ***'d out.
Because secrets are write-only if you ever forget what you set the secret to, you can't just run an action that logs it because it will get masked out as above, but you can pipe the secret value through base64 or similar encoding and log that, the filters are not (yet) clever enough to catch that. You can then pick the encoded value out of the logs and decode it. This is basically what the attack was doing.
I love a cheap shot at micros~1 as much as the next person, but to be fair, this wasn't their fault.
There's a third party marketplace for actions you can use in your GitHub workflows to save you reinventing the same wheels over and over again. It just so happened that one of those actions was compromised.
One reason to explain the low contributions, to Terraform at least, is that the repository that was forked is for the core Terraform binary/language. That doesn't really change all that often.
What _does_ change often are the individual providers, for things such as AWS, etc. which are in separate repositories and are (currently) still licensed under the MPL or similar, so they haven't had a need to fork those yet.
Many years ago I had to phone the HP server support line where the on-hold music was panpipe renditions of popular hits.
After listening to the panpipe version of the monobrowed purveyor of ultimate filths "Lady in Red", the poor support tech who eventually answered got an earful from me.
I didn't realise PCengines had shut up shop. I've been using an APU4 as my firewall & router for a good few years now and have been really happy with it. I had to switch after my Soekris board I was using previously developed a fault and I needed a replacement.
That means for the next upgrade I'm going to have to do the same dance again and find a small fan-less board with SIM slots, mini-PCIE, etc.
Yes, when they first went "digital" they first tried LCD/TFT-type displays and I thought the same. Sure enough they all started to fail with various screen burn symptoms. I thought at the time whoever spec'd those needed shooting. Then they switched again to the current orange dot matrix style which seem to be much more reliable apart from when they throw these occasional baud rate burps and I have a wry smile to myself.
It was slow because apparently the Commodore marketing department insisted that the C64 be compatible with the 1540 disk drive which had a hardware flaw that dictated that the C64 do everything in software so that's how the 1541 worked as well, even though the 1540 didn't really work very well on a C64!
I remember getting my Action Replay cartridge, a little red box of wonder.
There certainly used to be a database of Linux on various laptop models, I should know as I maintained pages for two such laptops, an HP and Sony each of some flavour that I've since forgotten and no longer own.
Found it: https://linux-laptop.net/
Although it looks a bit different now to how I remember it.