• 62 Posts
  • 124 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2025

help-circle

  • The blog post lays it out pretty well.

    The vulnerability of SHA-1 is that it’s possible for an attacker to find colliding hashes. But that’s not really an attack vector, because it’s not like they can find aatching hash for just ANY input. In order to pull off an attack, using a hash collision, an attacker would have to already be trusted within the controlling system, in which case they can do a hell of a lot worse than swapping out a file.

    Like you say, the hash is used as a lookup key within the git repo’s database. The requirement for that is uniqueness, which SHA-1 still fulfills just fine. The trust isn’t in the database lookup, the trust is in the systems that controls access to and distribution of that database.

    As the article points out, Linus Torvalds himself said as much in 2005, when he first wrote git:

    I really think people should not consider the sha1 the “security”. The real security is in distribution.


  • There’s people who seriously think commit hashes are there for security purposes? Furthermore, there are git MAINTAINERS that think this?

    How absurd. Author is completely right, making SHA-256 the default implementation serves no purpose. SHA-1 is a completely valid algorithm for non-security use cases, which is precisely how git uses it. This is a solution looking for a problem.

    I think he’s maybe overblowing the impact of this change. Realistically, the only ones who are going to be impacted are the folks who maintain git-related tools and forges, as he mentions. The rest of us probably won’t even notice. But that’s still a ton of pointless work for those folks.








  • Anecdotally, from a programming support community I hang out in…

    i’ve never seen anyone promote the values of Clean Architecture in the practical world. The only reason I even know about it, really, is because it’s a pretty popular topic for amateur/beginner developers to come in and ask about, because they read a book or a blog article about it, or are being taught about it in a class. And the response is always, universally, “Don’t use Clean Architecture, use Vertical Slice Architecture.”

    I get the vibe that it’s been popularized in the same pattern as microservices or lambda functions: someone at a super-scaled company like Google or Amazon published a blog post about it, and how it works for them for some niche scenario, and everyone latched on to it as trendy, despite the fact that their scenarios are NOTHING alike








  • Do you think you are being overworked compared to the industry standard (from experience or vibes) ?

    Hell no. I don’t have personal experience, but I read enough social media from other software devs to know I’ve got it pretty good.

    What are your responsibilities ?

    I’m the de-facto UI guy on the team, and also kinda the team lead’s go-to debugger for PROD issues. But we all do at least a little bit of everything. Really, we’re all considered “responsible” for the systems/features we’ve built personally, in that if an issue comes up on something I built, the team lead comed to me first about it. Usually.

    Do you do application deployments ?

    Not directly. The main server guy does the actual work of building the deployment artifacts and copying them up to the server, while the main database guy does the same for all database artifacts, including assembling migrations scripts.

    But our monthly scheduled deployments are a full-team affair. We’re all on a call together, and we’re all testing the stuff we worked on to make sure it deployed properly, and on occasion when something goes wrong, we’re whipping up a hotfix on the spot.

    What does the ownership look like in your compan. Do devs own everything and perform all tasks for the application to function? ( server management, server user profile management, application hosting, etc )

    I touched on it a little above, but there’s definitely roles, although the lines are blurry.

    One guy does all the server maintenance stuff, that falls through the server provider’s responsibilities. He also is the de-facto lead of our auth systems.

    One guy is the de-facto database lead. He does almost all of our ETL-related work, and often will be the first prototyper of new features or new workloads, by just playing around with data in the database and figuring out how to properly map it into what users want to see.

    One gal is our de-facto quality control. Generally, she does a secondary review of every change that gets merged, to check for regressions and such. This is particularly useful when multiple people end up working on changes to the same feature or system, and don’t necessarily coordinate with each other.

    Me, I mentioned, I’m the de-facto lead for UI, as I’m the one who spearheaded the effort to get us using TypeScript, and wrote almost all of our TypeScript “framework”.

    One guy is, I guess you could say, the de-facto lead for all our legacy features, that still run on jQuery and CSLA, and other nonsense. And we have a lot of those.

    The last guy doesn’t really have any AREA that I’d say he’s a lead for, simply because he’s not been around long enough to really build onele. He’s cranked out quite a few big features, and would definitely be considered a lead on those.

    Do you work off hours ?

    VERY rarely.

    Do you make the industry standard or are you paid less ?

    Don’t really know, honestly. Probably a bit under. I’m at like 110k/year, I think? In a relatively-low-cost-of-living area.