For anyone using a persistent checkout approach, consider how often you should run this command on your checkout, and when you last did.
git update-index --really-refresh
Is `git status` / `git diff` etc relying only on the timestamp of modified local files to decide if a diff is needed?
Because the timestamp on the file was set back, it did not show up in any Git diffs.
If so, that's a pretty sneaky exploit and something I'll bet many build systems are vulnerable to.
This reuse of the local clone is probably done to avoid the needed to clone from scratch. An alternative might be to have a (bare/mirror) clone maintained in `~/.cache/whatever`, then use the `--reference` flag e.g.:
git clone --reference ~/.cache/git-whatever https://github.com/whatever/whatever
Of course. There's no other way to implement these commands efficiently.
But you don't even need to play with timestamps. You can ask git to pretend not to see the changes:
git update-index --assume-unchanged password_change.cgi
Just saying this could have been worse.
I know that FreeBSD's webmin package was affected.
The way I understand releases and tarballs, I'd do it like this:
- git on my machine (supposedly safe)
- bundle the source code, sign it however necessary
- upload and publish the tarball + signature & checksums
That way, unless my own machine was compromised, it should be OK.
In modern times the reason is that the release is produced in a CI pipeline. So once a build is green and matches allmothe rreleas criteria that tested build is released.
In both cases using a git checkout for longer time is not a got idea and builds should be done as exports into clean directories.
Nginx is not too bad but what's the most secure frontend proxy these days? Ideally written in a memory safe language.
One kernel vulnerability and I’m cooked
I was running 1.881, and I'm at least glad I never updated to the 1.890. While I haven't needed to change network interfaces or any hardware related change, I still think it's worthwhile keeping it.
Thanks edwintorok for sharing this. I've patched and disabled webmin, I'll temporarily enable it if/when I need it. Yes, I could do everything through the terminal, but a GUI's still useful in the case where I can't remember/don't know the terminal way of doing something.
While there are other panels out there, Cockpit is sponsored by Red Hat. I'm not a fan of panels, but it offers more functionality out of the box than Webmin. Last time I looked there was some pretty large gaps in functionality outside of a Red Hat environment; the Ubuntu package was missing container management.
It has a long history of vulnerabilities (https://www.cvedetails.com/vulnerability-list/vendor_id-358/...).
They do have a valid Let's Encrypt cert, but apparently it's only configured for the `download` subdomain.
Running git status in an 1 GB checkout directory will return instantly. Do you really believe it has hashed all those files?
The hack here is that the working copy used to build from wasn't a clean clone on each build, so just fetching changes from the (un-pwned) github repository would apply those changes and not affect the modified file on the build server.