Length extension attacks are not an issue for git, because every object has two fields in its header, which is prepended to the object before hashing: the object type and the length in bytes.
Interesting. Anyway, since they're going through the pain of changing the hash function, why not using the latest standard? SHA3 has been standardized for some time now, and using SHA256 isn't any easier than using SHA3-256.
> they're going through the pain of changing the hash function
They've already gone through the pain, deciding on it on 2018[0] (and functional & non-experimental 3 years ago per TFA). What's left is just changing the default (and some stragglers to complete support). Changing the function now would push back changing the default by a couple additional years until the new git version gets widespread deployment (incl. on LTS distros and whatnot).
But, which kind of bribe are we talking about? How could it work out in practice for an AI to acquire something valuable, and at the same time prevent it's human operators from taking it without its consent?
It doesn't have to acquire it, it's enough to convince the operators that it did. Same pattern generalizes to threats.
There's so many angles to go at it too, beyond bribery and threats - humans can be tricked, nerd-sniped / baited by exploiting their curiosity or worries, overwhelmed with information or raw sensory input, etc. Depending on whether there's more than one operator involved, the trick may involve playing one human against another, etc.
Hell, humans get tired; I wouldn't be surprised if an effective breakout happened just because agent output something that, at first glance, looked like system-level message that makes the operator do the wrong thing in panic, or from muscle memory. Simple thing like:
$ sudo journalctl ...
password:
Timed right, might give agent root for long enough to do some damage before the operator realizes their mistake and pulls the plug (assuming there is a plug to pull).
~30 years old here, and I can confirm I risked and suffered data loss multiple times. I remember when I still was at my parents house during university I had in mind to build a NAS to properly host the family's photo archive (main reason was bit rot protection, which we experienced, but I was planning for a proper backup as well). But I kept procrastinating. Then, I risked losing it due to a distraction. After spending one week to recover it, building a proper solution to host and backup it became top of my list.
Unfortunately, your comment reminds me that car manufactures aren't Google or Apple either, and still it seems that modern, high-end cars have a tendency of collecting more than what's needed for the car to remain in good shape or be diagnosed. I guess we became so defeatist when more and more companies started realizing they could make extra profit by collecting data from their customers.
If you have lots of data, I would suggest using a filesystem designed for this, like ZFS or BTRFS. You would still have to spend in storage though, as ultimately protecting from bit rot requires redundancy.
I do use btrfs, but I don't really understand how to use it to protect against bit rot. I tried to look into it at some point, but got overwhelmed. Did invest in two backup copies, one of them off site, though.
However, looking at prices, I can see one of those backups just being dismantled to be used as more storage.
Zfs and btrfs will avoid corruption caused below the file system layer, not something like malware or misuse from a tired sysadmin. I run a tool called integrit that creates checksums and lets me detect non-wanted changes. I only run it on important stuff that does not change too much like photos and videos. Not fun to have to regularly check the log but it works fairly well. This could maybe be extended with automatic checking of the logs.
If you got overwhelmed in trying to understand how to do it, just do it the easy way: create a ZFS pool of two drives of identical size in mirroring. Then, make sure to have regular scrubs (this means ZFS will regularly check all files for corruption, and recover from eventual errors), use your OS' task scheduler (e.g. Systemd or cron) to run this once a month. This should be sufficient to protect you from bit rot.
I've currently got two 10TB, one 14TB and one 18TB drive. I don't think what you describe is as easy for me as you expect. I've got one backup in a different city and one in cold storage.
The sizes are all over the place because I only buy a new drive when I run out of storage and then just get the largest one within a reasonable cost. It has been cost prohibitive to mirror everything and current prices aren't encouraging. Neither is the rate at which HDDs get larger. I was kinda hoping for 100TB drives under $400 by 2025 back in 2014, but that hope has been shattered.
I also struggle to reconcile these things, I guess the only way would be to try and see if it works for me, without caring too much if it works for other people on the internet. I would just like to add that, DwarfStar's author (Salvatore Sanfilippo) is a strong supporter of the idea that you shouldn't read the code, and he says he never read DwarfStar's code. And still, it seems that this project is much more than PoC and actually both usable and useful for people doing local inference (I didn't try it myself, but I saw a lot of positive comments about it). Could be that the crucial point is in how we use those models: instead of giving it a general goal (e.g. build me an inference engine) Sanfilippo, being an experienced programmer, kept pointing the models in the right direction. He also read the papers related to the models he was programming support for in DwarfStar, so that, when he worked on optimizations, he knew what should be done instead of prompting a general "please optimize this". So, I would say that, if you let the agents work on a "feature by feature" basis instead of trying to on3-shot things, you get much better results. Could also be that, by attempting to one-shot large projects, the model starts coding badly due to context window exhaustion.
Sorry for the not so well written comment, I was just throwing in some ideas.
reply