I love how the author thinks developers write commit messages.
All joking aside, it really is a chronic problem in the corporate world. Most codebases I encounter just have "changed stuff" or "hope this works now".
It's a small minority of developers (myself included) who consider the git commit log to be important enough to spend time writing something meaningful.
AI generated commit messages helps this a lot, if developers would actually use it (I hope they will).
This is a team lead/CTO problem. A good leader will be explicit in their expectations that developers write good commit messages. I've certainly had good leaders that expect this.
Yes, and a culture problem, too. I guess I've been blessed that I've mostly only worked for "grown up" companies, but I've never encountered a workplace where people didn't write useful commit messages. At least one line description of the work done, but often multiple lines of valuable context. Only the junior devs had to be told to do it, but once they got into the habit, everyone understood why we do it and it was no big deal.
If I joined a company where people committed their code with "stuff" or "made some changes" or "asdfhlfo;ejfo;ae," that would be a red flag that I might have joined the wrong company, and I'd start to wonder what else the developers here do carelessly.
Indeed. If you can't spend two minutes (MAX) writing a sentence or two explaining what the commit is for, then what are we doing as developers? Commits are for future you and your future team. They are a tool. Please, use them.
Good commit messages would be nice but honestly I would be over the moon if our pull requests would be approved within a week without having to ping one or more people.
haha as if. I mostly do bugfixes, small features, and otherwise most of my PRs are just unit text fixes so that our CI jobs run again (because my colleagues don't seem to care about breaking tests, so I get to fix everyone's tests, so that QA doesn't go postal).
To put it into numbers: my PRs are usually less than 5 files changed, and very little changes in those files.
The same goes for code comments though people are much more vocal about their disdain. It's ironic given how frequent AI is used to generate docs. But docs are much better written by the person who wrote the code, the person who has all the context.
These things never take much time but people dismiss them because of that. Because each commit and each comment in isolation isn't very valuable but they are very helpful in aggregate. I'm not sure why this bias exists though, since the same is true for lines of code. It's also true about a ton of things. All the little things add up. Just because it's little now doesn't mean it's not important
I once tutored an intern. Who thought he was The Best Programmer On Earth (didn't we all at that age?).
He refused to use revision control, it slowed him down.
So we told him to commit at least once every day, with a relevant commit message, or else fail his internship.
He worked 21 more days. There were 21 commits: "17:00, time to go home".
This reads like the intern was left to his own devices and his output not checked at all for three weeks straight. Actual tutoring would have surfaced the issue after 1 or 2 days tops.
I don't agree. These things actually matter. A developer who isn't told otherwise is just going to do whatever they feel like, so if there is nothing or no-one enforcing the standards, then the failure isn't on the individual developer, it is on the team lead. Someone needs to be setting the standards.
In the company I work for, there is a team that has isolated itself to some extent from other teams and works at a furious pace to keep their particular section of the business happy. We're lucky enough that they spun up their own repo to do their work on, so they don't actually impact other teams, but if the quality of the commit messages is anything to go by, I am 100% certain they're going to end up in a huge mess, if they aren't already. The team lead encourages this, and certainly doesn't care about commit messages etc.
Developers who care about other developers tend to write better quality code, because they care what other developers think of them. If you care about other developers, you will most likely write decent quality commit messages too.
I have seen over many years the types of developers who only care about moving their own code into production as fast as possible and getting to the next thing. There is a very high correlation with a mess at the end, which they inevitably won't have to tidy up because they'll be doing the next thing. These types of developers hate owning stuff in production, so they don't do it, so they don't actually care how maintainable their "clever" code is. I am very certain that a number of people reading this will be those types of developers.
Useless? So you never use “git annotate” or your IDE to see who wrote a line of code whose purpose puzzles you, and go to the commit message to see what they were trying to accomplish? This is invaluable to me as long as commit messages are clear.
As a manager, one of the first things I do is make sure that the PR titles (the PR text becomes the commit messages in squash-merging workflows) at minimum begin with a ticket number. Then we can later read both the intention and the commentary on it.
> you never use “git annotate” or your IDE to see who wrote a line of code whose purpose puzzles you, and go to the commit message to see what they were trying to accomplish? This is invaluable to me as long as commit messages are clear.
You're thinking like someone with a mature understanding of version control. Plenty of developers seem set on going their whole careers using git like beginners.
That sounds clever until you remember tools exist to solve actual problems.
Treating simple workflows as inferior is like saying a carpenter is amateurish for not using every attachment in the workshop. Some teams don't have enough upstream issues that they need to lean on git in the way you do maybe?
Think of a major FOSS project in a technically challenging domain. Every single one of them insists on proper version-control discipline. [0,1,2,3,4]
If enough of the following apply strongly enough to your project:
* Very small codebase
* A one-person project, or a very small team where everyone can be expected know the entire codebase and you don't bother with code-review
* Not doing anything technically challenging
* You don't care about the other advantages of disciplined version-control, such as the ability to meaningfully revert a commit, or to more easily associate a bug with a feature
then sure, you can get away with sloppy use of version control, or even no version control at all. The same applies to various other aspects of software development. Skillful structuring of code doesn't matter in a very small codebase. The drawbacks of dynamically typed languages aren't a real problem in small codebases. Documentation might not be worth writing up. The list goes on. It makes sense that there's generally less call for the various aspects of the 'craft' of software development in such projects. The same applies to other disciplines. You don't bother with CFD modelling for your paper airplane.
I'm not convinced there's really any upside to the sloppy approach though. Developers with the skill to write decent commit messages (plenty of developers lack this), and otherwise make skillful use of version control, tend to make it a habit and always apply the disciplined approach. It's like NASA's old rules for software: The rules act like the seat-belt in your car: initially they are perhaps a little uncomfortable, but after a while their use becomes second-nature and not using them becomes unimaginable. [5][6]
> Treating simple workflows as inferior is like saying a carpenter is amateurish for not using every attachment in the workshop
I see it differently: what I'm proposing is developing mastery over a core tool of the craft, and applying it consistently in our work. We'd expect the same from a competent carpenter or cook.
> Useless? So you never use “git annotate” or your IDE to see who wrote a line of code whose purpose puzzles you, and go to the commit message to see what they were trying to accomplish?
Personally no, the code is the "truth". If I need more I'm going to open a dialog with the author, not spend time trying to interpret a 7 word commit message, "good" or otherwise.
The code is the present truth, the commit messages can inform you about how it got turned into this truth. Interestingly, I recently wrote a short article about this: https://agateau.com/2026/on-commit-messages/
Your argument on conventional commits is something I've come to agree with. There are even tools that can generate release notes from conventional commits, and they are premised on the same mistake.
The code can only convey what is being done (and then, in some cases, only superficially). It can't convey what decisions were made, what alternatives were discarded, what business motivations may have led to that code.
And for old enough code, the author may not be available, or more likely doesn't remember.
Yes, we are on our third ticketing system on our team with dead refs to old issues. PR without a commit documenting why you need a change does not normally get approved and helps a lot also at present and future review time. Lots of value for new devs to see how thinking went and why something exist and not something else etc.
Documenting it also forces people to think why they are adding a change in the first place. Code added without purpose becomes dead weight and tech debt.
Look, I'll make this easy to understand. The parent comment that this stems from said:
> It can't convey what decisions were made, what alternatives were discarded, what business motivations may have led to that code.
If you're advocating this should all go in commit messages then I don't know what to say that I haven't already, it objectively doesn't belong there. The end.
Sure but code can't capture everything. Maybe with enough comments I guess, but not code alone. For example, code won't tell you that this feature was timeboxed hence this edgecase was not supported
You'll at least need the discipline to include the ticket ID in the message. Links to documentation are ok, but they will likely rot and even if they don't the content may change such that it no longer accurately reflects the commit changes.
I partially disagree. Technical leadership at the micro/mid level should be able to set and enforce standards like "you must have semi-meaningful or meaningful commit messages." If and only if they set those standards, and the team does not follow them, then we can say that either the leadership is lacking, or there is a structural barrier/disincentive to following the rules. Within that framework, I do think using process-smells like this is valid for judging technical leadership.
To the point of other commenters however, I wouldn't lay something this micro at the foot of the CTO in all but the smallest of organizations.
It's a stretch to lay at the CTOs feet, but not the team lead or even Head/VP of Engineering IMHO. It's also easy to "enforce" if you're already doing peer review (which you definitely should be, even if not required for compliance).
I am a CTO and I actually have very little patience for people that obsess over minor formatting issues (use a linter if you care), commit messages, and other fringe issues. If that's the biggest issue you have in a team, amazing. You are doing great. But you probably have bigger issues. The focus of the CTO is on the big picture stuff. Like staying on top of technical debt and correcting people when they keep on adding more of it. And making sure people learn from their mistakes, focus on the important things first, etc.
The thing with commit messages is that they are mostly never going to get a lot of scrutiny. But there are exceptions to this; especially if there are audits involved or external contributors. And of course when making a pull request to an OSS project, it is good form to make a bit of an effort. It depends on the context. I tend to focus more on diffs and pull requests. Not on the cryptic one liners that may or may not describe some of the changes. The right unit of change is a pull request, not individual commits.
And all this of course was when I was still able to keep on top of the massive volume of change. With AI that's simply no longer the case and the volume of change is only going to increase over time. Human reviews are now the main bottleneck to getting code merged. AIs probably should be doing a lot of the reviewing, gatekeeping testing, vetting, etc. Especially when AIs also produce most of the change. It's likely a lot of things will slip through unless you get your house in order on guard rails and process that your AI agents need to follow. As a CTO, guarding quality without becoming a human bottleneck is now the main challenge and removing bottlenecks responsibly is part of the job.
BTW. making AI tools write good commit messages is actually be a bit expensive. Many AI tools default to just summarizing the first message of a chat session under the assumption that just one thing changed over the course of a session. Making the AI look at the actual diff is of course possible and not that hard (just ask). And it definitely yields better descriptions when you do that. But it also takes more time and the token cost goes up as well. I'm not sure that's actually worth the expense in tokens. I tend to not bother with this. But again; depends on the context.
> The thing with commit messages is that they are mostly never going to get a lot of scrutiny. But there are exceptions to this; especially if there are audits involved or external contributors. And of course when making a pull request to an OSS project, it is good form to make a bit of an effort. It depends on the context. I tend to focus more on diffs and pull requests. Not on the cryptic one liners that may or may not describe some of the changes. The right unit of change is a pull request, not individual commits.
Why do you think OSS projects have a high bar for change descriptions? It's because some things matter for the long run.
Also, it's pretty clear from the context of this discussion that it's about the descriptions on pull requests (or other units of change like CLs) and not individual commits that get squashed in a PR/CL.
> BTW. making AI tools write good commit messages is actually be a bit expensive. Many AI tools default to just summarizing the first message of a chat session under the assumption that just one thing changed over the course of a session. Making the AI look at the actual diff is of course possible and not that hard (just ask). And it definitely yields better descriptions when you do that. But it also takes more time and the token cost goes up as well. I'm not sure that's actually worth the expense in tokens. I tend to not bother with this. But again; depends on the context.
All coding agents do that these days - they just run git diff and figure out what the change is when writing the commit message. Are you saying that writing a better change description is not worth the pennies it costs in tokens?
> The focus of the CTO is on the big picture stuff. Like staying on top of technical debt and correcting people when they keep on adding more of it. And making sure people learn from their mistakes, focus on the important things first, etc.
sound like something maybe good commit messages could help with
Obviously a very unpopular opinion, but I guess for my own sake it's hard to write commit messages, because for me it's that I have never really even found use of other people commit messages, and I rarely even attempt to. Ultimately code is code and I don't care about how it got to how it is. I got same issue with documentation and comments or really anything that isn't building stuff. I don't like writing it, don't like reading it either... ADHD?
So, before AI came and saved me from writing commit messages I had alias that ran the whole git add . && git commit -m ... && git push with a fixed commit message. But of course we had squashing so PR title was the one to eventually go there, so maybe that part is fine. But all my side projects had just that.
> Ultimately code is code and I don't care about how it got to how it is.
That's fine until you come up against something like a subscription system that's been built over 15 years by at least 20 different developers, none of whom are currently at the company, half of whom appear to have been clinically insane, each of whom had their own unique approach to code, with almost zero code commentary, zero external documentation, and abstractions layered like geological strata where you need 15 files open to understand one API endpoint.
As long as there’s some record, whether it’s PR or commit. At Google and Meta there’s no distinction, each commit is a PR (approximately) and has a description and discussion linked to it. I’ve found this really valuable for understanding a piece of code, maybe it’s just five lines but of there’s 200 words of discussion giving you more context on why it is that way.
Yeah I also don't really write commit messages. If your pull request becomes associated with that commit, and the history gets squashed, then that one commit becomes a link to the pull request where all the necessary info is. I just write "commit" for all my messages.
On my local copy of the repo, commits are notes to myself. I don't use the `--message` switch. I let git bring up my $EDITOR where I type what I did since the last commit. This helps when I'm writing the PR description and when I'm rebasing the branch on top of the main trunk. And then some time, I need to do a bit of git-fu and split the changes into different PRs. Hard to do this with generic messages.
But I use magit and I can commit specific lines and hunks as easily as files. That helps with managing changes to meaningfully group them.
In codebases where PRs are squashed on merge, the commit messages on the main branch end up being the PR body description text, and that's actually reviewed so tends to be much better I find.
And in every codebase I've been in charge of, each PR has one or more issue # linked which describe every possible antagonizing detail behind that work.
I understand this isn't inline with traditional git scm, but it's a very powerful workflow if you are OK with some hybridization.
It works until you migrate to a new system. In 5 years we are on our 3rd. I saw that at FAANG and startup alike. Then someone might dump the contents in JSON or just PDF for archival but much easier to have the commit msg have the relevant info - only relevant, losts of small details can be still on the issue and if someone really needs them can search those archives.
I personally find this to be a substantially better pattern. That squashed commit also becomes the entire changeset - so from a code archeology perspective it becomes much easier to understand what and why. Especially if you have a team culture that values specific PRs that don’t include unrelated changes. I also find it thoroughly helpful to be able to see the PR discussions since the link is in the commit message.
I agree, much as it's a loss for git as a distributed system (though I think that ship sailed long ago regardless). As far as unrelated changes, I've been finding that another good LLM use-case. Like hey Claude pull this PR <link> and break it up into three new branches that individually incorporate changes A, B, and C, and will cleanly merge in that order.
One minor nuisance that can come up with GitHub in particular when using a short reference like #123 is that that link breaks if the repo is forked or merged into something else. For that reason, I try to give full-url references at least when I'm manually inserting them, and I wish GitHub would do the same. Or perhaps add some hidden metadata to the merge commit saying "hey btw that #123 refers to <https://github.com/fancy-org/omg-project/issues/123>"
Yep - we do exactly the same with Claude. In fact - part of our PR review automation with Claude includes checking whether the PR is tightly scoped or should be split apart. I’d say in about 80% of the cases the Claude review bot is accurate in its assessment to break it up? It’s optional feedback but useful - especially when we get contributors outside our immediate team that maybe don’t know our PR norms and the kinds of things we typically aim for.
Yeah I usually default to just a straight up link or a markdown link. Mostly because I usually don’t know the exact number of a PR/ticket/issue - so it’s easy to just copy the URL once I’ve found it.
I've seen it be the concatenated individual git commit messages way too often. Just a full screen scroll of "my hands are writing letters" and "afkifrj". Still better than if we had those commits individually of course, but dear god.
The gold standard is rebased linear unsquashed history with literary commits, but I'll take merged and squashed PR commits with sensible commit messages without complaint.
And in a squash and merge workflow, which are most teams I've been on the past 8 years, it really is the title of the pull request or merge request. That is what really matters.
And I really like that because it leaves room to let the developer do whatever kind of commit messages they want to that makes sense to them. Because nobody's really ever going to read those again after it squashed and merged.
Every time I hear about commit messages on HN, this is my first thought. I can't imagine not working in a squash workflow. No matter how good your commit messages are, I do not want to read all of them. The squashed commit will direct me to the original PR in case I need more detail.
Totally agree. One thing I really like about HN is it reminds you that nobody's individual experience is indicative of the industry at large.
The parent comment stated "Most codebases I encounter just have "changed stuff" or "hope this works now"." I worked at 6 tech companies in my career and a slew of contracting gigs, and I literally never encountered the problem of commit messages being uninformative. Most of the companies developed strict rules for commit comments like always including an issue number (with occasional [NO-ISSUE] tags allowed for minor changes) or something like Conventional Commits, https://www.conventionalcommits.org/en/v1.0.0/ .
Only two of the five depend on commit messages. Churn, authorship, and velocity work regardless. Even teams with terrible hygiene write "fix" when something breaks.
Is it really a small minority? I have never worked on a project that didn't have commit messages that at least tried to be descriptive (sometimes people fail at it but its very different to an outright "changed stuff").
I don't remember any friend mentioning to me them encountering a work project where the messages were totally neglected either.
Never seen that in any company I worked at either and I can’t believe professional developers seem to think that it would be ok to write meaningless commit messages. That’s just so sloppy.
When your boss looks only at the business output and your most prolific developer writes "save" for commit messages, it gets real hard to enforce a commit message policy. "It's hard to review"? Your boss doesn't care about that and it slows the 10x guy down. These days I just run an LLM on the commits to annotate them (via git notes) based on context.
We have a hard division between "Core" repos (those which are deployed to production / customer sites) and everything else. The expectation in Core repos is that everything goes through a PR process where the pull request message is intended to explain the what and why of the change (perhaps with reference to a ticket, but with the key information restated in the PR), and goes through a review just like the code. Changes are then either squashed with that as the commit message or (if they're larger and benefit from a clear separation of commits), may be rebased with `git rebase -i` assuming the final PR body ends up in one of the commit messages.
Non-Core repos are absolute free-form anything goes. You can commit 8 times a day without a PR as long as you're not deploying to production. This is excellent for things like test harnesses, CI/CD nonsense, one-off experiments, demos, prototypes, etc.
My last Core commit had something like 20 to 1 ratio between lines of commit message to lines of code (small change touching something deep that required a lot of explanation). My last non-Core commit message was "hope this works" (it did not).
Our small team has a lot of commit messages like this. For a while, we had a guy on the team who had come from a site that expected more. The pet peeve he brought along was that commit messages end with a period (my guess is that someone at their previous work place had reasoned that forcing periods encouraged developers to actually write meaningful sentences). When I look at that period of development, I see lots of messages like “stuff changed.” And “more stuff changed.” And then it goes back to just “stuff changed” around the time they moved on.
> my guess is that someone at their previous work place had reasoned that forcing periods encouraged developers to actually write meaningful sentences
I have actually seen proper capitalization and correct conventional-commit types to correlate very well with the author being intentional and the patch being of good quality.
e.g.
- (a) chore: update some_module to include new_func
- (b) feat: Add new_func to handle XYZ case
Where:
(a) is not a chore, as it changes functionality, is uncapitalized and is so low-signal I can probably write a 10 line script to reliably generate similar titles.
(b) is using the correct "feat" commit type, capitalized and describe what this is for. I expect the body to explain "why", as well, and not to reiterate the "how" in natural language.
This is just my experience, but I've seen commit messages where people actually put in some effort to usually come with a good patch, and vice-versa.
One big problem about commit messages is, that you write them from your perspective. If you write them while activly engaged with the topic and changes you are very heavily biased and might miss things which are obvious to you but not to future readers with less knowledge. I think abstracting your personal opinion is quite hard - I agree that LLMs are perfectly fitting for writing this since they just dont have a "personal opinion". Atleast I made the mistake in the past many times focusing on the things which were not obvious to me but then leaving out the non obvious things for others.
> Most codebases I encounter just have "changed stuff" or "hope this works now".
I have been told off several times at different jobs for writing commit messages that are "too big". Also for writing too much commentary in my code changes. Also also for complaining that other people aren't doing these things.
(Not that it stops me, mind, but it does make working relationships fractious.)
I also like meaningful commit names. But am sometimes guilty of “hope this works now” commits, but they always follow a first fix that it turns out didn’t cut it.
I work on a lot of 2D system, and the only way to debug is often to plot 1000s of results and visually check it behaves as expected. Sometimes I will fix an issue, look at the results, and it seems resolved (was present is say 100 cases) only to realize that actually there are still 5 cases where it is still present. Sure I could amend the last commit, but I actually keep it as a trace of “careful this first version mostly did the job but actually not quite”
Many organizations squash their commit messages from PR, where most commits actually happen. Unless everyone is committing to trunk all the time, which almost never happens on a real job, I highly doubt the value of this.
Showing my Git ignorance here, of course - does "ancestors(trunk)" pull in all the commit messages?
Only two of the five insights are based on commit messages and the author acknowledges that they won't work in projects without message discipline. But the remaining ones will give you valuable insights even into the most lazy project department.
tbh I'm not convinced that a git log history should be treated as a group journal because it's not.
relying on git commit messages assumes they're correct by convention since there is no technical constraint to enforce it. and it assumes no work in progress commits, sometimes it's just necessary to hit the save button real quick or move a workspace from one device to another.
my point is:
git is a way of storing and loading files at its core.
It's because the vast majority of commit messages are never read by anyone, and there's other ways to fund out what happened in the handful of cases where you would need to.
I read commit messages all the time to figure out what a change was about.
For small personal projects I often write one phrase messages with `-m`, but if you're working with other people you should be writing good commit messages.
The thing is, falling down (ie. failing at things) can take a lot out of you, physically, mentally, financially, spiritually.
For most of us, taking calculated risks is better than simply taking more risks.
And the risk calculation changes based on your personal circumstances: physically falling has a greater impact on an old person than a young person, making a financial mistake has a greater impact on someone who has no savings than someone who is wealthy, etc.
So "let yourself fall down more" isn't really one size fits all advice.
I did some napkin math the other day, and my kids at half my size prob hit the ground with 1/2 the stress that I do. Certainly could take more risks falling with a 50% reduction in harm. The extra rotational energy from 70" vs 40" will do it.
I am sure IRC was good for some people, but I can say for me personally it was a net negative and real life was so, so much better. I wish I never used IRC.
I also personally witnessed multiple friends who dropped out of college due to IRC addiction in the early 1990s.
I am curious if anyone else has a similar memory of IRC.
QuakeNet in the 90s, I don't know what to say, thank you? It was high school for me, like, I got through high school, got into computers in high school, have great memories of that time: because of QuakeNet in the 90s. hackernews community is the closest things I've felt to that since then, but it's pretty hard to beat QuakenNet in the 90s.
Depends a lot on where you were growing up, and what kind of community surrounded you. For me IRC and the internet at large was a salvation, but the 90s in my country of origin were... interesting times. Being on the internet was much healthier and much less hazardous than most of the things real life focused people in my age group were doing back then.
There are people on IRC who I've maintained contact with for longer than anyone I can think of off the top of my head aside from family members. Many now through other channels (thanks to the Discord wrecking ball), though some still on IRC.
Hard to say how many intellectual rabbit holes I've gone down as a result.
I can say for sure life would have looked very, very different without it.
> I also personally witnessed multiple friends who dropped out of college due to IRC addiction in the early 1990s.
I think there's always a segment of any population that will get addicted to anything, to the point of dropping family, friends, school, or work. Blame it on culture, nurture, genetics, unfulfillment, or simply lack of self control, but it always happens.
Blaming IRC, which is a pretty neutral outlet, is unfair. This is specially true today, as we have things designed and constantly honed to be as addictive as possible.
Even though I really like irc because I can get answers really quickly from helpful people but it's a net negative I have felt if you linger on and listen to people conversing. IRC is good for short help needs but if you spend lot of time then it's net negative. I feel for the helpful ppl on various irc channels who are there to help out of their own goodness. They must be having a lot of net negative
It's not too bad after some (a lot of) adjustments, but I agree the problem is that the default is that notifications are on. I'm part of more than a dozen Discord servers, and only three of them have notifications enabled, and one of those are basically dead. If I joint a new one, the first thing I do is mute it, and then I'll maybe unmute it if I'm actually active in there (or if it's a large server, I'll unmute the specific channels I care about and mute everything else).
I have email notifications on, but I actually read the few newsletters I get, and I barely get any mail beyond that. Meanwhile, everybody else I see has 4000 unread emails and the vast majority are unread rubbish that they could have unsubscribed to 700 emails ago, or just never subscribed to to begin with, but I guess signing up for that shit is just the default now.
I go even further: I only use the website. If I want to add or modify something, I go to my profile and do it. I only used 2 social network apps, and they are mostly for news and to check on tech people I follow.
My wife's phone, is just full of noise. Notifications, messages, email ... some folks just want to be in front of a fire hose of crap... I don't know why.
He's not "obligated" to do anything but it's still immoral to abandon maintenence of something like that. If he can't be bothered to maintain it, then he should delete it.
I don’t know if the allegations against Jon Pretty were valid or not, but those who piled on against him can’t escape accountability for mob behavior (assuming Pretty was innocent) if it becomes embarrassing. At most they can say “I supported this but no longer do”, not expunge all traces.
> If he can't be bothered to maintain it, then he should delete it.
Not necessarily, plenty of projects have been put in an archive state because they are 'finished', superseded, forked, etc. This isn't code nor a living document, it was a one-off operation.
> He's not "obligated" to do anything but it's still immoral to abandon maintenence of something like that. If he can't be bothered to maintain it, then he should delete it.
Morality is subjective (that's why we have courts; which don't respect the individual and differing moralities of the parties involved, it has its own moral bar, for better or worse).
In this case, I feel it is more moral to record all the members of the mob. Maybe this would cause them to think twice before joining the next mob.
I mean, if we are going to have witch-hunt mobs, then the lesser evil is to not allow anonymous mobbers.
The first was that 123456 was the credentials for the admin panel.
The second was an insecure direct object reference, where the lead_id querystring parameter can be changed on an API call to retrieve another applicant's data.
> It sounds like there were two separate problems:
> The first was that 123456 was the credentials for the admin panel.
No. 123456 was the credentials for the test setup, which contained nothing. But you could use the IDOR to access data from the test setup.
If 123456 had been the credentials to the admin panel, there would have been no point in exploiting an IDOR - as an admin, you can just look at whatever you want.
Using numeric IDs on an outward facing object is, for the most part, totally fine. It's a serious tradeoff to ditch the nice properties of numerical IDs and the legibility they provide in order to cargo-cult a "we must reveal nothing" approach, as you would here via UUID. It also misses the point of the actual security lesson: no matter the identifier, you need to be applying access controls to your data. Even if your UUIDs were generated via 100% airtight cryptographically random sources, you have to, y'know, communicate with them. That means you'll probably leak them, expose them, or other folks will collect them (often incidentally via things like system logs). If all it takes to gain access to a thing is knowing the identifier of that thing, you've blown it in a huge way. Don't stress about the theoretical benefits of something like an opaque identifier and then completely neglect the necessary real world access control.
Can you tell I've been scarred by discussing designs with folks who focus on the "visible" problems without thinking about the fundamental question of "is this secure"?
> If all it takes to gain access to a thing is knowing the identifier of that thing, you've blown it in a huge way.
Defense in depth is a thing, so even if you make a mistake in one place, and the attacker gets complete access - as what happened with the McApplicaton here - they won't be able to download your entire db within minutes. Even with zero authentication, non-guessable identifiers will slow down the exfiltration by several factors from dozens/hundreds of records per second to one record per $MANY_DAYS, with lots of 404s for the defenders to look at.
> That means you'll probably leak them, expose them, or other folks will collect them (often incidentally via things like system logs)
The additional friction of acquiring the UUIDs from a different channel is beneficial to defenders, compared to decrementing or incrementing IDs, which is trivial to do, and doesn't need RCE. It's the difference between "All users' data was exfiltrated" and "Only a couple/handful of accounts were affected", and this can make or break the breached company.
I think I disagree with "totally fine"... Even if that were true though, this case is definitely a point where you wouldn't want to give away information with a numeric ID. Giving away # of applications/growth of that over time is definitely business information that arguably should not be discernible.
The point is not that UUIDs are magically secure, it's that they mean nothing to whoever gains access except a single job app. The assumption is that they will get out (they're in a public URL), and that they will have no meaning when they do.
It's a defense-in-depth thing IMO -- cargo-culting this approach defends you even when you don't do the other things right. It's simple -- with a non-zero probability that the actual access control is faulty, do you want a default that protects you or doesn't. What's the intentional trade we're going for? More DB perf? Easier to type URLs? There are other ways to deal with those
> Can you tell I've been scarred by discussing designs with folks who focus on the "visible" problems without thinking about the fundamental question of "is this secure"?
Ok, this is probably a stupid, very bad, no good idea considering I've not heard of people doing this, but can't you retain many of the benefits of numerical IDs but also the secrecy of UUIDs by using an HMAC ?
With HMAC, you can still ask for some sequential IDs
SipHash128(0, KEY) = k_0
SipHash128(1, KEY) = k_1
You get the same number of bits as a UUID.
You can't, however, sort by IDs to get their insertion sequence, however. For that you'd need something like symmetric encryption but this is already a bad idea, no reason to make it worse.
You are both right. UUIDs, if randomly generated from a CSPRNG are impossible to guess. But not all UUIDs are generated from a secure RNG, or use randomness at all.
UUIDv4 may or may not use a cryptographically secure random number generator. Python's UUID library, for example, falls back to the insecure 'random' module. Given a handful of outputs, it's possible to predict future ones.
For python specifically, the uuid4 function does use the randomness from os.urandom, which is supposed to be cryptographically random on most platforms.
Yeah, Python went through a big shakeup around secure randomness when they put together the "secrets" library, around a decade ago. A lot of that also got backported on most OSs.
So there really shouldn't be anyone using that today, thankfully.
Gasp! I had no idea about the Python implementation. Not that I do anything where it would matter (just need a random id), but for an already slow language, I would prefer the safer default.
Yes, you are technically right -- I should have said "functionally impossible". It's not actually impossible, but close enough for the average random onlooker.
> During a cursory security review of a few hours, we identified two serious issues: the McHire administration interface for restaurant owners accepted the default credentials 123456:123456, and an insecure direct object reference (IDOR) on an internal API allowed us to access any contacts and chats we wanted. Together they allowed us and anyone else with a McHire account and access to any inbox to retrieve the personal data of more than 64 million applicants.
As an LP, I would be excited for liquidity in 10 years at this point.
It seems like even for successful companies, there isn't a clear path to an exit for many of them. Add to that the increase in late-stage investors, and there isn't much of an incentive to exit.
A bit hyperbolic but yeah. It also depends on the industry / stage. I’m always looking for creative ways to get liquidity out given the exit issues you mention.
All joking aside, it really is a chronic problem in the corporate world. Most codebases I encounter just have "changed stuff" or "hope this works now".
It's a small minority of developers (myself included) who consider the git commit log to be important enough to spend time writing something meaningful.
AI generated commit messages helps this a lot, if developers would actually use it (I hope they will).
reply