Where?

The attack is vague and unlikely, but blak3 might be faster. Of course less support than sha256

Good thread. For mentees learning git, I would start with a clear branching habit before worrying about hash internals.

Can't argue with that! The fact that you cant mix and match within a repo means this should be a complete non-starter.

I don't think your Wayland comparison is great. There are already solutions to app isolation that make X a weak link, e.g. Android or Qubes. Whereas there's basically no future where SHA1 in Git is the weakest link.

Also security was only one reason for Wayland.

Migrations like this are a good reminder to write down why a default changed. Junior devs often skip reading the design discussion, but it teaches more than the release notes.

Very interesting. I taught git to students last year and was showing them the SHA256 option and the issues he's describing was pretty much what I was wondering about. If you force people to switch, with no intercompatibility, holy shit this is gonna be quite the clusterfuck!

What I'm taking away from this is that Linus was right from the get go : SHA1 isn't there for security, it's a really good algorithm for a hashtable's hash where we really want to avoid collisions. That's it.
If you're thinking it's safe because it used to be involved in security, you're a muppet.

he gives a pretty reasonable solution at the end? basically his point is the implementation is problematic and causes churn for everyone who uses git and if the concern is really about security then they would allow swapping out the verification hash instead of hard coding it again and waiting for 256 to be broken.

Wayland actually increases the barrier to entry by improving the security model.

Git commit hashes were never meant for security or trust, and trying to crowbar them into that role is shortsighted, as Linus argues.

Personally, I'm in favor of the migration and would already be using it (except Nix only supports sha1 atm). But, the security argument isn't a good one.

I'm in favor of a better hashing algorithm because the hash will be a better hash, not because I think it will improve the cryptographic security and trust of my repos. But honestly, that's just a nerd mental thing. I could take it or leave it. SHA1 is sufficient for the role.

The author makes the argument that we shouldn't update the hashing algorithm because an adversary has simpler, cheaper means to achieve the same goal of injecting malicious code into a project. I don't find this a convincing reason. People say the same about Wayland. As I understand it, Wayland makes it so that processes can't see inside windows in other processes or observe the keyboard when one of its windows is not in focus, something X11 apparently doesn't guarantee. They say we shouldn't switch because it would achieve nothing: an adversarial program could just as easily do similar snooping because it has access to the user's home directory. I think that just means we need to also patch the other holes. You can't improve security by doing nothing. It's like you have two insecure doors in your home and you don't bother installing a lock on one because an intruder could easily get through the other one. You have to start somewhere. You can strengthen the hashes and try to patch the other holes (social engineering, etc.) at a later point.

Addressed in the article.

Why not blake3?

great read, thanks for sharing!

when it comes to secure messaging, self-hosting is generally encouraged... while not quite self hosted, it would make it easier for the majority of users to get started.

users can choose a git storage provider of their choice (GitHub, Gitlab, etc), or host their own git server.

for self hosting it’s overkill but makes deployment easier. You can choose any git provider.

I introduced git as an replacement for peerjs in my project. I describe my app as a "decentralised P2P messaging app"... Using peerjs introduces a centralisation in an otherwise decentralised architecture. It also has the additional advantage of allowing users to send messages when peers are offline. Previously not possible with the pure webrtc approach.

You've insufficiently described any technical reason to use git as the basis for your chat history. Git is a poor choice for all the reasons I explained in your last post and more. It's like using paint as glue or using a microwave to heat your bathwater.

While it might be technically possible and work on first glance, there are few to no technical advantages to doing so, and anyone could tell you as such. In fact in some cases it might even be a detriment.

In your posts, you're talking about the usage of Tor and how WebRTC is a bad fit compared to Git and I can only guess at how you reached the conclusions you did.

Literally just ask your AI why using Git as the basis for a secure encrypted messaging application is a bad idea and I'm sure it could do so more eloquent than I.

Like, my first thought is "why not use https or even TCP directly rather than Git" sqlite and a TCP socket is more sane than this.

I'm genuinely curious. Can you elaborate?

I've seen vibecoded slop too. To avoid it being mistaken for slop I created documentation, tests, etc.

Perhaps individuals shouldn't be allowed to make cybersecurity software. You may understandably want this done by a group of experts.

Getting traction on any project can be hard and I'm curious what nuances I might be overlooking.

I'm actually not against vibe coding, but this is the kind of stupid shit people point to when they say vibe coding is bad.

I've approached OSTIF.

"Sadly at this time, OSTIF is unable to provide you with security work. We wish you and your project the best of luck and much success to come."

They suggested to take a look at opentech.fund ... Similarly rejected.

"We very much appreciate your submission to the Open Technology Fund (OTF) for consideration. Upon evaluation, we have decided that OTF is not able to provide financial support for your project at this time."

Going close source is a fairly recent change in direction for my project. I hope it's more clear why Im not going to bet on support by open sourcing my project.

It certainly isn't enough for the cryptography alone to be secure. Cybersecurity is full of nuances when it comes to the supply chain. Concerns around apps like mine running on untrusted browsers sits in contrast to something like the Signal app running on untrusted hardware/OS/networks.

When talking about the supply chain vulnerabilities, security can be easily undermined if you have screen sharing malware on your device. Neither browser or native app can protect against that. As a browser app, you have more flexibility in choice of browser and OS compared to something like Signal.

The rust approach is intended to further break out of that limitation (albeit close-source, unaudited, etc).

1. Okay, but it sounds like you haven't yet investigated any of the sponsored security audit solutions. These aren't quite the same as a grant.

https://ostif.org/get-an-audit/

But by making yourself closed source, you kill any chances of getting access.

It's not enough for the cryptography to secure. An unverified, unsigned, unhashed index.html that the user still has the same issues outlined in the article above. The supply chain has to be secure as well.

I didn't mean to confuse audits and funding. I meant grant funding could be used to get a security audit.

Ive applied to several. I got an email the other day from NLNet to say they had a record breaking number of applications which is why they are taking so long to evaluate... It's not my first time applying there. I expect they will reject the project (it's for the signal protocol project).

JavaScript has a lot of rhetoric against it being used for cryptography. I've tried to justify the approach, but it was an uphill battle from the onset. My approach is still unique in that it can run locally from index.html without a static server. It's further explained here: https://www.reddit.com/r/CyberSecurityAdvice/comments/1ev5kqn/is_this_a_secure_messaging_app ... That version of the project is deprecated.

Glitr as seen in the main post above, is written in Rust. Not only avoids concerns around web crypto, but also being able to build for multiple platforms. I'm aiming for native build as well as a TUI. (I'm only promoting the webapp because I want to focus on that version first). The main reason for Rust is that there is more mature tooling around cryptography and formal verification.

1. A security audit is not the same thing as a funding grant.

Have you investigated the open source security audit organizations?

2. https://www.devever.net/~hl/webcrypto

(Sorry for this being so long... Feel free to reach out for clarity on the details. Long-story-short. Sure those orgs exist... But they aren't rushing to fund projects that are simply open source)

You're over simplifying. So let's add some context relative to this project.

I have several open source projects. This project started off open source and I keep the version open source because it demonstrates a fairly unique concept around avoiding installation and registration.

https://github.com/positive-intentions/chat

I handcrafted that version. It's open source with the commit history. It was before the days of agentic AI. I spent countless hours considering countless details. I could spend countless more on improving the quality there for things like unit tests.

I had something reasonably unique and so I tried to apply for funding. I tried very hard, several places, several times. All rejections.

Grant applications are a horrible experience. It's not something I had experience in before and it carried a exhausting learning overhead... But if I could get funding, it would be worth it. As AI become more prominent, I'm sure these organisations are overwhelmed with how many submissions they have.

My conclusion is clear; if it's been this hard to only receive rejections, I'm no longer going to bet on open source. It's clearly not a good business plan.

I consider myself a seasoned developer. So as I'm working on my project, I'm taking on feedback and made improvements throughout.

I still believe in things like kerkhoffs principles. So as part of the continued development, I created a version of the signal protocol.

https://github.com/positive-intentions/signal-protocol

I aim for it to be for production use, but without a third party audit, open source is worthless. When sharing it online, the conversation cannot move past that it's created with AI. It undermines all the time and effort I put into it. I created things like formal proofs/verification and security audits. I kept all the documentation honest that it was created by myself with AI. I think the approach is honest and transparent.

I see the project is well received in various subs, but the cryptography subs that can actually understand what I created, I just risk being banned for sharing AI slop... And thus this close source approach.

Going close source is particularly ambitious because there is an element of "trust me" to it (I don't like it either)... but it appears to be the only way to proceed at the moment.

I don't need it open source so people can debug my code. I open sourced it previously for discussion... I now realise my project is simply too complicated to discuss. It's not for lack of trying.

There are organizations that audit software for free, for smaller developers.

But they only do so if it is FOSS.

You have now essentially killed your project, since you will not be able to afford an audit, and nobody who knows what they are doing will look at an encryption protocol or app that hasn't been audited.

No, using a directed acyclic graph as a backend for a messaging app makes perfect sense, it's what matrix does!

A significant portion of matrix's problems stem from the fact that it was originally a blockchain research project that somehow turned into a messaging app.

The git usecase here is not version control. The repo size would swell to a large size easily if people exchange large files. The app flattens and truncates the history.

GIT tracks changes, which doesn't strike me as something that often happens with messaging. Unless you just always replace your last message with the new one, I guess, then sure!