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.
> Good, are there (m)any other plans to ditch the slow files and use proper database?
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
> GrapheneOS's goal is privacy for the world and that's achieved through secure devices.
Perfect is the enemy of good. What's better for privacy, an old but inexpensive smartphone running Android 11, or the same smartphone running an up-to-date third-party rebuild of Android 16 or newer with as many privacy-improving bells and whistles as the hardware can support?
> Soon there will be two different phone brands which you can install it on.
...will they be available in my country (Brazil)? I don't think I've ever seen a Google Pixel phone in person.
Not sure if you have any experience with eBay. I looked it up and people had problems selling to Brazil [1] but there are various listings that offer to ship. So maybe not a great option.
KaBuM!, Intec Store, Performance Solutions all charge significantly more with a 10a being more than double than from Google.
Motorola officially sells the Signature in Brazil [2] at the same price or cheaper than in the UK. It will be supported by GrapheneOS in 2027 on the 2027 version. From then on, hopefully Qualcomm brings MTE to the non-flagship chips and Motorola and GrapheneOS support budget or midrange devices.
>perfect is the enemy of good
I don't consider that relevant when users deserve ≥ security than an iPhone. GrapheneOS is not purpose-built to avoid big-tech's services although it does that more completely than any other alternative mobile operating system, the focus is privacy.
> Are all of these unsuitable [0]? [...] I looked it up and people had problems selling to Brazil [1] but there are various listings that offer to ship.
Do these phones have ANATEL certification? Because if they don't, they will be rejected by customs. It's not simply a case of the item being held until you pay a 60% import tax.
There are [1] people currently using GrapheneOS in Brazil. You can ask on the forum and you might get more clarity. The Motorola Signature will be announced in a few days but is a high end flagship with all-around better hardware than the Pixel 11 Pro XL and it's cheaper, but it's still a flagshio.
What's better for privacy, an old but inexpensive smartphone running Android 11, or the same smartphone running an up-to-date third-party rebuild of Android 16 or newer
I see your point, but it would be very misleading, since the phone would still have a lot of known holes. Only the OS would get updated, typically not the drivers, driver firmware, possibly not the kernel. The phone would still be easily compromised through all the known RCEs. So you tie up non-profit projects in a lot of extra work to get an improvement that does not really matter.
This is a mess created by the OEMs and they will continue to create this mess until people will stop buying from OEMs that only give lip service to security updates (roll out Android Security Bulletins to show a high patch level, while in reality the phone the phone has many known CVEs).
Android Security Bulletins do list a tiny subset of firmware, Linux kernel, driver and HAL patches so they do require at least very minimal updates to those. Most non-Google-certified operating systems are setting an inaccurate Android security patch level by ignoring the non-AOSP portion of the patches. GrapheneOS doesn't do that but most of the other AOSP-based projects not being certified by Google are doing it. OEMs were caught doing it too but it's not clear if it was intentional in most cases as it is with the alternate operating systems.
Android Security Bulletins set a very low bar since the AOSP patches are available to ship by OEMs 2-6 months prior to the bulletin being published. It's also only High/Critical severity patches being listed. Due to a recent policy change, it's also officially only a subset of the patches for AOSP. That's visible through the Android platform components having patches in the Pixel Update Bulletin for September 2026 despite those being applicable to other operating systems. It's because they no longer want to backport all High and Critical severity patches due to the high volume of issues discovered by AI models. It's similar to how they stopped backporting any Low and Moderate severity patches years ago due to high volume.
The purpose of GrapheneOS isn't providing a less bad operating system for insecure devices which still lacks anything close to reasonable security patches and protections. It would not be possible to provide the core GrapheneOS feature set on those devices. More importantly, they'd have many years of missing firmware, kernel, driver and HAL updates. Those are among the most important security updates and would not be available in practice. That would not be GrapheneOS and is not the purpose of GrapheneOS.
> Same as traditional physical keys, you don't have a single key, you have multiple ones [...]
I have multiple identical ones.
> [...] and can go to the local locksmith and get another one in minutes.
Can I go to the digital equivalent of a locksmith (like a backup software) and duplicate my passkey? Can I do that with only my passkey in hand (without having to do anything to the corresponding lock, or having to contact its issuer), like I recently did with a physical key?
Heh, in the security world, this shows how your traditional metal key is "something you know" (like a password) because it can be copied and many people can know it at once!
So if we are enforcing MFA requirements and allow this kind of clonable key, then we should really require some other factor that is not clonable.
That's the core silliness of this whole passkey mess, IMHO. So many turns of rhetoric and weird compromises, we have cargo cult security and no real understanding of what security level is in place.
Instead of the best of worlds, we can accidentally have the worst of worlds without realizing until it is too late and we're painted into one of those ugly corners.
> Heh, in the security world, this shows how your traditional metal key is "something you know" (like a password) because it can be copied and many people can know it at once!
If you have a photo of a traditional metal key, you can duplicate it. AFAIK, there's also a numeric representation of the height of each position on the key; if you know that number, you can duplicate the key. A traditional metal key is more like a password than most people think.
> > What if the computer you want to log in on doesn't have Bluetooth?
> Only if they’re a bit old. Nowadays WiFi chips double as Bluetooth chips on newer platforms.
What if the computer you want to log in on doesn't have a WiFi chip?
It doesn't have to be an old computer; for instance, the desktop computer I built last year uses a wired gigabit Ethernet connection to the router right next to it, and doesn't have (or need) any WiFi or Bluetooth chip.
> but what many people do not know is that debugging NPEs in Java is easier now - they carry more information about the source
Unfortunately, no, they don't. Not after your application has been running for a while; newer JVMs arbitrarily decide you don't need the stack trace anymore, and all you see in your logs is "NullPointerException" (unless you still have the logs from several weeks ago, just after the last JVM restart, which might still have the full stack trace). Older JVMs were better, since they always had the full stack trace; debugging NPEs was easier with them.
> And another positive point for Java: checked exceptions. It's verbose, but knowing exactly in which ways a function can fail is extremely helpful for building robust applications.
Sorry, but no, Java has the worst of both worlds here. It has checked exceptions AND unchecked exceptions, AND errors which are like unchecked exceptions but won't get caught by a normal catch-all (you're not supposed to catch Throwable, but it's the only way to prevent some dynamically loaded plugin code ten layers deep in the stack from breaking your invariants or stopping your periodic scheduled task due to an errant NoSuchMethodError or NoClassDefFoundError).
And you can't easily use checked exceptions with Java8-style functional code, since interfaces like Function aren't generic on the exception type. Which leads to aberrations like UncheckedIOException, which exists only to make IOException usable in the functional world.
The issue is that magnifying the screens to fill your vision makes reasonably sized text very hard to read. You have to make the entire screen/text in front of you fairly large to make it legible. There are many other headsets with identical resolution panels, you can find this info everywhere
reply