Programming

17432 readers

251 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 1 year ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

MaungaHikoi@lemmy.nz

Unsigned Commits (blog.glyph.im)

submitted 9 months ago by AnActOfCreation@programming.dev to c/programming@programming.dev

25 comments fedilink hide all child comments

I'm curious to hear what the Lemmy programming community thinks of this!

The author argues against signing Git commits, stating that it adds unnecessary complexity to systems.
The author believes that signing commits perpetuates an engineering culture of blindly adopting complex tools.
The consequences of signing Git commits are likely to be subtle and not as dramatic as some may believe.

Archive link: https://archive.ph/vjDeK

you are viewing a single comment's thread
view the rest of the comments

[–] AMDmi3@lemmy.world 5 points 9 months ago (1 children)

Agreed, and I have more arguments against commit signing.

Commit immutability is undesirable, and mutable commits are not compatible with signing. For instance, pull requests are squashed and rebased to keep linear history, and changes are cherry picked around. It does not change authorship, however it changes hashes and invalidates any signatures. Or, say, one wants to adopt an otherwise FOSS project which though contains some copyrighted material in its repository, which needs to be filter-branched away, again invalidating the signatures.
In our world where stuff randomly gets criminalized I prefer to avoid being undeniably linked to my code.

BTW this topic has common considerations with now mandatory (on GH and more places) 2FA. For the latter reason, and also for own convenience and for reducing risk of losing access to your account (which I assess as much higher than risk of leaking my password to third parties) I make second factor public, effectively reverting to 1FA.

[–] Mikina@programming.dev 3 points 9 months ago

I make second factor public, effectively reverting to 1FA.

I work as a Red Teamer, and I heavily disagree with this approach. MFA has been a bane of so many engagements. We usually end up with a lot of credentials from the target company that we can't really use for anything (unless you already are in the network, where some of Windows services don't require it), because each one is under MFA.

There's so many different ways how can you solve the problem of not loosing access to you account. Make offline back-ups of recovery keys, back up your Aegis vault to different places.

Also, you may have a pretty good level of security awarness, highly reducing the risk of any kind of breach happening to you. But that's something you can only affect to a degree. Supply chain attacks happen, zero days happen. An extension you are using in your browser may get compromised, and someone pushes a info-stealer instead (which has already happened, i.e with Nano Defender). MFA is what will help you in cases like these.