Backdoor in ssh-decorator package
reddit.com
Backdoor in ssh-decorator package
1–10 of 15 posts
Re: Backdoor in ssh-decorator package
#2That is such a dick move. There should be a blacklist of people that pull these kinds of stunts. I understand that blacklists aren't Sybil resistant but they're better than nothing. At the very least the scum would have to rebuild their reputation.
Re: Backdoor in ssh-decorator package
#3That is such a dick move. There should be a blacklist of people that pull these kinds of stunts. I understand that blacklists aren't Sybil resistant but they're better than nothing. At the very least the scum would have to rebuild their reputation.
It's very easy to change identities online. That's why throwaway accounts are a thing... If you start trying to ban based on IP, then you're in the cat/mouse game that IRC folks have been fighting for decades.
Re: Backdoor in ssh-decorator package
#4Two questions:
1) can paramiko.RSAKey handle other encryption schemes (ED25519) ? If not, folks using non-RSA keys wouldn't be affected..
2) Having a (strong) passphrase for your key file would help prevent the perp from doing any harm with the key(s), or at the very least would give you time to invalidate the key(s). Right?
Re: Backdoor in ssh-decorator package
#5That is such a dick move. There should be a blacklist of people that pull these kinds of stunts. I understand that blacklists aren't Sybil resistant but they're better than nothing. At the very least the scum would have to rebuild their reputation.
It's very easy to change identities online. That's why throwaway accounts are a thing... If you start trying to ban based on IP, then you're in the cat/mouse game that IRC folks have been fighting for decades.
You can solve this though a few user interaction metrics. I'm not active on hacker news thus I don't have privileges (karma) to down vote. A brand new account shouldn't be allowed to make a change such as this, getting enough reputation should require active involvement and code review of changes before they are accepted. Just as my karma can drop, people should lose privileges. That this is sensitive piece having high security requirements means that bar can be even higher requiring years of involvement before unverified commits can occur.
Re: Backdoor in ssh-decorator package
#6That is such a dick move. There should be a blacklist of people that pull these kinds of stunts. I understand that blacklists aren't Sybil resistant but they're better than nothing. At the very least the scum would have to rebuild their reputation.
Why not a whitelist of users who can make changes to code flagged as security sensitive (or more specifically: security-authentication)?
Edit: digging through Reddit comments more suggests the repo owner may have been hacked as commit blame shows his user made the changes. In this case: a Blacklist wouldn't help and my suggestion may already be in place.
Re: Backdoor in ssh-decorator package
#7The solution to the impersonation aspect of this is commit signing. It is literally built into Git. There are no good excuses for project maintainers to not sign commits at this point. Grab a yubikey or other gnupg smartcard and do it. Else someone is going to impersonate you and use your name, reputation, and repos to spread malware like this. Have your git hosting provider refuse unsigned commits (github/gitlab allow this).
Secondly stop trusting pip/pypi. You -can- upload gpg package signatures but clients totally ignore them. There is no way to verify the author of a pip package except by hand today.
Let me be really clear here. When you install a pip package you are executing arbitrary code from the internet with unknown authorship.
Pip is fundamentally broken until signature validation is implemented. Whenever possible use OS package managers like apt which actually verify authorship and integrity.
Re: Backdoor in ssh-decorator package
#8That is such a dick move. There should be a blacklist of people that pull these kinds of stunts. I understand that blacklists aren't Sybil resistant but they're better than nothing. At the very least the scum would have to rebuild their reputation.
Why not a whitelist of users who can make changes to code flagged as security sensitive (or more specifically: security-authentication)? Edit: digging through Reddit comments more suggests the repo owner may have been hacked as commit blame shows his user made the changes. In this case: a Blacklist wouldn't help and my suggestion may already be in place.
It doesn't matter if it's "security sensitive" or not. Any compromised package can steal your secrets.
Re: Backdoor in ssh-decorator package
#9Re: Backdoor in ssh-decorator package
#10The solution to the impersonation aspect of this is commit signing. It is literally built into Git. There are no good excuses for project maintainers to not sign commits at this point. Grab a yubikey or other gnupg smartcard and do it. Else someone is going to impersonate you and use your name, reputation, and repos to spread malware like this. Have your git hosting provider refuse unsigned commits (github/gitlab all…
I only sign git tags and releases.
I don't sign git commits, because it's supper annoying, especially when rebasing large number of commits.
Package signing and verification works for distros, because significant effort is spent on curating keyrings of trusted keys. (And even that isn't foolproof! See https://bugs.debian.org/842939 for the latest example.)
It's not clear how automatic signature verification could work for pip. Who's going to decide which keys are trusted?