Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Dear Author/Maintainer,

Why do you even accept giant patches which you can’t review?!



It's a good question to ask, although in the case of this project, there don't seem to be any merged code reviews with large line diffs?


Makes the story even murkier.

I don’t know what happened there, but the issue linked sets off so many alarm bells that all I want is to run away.


I think the issue in the repo explains it pretty well: the maintainer's machines were compromised, meaning that any commit under his name could have come from an attacker. It doesn't matter how big or small the diffs are when the person in control of the repo is malicious. Even signed commits would not be safe from this unless he was using a physical signing key (e.g. a yubikey)


Perhaps I'm sorta nitpicking or being overly annoying by pointing this out, but use of a Yubikey wouldn't necessarily help if a malicious process modified the code to be submitted. They'd be signed-but-corrupted commits.

The best safety net I'm aware of is that source code and/or diffs in plaintext (not binaries) are distributed, and that recipients inspect them.

It's reasonable to distribute binaries in addition, although recipients take on risk by using those. That risk can be mitigated in the presence of source code and reproducible builds.


Despite my unbounded sense of optimism about everything in life, something makes me think there might be more situations like this ahead (it's a sign that software is being written and distributed more widely, which is good - and a sign that running tons of arbitrary code on all our machines and internetworking them all might lead to difficult-to-answer questions around compromise).

So to harness that optimism again: it's a challenge and an opportunity to build the correct collaboration and analytical tools to audit codebases quickly and effectively in a distributed environment.


My interpretation was that the author meant "even if we tried to review all changes between current HEAD and the last known-safe commit, it would be difficult if there were large commits (e.g. a giant refactor.)"


Then just fuck it, reset to last known good commit and work from there. If a contributor gives a shit about their PR, they will resubmit it again. If not, good riddance. If something has to be reimplemented again, it's usually way better the second time around anyway.


Okay, if the account has been compromised: why don’t you keep a known-good offsite backup?


[flagged]


Or just don't accept large patches, tell authors to split them into nice commits, and have others review it with you.

The people who'll complain about "gatekeeping" (if any) are likely not contributors you'd want, anyways.




Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: