Posted by chmaynard 16 hours ago
What about future attacks by quantum computers? Is Git safe from quantum computers for it's all hashes only? Or shall there be issues with quantum attacks?
I'm asking for there are several projects that are already moving to quantum-resistant schemes (like OpenSSH who uses an hybrid scheme [1]).
And from the other comment, symmetric cryptography is safe too from QC attacks.
So it's apparently as you wrote: it's really only asymmetric crypto that is at risk.
Quantum algorithms require some sort of quantum 'trick' to actually have any speedup over classical computers. The most general quantum trick is Grover's algorithm, which lets you find f⁻¹(x) (given f and x) in sqrt(N) queries rather than N queries, where N is the size of the set from which x is drawn. This cuts the bit security of every algorithm in half, although for things like cryptographic hashes, it really means that a second preimage is now only as 'easy' as finding a collision (due to the birthday attack).
The other really well-known quantum trick is QFT, which allows you to find the period of an unknown periodic function really quickly. This is what allows quantum computers to break asymmetric algorithms based on integer factoring or elliptic curves, since they can both be expressed in terms of the QFT.
But the article helps. Basically Grover’s is not as potent as Shorr’s. And it seems like everyone is convinced there is no dramatically better quantum algorithm than Grover’s?
Grover's assumes the function is a black box that you cannot look inside and that your only way of finding a certain result is through repeated invocation.
Under this assumption, Grover's is optimal in the number of invocations of the function required to find the result.
However, this assumption may be quite wrong for AES and friends. It may be the structure allows for non brute force attacks that are totally impractical classically but not subject to Grover's optimality limitation quantumly.
The only thing you are guaranteed here is that if you cannot take advantage of structure at all then Grover's is the best you can do.
Given that we have pretty much always found a way to take some advantage of structure, I would bet we will do so here.
That may or may not make it viable to break at all, I just wouldn't bet that it must be treated like a black box forever.
To me that would be a very bad bet.
And, if I’m following you, that’s the key difference in Grover’s and Shorr’s: Shorr’s takes advantage of structure?
This has nothing to do with SHAttered
Then you can also do `git diff > changes.diff`. Or simply `rsync -avPh repo/ repo.snap/`, if your repo isn't huge. Or consider putting your repo in a filesystem that can do CoW snapshots.
The solution: create a branch or tag with the things that you're trying. If you want to apply it, use `git merge --squash`. This way your unfinished work lives outside the stash stack!
[1] https://blog.gitbutler.com/how-git-core-devs-configure-git
1. Git push should default to --force-with-lease --force-if-includes.
2. push.autoSetupRemote should be enabled by default.
3. The default conflict style should be zdiff3.
4. diff.submodule should be 'log' by default (gives much nicer submodule diffs).
5. Submodule updates / clones should be recursive by default. (There is a setting for this but I can't remember it.)
This one always baffled me. The default conflictstyle is so hard to read it's almost useless. Using diff3 is mandatory.
I hadn't heard of zdiff3, I'll give it a shot.
receive.denyCurrentBranch should be updateInstead by default (or at the very least mentioned in the help message, rather than it recommending ignore or warn or refuse, none of which do what is wanted)
And sha256 is in private preview at GitHub: https://github.com/bk2204/talk-rust-in-git/blob/dev/presenta...
Priorities!
I wouldn't agree with all of those reasons, but it's very definitely not "just for the sake of it." One of the better reasons so many people look to writing some things in Rust is that we now have pretty ample evidence than trying to write a binary file format parser in C is a cornucopia of CVEs that are just simply absent in Rust, and the excuse of "well, but a sufficiently smart programmer doesn't write bugs in C" doesn't cut it anymore.
I don't see how that's possible without turning the language into something that isn't C, either by adding significant new functionality (e.g. fat pointers) or subtracting enough functionality that it's a much less capable language (e.g. disallowing dynamic memory allocation).
An important improvement over rust is that "Fil-C has no unsafe statement."
In case of fil-c, it is about 1.5-4x slower performance, and a memory overhead.
So, let's not present it as a panacea to all problems: there could good reasons to use it, but it isn't a magic trick.
on my Linux system, C takes ownership of a 'top-level' /usr/include directory, all the kernel APIs have their canonical definitions in C headers, a lot of system features like nsswitch require dynamically linked C libraries etc. etc.
Rust is just something that programs can choose to be written in and that doesn't inconvenience me in any way.
Maybe git's case is different though. Do you have more info about it? Are you a git maintainer who was coerced to use Rust, or do you know of such cases?
Just because something does provide an immediate perfect solution does not mean it isn't not worth investigating and/or pursuing.
Also consider that bugs tend to be more prevalent in new code (e.g., [0]) as a result, you are likely to see more of a benefit from writing new code in a memory-safe language than raw line count proportions would indicate.
[0]: https://security.googleblog.com/2024/09/eliminating-memory-s...
Good, are there (m)any other plans to ditch the slow files and use proper database? Or is it only reserved for various post-git competitors?
The filesystem is a proper database, just not a relational one.
Linus focused heavily on performance when he wrote git; he used the filesystem because, as the main Linux kernel maintainer, he knew that the Linux VFS and filesystems were fast enough for these use cases.
(It's the use cases that have changed; it was not expected back then to have more than a few hundred refs in a single repository.)
Ah, yeah, "you're holding it wrong", though use cases haven't changed, it's closer to the expected common case of expectations turning out wildy wrong (Why would you ever expect people to stop NAMING things at scale???)
But also the core property of the filesystem database has always been low performance for a bunch of tiny things
This is work that Patrick and GitLab have been doing for years now and it's very impressive and nearly complete.