41–50 of 323 posts
"pip" has a usability problem. It should do a lot more at preventing this kind of thing. When using pip, it's not easy to tell information like the release date, how many versions have been released, and so on. Since such info is available from PyPI API, I wrote my own "pypisearch" script to sort by latest release date and include number of releases to weed out packages that seem useful but are old or rarely released…
> The first is "python3-dateutil," which imitated the popular "dateutil" library. The second is "jeIlyfish" (the first L is an I), which mimicked the "jellyfish" library.
Wish they listed out how many installs.
Maybe ash keys and got keys need to be protected from access by anything local unless given permission? Right now they are just files sitting there that can be read by any standard user process right?
Ok macOS you can easily throw your SSH keys into the secure Keychain (not that I do this...).
Windows and Linux need to get with the times.
My dev env should be sandboxed like everything else. Git can have ssh permissions but not every random tool from pip or the ceasepool that is npm.
Software repositories without a human review process are a bloody stupid idea.
There are probably several open-source projects that you can download today that include unknown malicious code. But they will be discovered eventually. Proprietary software, on the other hand, can keep malicious code during their entire life of relevancy. And in fact, it's rare for proprietary software to not have malicious code these days, with personal data being sent to servers, ads being delivered, and installer…
I don't know what the solution is but it feels like this is a much bigger issue and we need some rethinking of how OSes work by default. Apple has taken some steps it seems the last 2 MacOS updates where they block access to certain folders for lots of executables until the user specifically gives that permission. Unfortunately for things like python the permission is granted to the Terminal app so once given, all pr…
This is literally what SELinux does, and has been able to do for years. We don't need "default block lists" - we need solid SELinux policy in all distros.
Things today:
- Protective monitoring. If it's stealing your key, it's presumably sending it somewhere, so somebody alerting should be going off asking clients are calling something external.
- Peer review. Maybe its about time we question whether we should actually be running so many random modules without actually vendoring and reading the code.
- Subscribing to security lists, so the people who actually do the above stop you from using dirty modules.
- Yubikeys, etc.
Things in the future:
- New home directory model. I believe systemd crew are looking into this, so I imagine it'll be hated, even if it does help solve similar issues.
- Newer distro models such as fedora silverblue where every process is isolated. I believe this currently mounts your home directory though, so maybe wouldn't work.
- New FS layout. Putting .ssh keys in something like .secret/ssh would likely make it easier to not mount secrets into isolated processes and help MACs too.
That solution also has the benefit of allowing you to call a package from any language from your language of choice.
I highly recommnend reading their the article introducing the idea, its very convincing:
[0] https://bytecodealliance.org/articles/announcing-the-bytecod...
What's the best information source for me to follow to keep up to date on these kinds of library vulnerabilities? I would make a feed of the homepages for all the libraries I know I use, but that won't help me with the libraries I use without knowing.
[safety](https://pyup.io/safety/) is a commercial product that monitors your dependencies for this kind of shenanigans
LGTM.com seemed to be working in this area - Semmle was acquired by github/microsoft
"pip" has a usability problem. It should do a lot more at preventing this kind of thing. When using pip, it's not easy to tell information like the release date, how many versions have been released, and so on. Since such info is available from PyPI API, I wrote my own "pypisearch" script to sort by latest release date and include number of releases to weed out packages that seem useful but are old or rarely released…
Is the code public? I'd love to use something like that.
Anyone here not encrypting their private keys? Also known_hosts file is a double edged sword. It's pretty sensitive in combination with a private key.