
Backdoor in ssh-decorator package - jbfoo
https://www.reddit.com/r/Python/comments/8hvzja/backdoor_in_sshdecorator_package/
======
lrvick
The 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.

~~~
jwilk
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](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?

------
amingilani
That 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.

~~~
craftyguy
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.

~~~
Forge36
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.

------
jwilk
Maintainer's response:

[https://webcache.googleusercontent.com/search?q=cache:vjUIkP...](https://webcache.googleusercontent.com/search?q=cache:vjUIkPX1-0EJ:https://github.com/urigoren/ssh_decorator/issues/11%2B%22ssh-
decorate.cf%22)

[https://github.com/pypa/warehouse/issues/3896#issuecomment-3...](https://github.com/pypa/warehouse/issues/3896#issuecomment-387184492)

~~~
jlgaddis
It seems there's no way to be 100% certain whether the maintainer ( _urigoren_
) is a victim or the perpetrator in this case.

------
parliament32
The module starts with "import requests" which should be a red flag even for a
cause skim of the source. The "it's open source, I'm sure someone else read
over it" excuse only works when the code is popular enough... and some obscure
pip package definitely isn't.

The author of the package claims to be a "victim" here, but it's hard to tell.
Too bad pip doesn't support package signing.

------
craftyguy
Two 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?

