by xrstf on 6/8/16, 1:45 PM with 143 comments
by wbond on 6/8/16, 3:58 PM
My hope is to be automating a large amount of the review in the next few months, however I think this is a good argument for never having it be fully automatic. Having a human sanity check submissions isn't a terrible idea if we can keep the workload down.
Certainly this doesn't prevent a malicious author from posting a legitimate package and then changing the contents to be malicious, but that can be somewhat solved by turning off automatic updates.
by Mahn on 6/8/16, 3:56 PM
http://incolumitas.com/data/thesis.pdf section 5 "Practical implications". Just wanted to point out that in case you skipped it it's worth a read, some interesting proposals there that are worth discussing with package manager maintainers.
I particularly like the preemptive approach of auto-blacklisting common typos by simply monitoring the number of times a specific unexisting package is requested over time (5.10). So if a lot of people regularly attempt to install the unexisting package "reqeusts", it could signal that it's a common typo and should be blacklisted to prevent malicious use in the future. False positives could always be sorted out manually by communicating with the package manager maintainers.
by zeveb on 6/8/16, 3:01 PM
I think that this clearly falls under the heading 'naming issue.' People know what they want, but do not enter it properly.
I can't think of a 100% off-hand, which isn't surprising, because it's a hard problem.
pmontra's suggestion to use typo blacklisting ain't a bad idea. Maybe some sort of reputation-per-name could help?
by szx on 6/8/16, 3:29 PM
It's pretty mind blowing how big of a blindspot package installers are. I guess running everything inside a e.g. Docker container/VM would be a partial interim solution for the paranoid?
by eudox on 6/8/16, 3:00 PM
It does raise the barrier to entry, but it would prevent typosquatting and regular namesquatting.
EDIT: Does any major package manager provide a "did you mean" functionality, offering a list of actual package names similar to what you typed?
by baby on 6/8/16, 3:21 PM
by pmontra on 6/8/16, 2:47 PM
by Mizza on 6/8/16, 3:22 PM
Also, doesn't point out that the bigger threat is that this is wormable.
by PeterisP on 6/8/16, 3:45 PM
by cormacrelf on 6/8/16, 3:53 PM
by nichochar on 6/8/16, 3:02 PM
I wonder what kind of steps we can take to prevent this risk.
by ysavir on 6/8/16, 4:56 PM
That way authors can continue to use any name they want, and the emphasis is on letting installers know that they might be installing the wrong package.
by zmanian on 6/8/16, 8:15 PM
Ones dev environment should be a place where remote code execution is a high probablity and we need better tools to partition that from high value data.
by airless_bar on 6/8/16, 4:01 PM
I think most languages these days are a bit smarter and avoid this beginner mistake (for various reasons).
by bennofs on 6/8/16, 3:30 PM
Possible explainations:
* Perhaps many of those are automated build systems, which would also explain the high number of systems with admin access (for example, if you use travis without docker, every build runs in a clean vm with admin access).
* People download one package and install it multiple times? Seems unlikely
Any other ideas?
by mirekrusin on 6/8/16, 4:51 PM
but even this just tries to put the problem under carpet. you could still for example have requests package which just installs request package, works as expected, just sends request/response to your own server from time to time. ie. when there's http basic auth used only.
by mbroshi on 6/8/16, 5:01 PM
by ryanmarsh on 6/8/16, 2:56 PM
by jogjayr on 6/8/16, 10:21 PM
by jwilk on 6/9/16, 12:19 PM
by tbrock on 6/8/16, 6:52 PM
by andrewstuart on 6/9/16, 12:16 AM
by sheerun on 6/8/16, 5:49 PM
by irremediable on 6/8/16, 3:08 PM
by optimuspaul on 6/8/16, 3:31 PM