from the I've-created-a-devastating-masterpiece dept.
Open-source security: It's too easy to upload 'devastating' malicious packages, warns Google:
Google has detailed some of the work done to find malicious code packages that have been sneaked into bigger open-source software projects.
The Package Analysis Project is one of the software supply chain initiatives from the the Linux Foundation's Open Source Security Foundation (OpenSSF) that should help automate the process of identifying malicious packages distributed on popular package repositories, such as npm for JavaScript and PyPl for Python. It runs a dynamic analysis of all packages uploaded to popular open-source repositories. It aims to provide data about common types of malicious packages and inform those working on open-source software supply chain security about how best to improve it.
[...] "Despite open-source software's essential role in all software built today, it's far too easy for bad actors to circulate malicious packages that attack the systems and users running that software."
[...] Attackers distribute malicious packages on npm and PyPl often enough that it's something OpenSSF, which Google is a member of, decided it needed to be addressed.
[...] OpenSSF says most of the malicious packages it detected were dependency-confusion and typo-squatting attacks. But the project believes most of these are likely the work of security researchers participating in bug bounties.
"The packages found usually contain a simple script that runs during install and calls home with a few details about the host. These packages are most likely the work of security researchers looking for bug bounties, since most are not exfiltrating meaningful data except the name of the machine or a username, and they make no attempt to disguise their behavior," OpenSSF and Google note.
OpenSSF notes that any of these packages "could have done far more to hurt the unfortunate victims who installed them, so Package Analysis provides a countermeasure to these kinds of attacks."
"security researchers looking for bug bounties"?
Related Stories
Backdoor in public repository used new form of attack to target big firms:
A backdoor that researchers found hiding inside open source code targeting four German companies was the work of a professional penetration tester. The tester was checking clients' resilience against a new class of attacks that exploit public repositories used by millions of software projects worldwide. But it could have been bad. Very bad.
[...] A few weeks later, a different researcher uncovered evidence that showed that Amazon, Slack, Lyft, Zillow, and other companies had been targeted in attacks that used the same technique. The release of more than 200 malicious packages into the wild indicated the attack Birsan devised appealed to real-world threat actors.
Dependency confusion exploits companies' reliance on open source code available from repositories such as NPM, PyPI, or RubyGems. In some cases, the company software will automatically connect to these sources to retrieve the code libraries required for the application to function. Other times, developers store these so-called dependencies internally. As the name suggests, dependency confusion works by tricking a target into downloading the library from the wrong place—a public source rather than an internal one.
To pull this off, hackers scour JavaScript code, accidentally published internal packages, and other sources to discover the names of internally stored code dependencies by the targeted organization. The hackers then create a malicious dependency and host it on one of the public repositories. By giving the malicious package the same name as the internal one and using a higher version number, some targets will automatically download it and update the software. With that, the hackers have succeeded in infecting the software supply chain the targets rely on and getting the target or its users to run malicious code.
Previously:
Open-Source Security: It's Too Easy to Upload 'Devastating' Malicious Packages, Warns Google
Dependency Yanked Over Licensing Mishap Breaks Rails Worldwide
More Than 75% of All Vulnerabilities Reside in Indirect Dependencies
(Score: 3, Interesting) by darkfeline on Thursday May 05 2022, @07:41AM (1 child)
Distro package repos were at least vetted by the maintainers. Having central repos where anyone can upload anything was bound to be an issue from the start.
Go does it right, by defining standard protocols and deferring the package hosting to users. It doesn't prevent stupid, but it makes it more obvious where packages are hosted (e.g., some random guy on Github). You can't typo squat since the domain/path is going to be vastly different.
Join the SDF Public Access UNIX System today!
(Score: 3, Interesting) by Anonymous Coward on Thursday May 05 2022, @06:18PM
I think you should have stopped with your first paragraph. Having a trusted package maintainer of your distribution vet things before you get them, and the distro freezing on a version until a compelling reason to change that version (backporting specific bug fixes to the frozen version, but ignoring new features/bugs), provides about as much safety as is possible.
Go's model is the random chaos of downloading crap from random places all over the Internet with no clear indication of which are legitimate sources-- this is the model Windows has historically used for everything, leading it to be the number one malware platform for decades. This is a shit model. And, Rust's, Python's, Java's (like Go), etc. are all shit. A major reason for language package managers is because some commercial operating systems do not have a proper/sufficient package management system for distributing libraries.
And, static compilation being encouraged/only supported option by some of these languages with package managers is even more shitty. So, now your application has to be re-built every time an exploit is patched in any library it uses. So, you / your users need to now keep track of every bug in every dependency of your app to be safe. Meanwhile sane software gets automatically patched for library vulnerabilities when the user does a routine (likely automated) update on their OS, getting all the patched dynamically linked libraries from their distribution with zero effort by you or the end user.
(Score: 2, Insightful) by Anonymous Coward on Thursday May 05 2022, @07:54AM (14 children)
The whole theoretical 'strength' of Open Source is that "many eyes make for shallow bugs." In reality however, only a few elite coders look at source code. These are either the maintainers, or those wanting to make a fork, ....or malicious players scratching for a weak point. Joe Linux does NOT look at source code. I did IT for years, but I take a Linux distro and all its packages which I may add, as-is. I have work to do. It would take me a few centuries to sift through the source code and I would have to upskill considerably for it to make any sense. There is a beauty to the Linux updates model, but yes - malicious entities have abused in and will abuse it again.
(Score: 5, Insightful) by maxwell demon on Thursday May 05 2022, @09:07AM (2 children)
If you look at the source of this quote [catb.org] you'll see that it did not mean that everyone who uses the code also reads it. To quote (emphasis by me):
So it only applies to a project that's developed by many people. A project with few developers and many users does not meet those conditions.
In other words, the relevant quantity to look at is the number of active developers. If it is low (or even just one), the probability of a bug or vulnerability is not automatically lower than for some proprietary package (it all depends on the abilities and responsibility of the few developers).
It's a nice example what happens if you miss the context of a statement.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 1, Touché) by Anonymous Coward on Thursday May 05 2022, @09:48AM (1 child)
Yes, but this quote has been applied in the mis-construed context time and time again. Another thing to consider is that a lot of distros have a small team - sometimes one to three people. The commercial big guns (Red Hat, Canonical) have larger teams and they do a major amount of work on the code base. No wonder the 'corporate interests' like systemd or snap get in. Looking at the credits on some packages even in that "big" space, it comes down to one to five individuals working on a set of utils or tools. Few eyes, but held more accountable than the closed source world. There you get monkey code and no discussion.
(Score: 0) by Anonymous Coward on Thursday May 05 2022, @02:27PM
That is only a problem of the people mis-applying it - and maybe a problem for those what will take a wrong-context quote seriously.
(Score: 4, Insightful) by shrewdsheep on Thursday May 05 2022, @09:54AM (1 child)
You say it yourself. All that comes before is contradicted by this statement. I heard this opinion voiced before here that there somehow is an obligation to check the code changes before updating if you want to be a responsible user. Well, there isn't because it can't be done. Like with https, there is a chain of trust. You trust your distro. The distro-maintainers trust their upstream sources. The upstream repos trust their developers. Trust is built through a track record of reliable, secure updates, reactions to vulnerabilites and handling of disputes. A responsible person in this chain will occasionally take a deeper look, certainly not exhaustively (openSuse, which I'm on, delivers ~ 100 updated packages per week, there should be a review of maybe commit logs, certainly there is no complete code review).
The solution is to create tiers. The core distro-repos should have (if only informal) standards for project quality to allow packages in and allow for the rest to go elsewhere but still be accessible at your own risk. AFAIK (almost) all distros make this distinction. If python and node.js don't make this distinction that's the problem right there.
(Score: 3, Informative) by HiThere on Thursday May 05 2022, @01:41PM
Python does, but PyPi is the secondary tier. Python advertises (advertised?) itself as "batteries included", which meant that it came with a large library of vetted code, but PyPi handles lots more stuff that's much less validated. So of it's beta quality. What this article is saying is that some of it also includes "report home" features.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 2) by janrinok on Thursday May 05 2022, @12:56PM (8 children)
I wouldn't use a library produced by Joe Linux that I didn't understand. All the libraries that I use provide source code - not just a binary blob. And the Python Standard Library is fully vetted and maintained by the Python team. Other libraries that I might use always provide the source, usually with a some form of test modules too. Yes, bugs occur from time to time, but not the sort of malicious code that TFA is describing. The bugs are fixed promptly and the new version is made available if you wish to use it. And that is the next point to remember - you don't have to update your program with every new version that is released. If it is working and the new release is not a security issue then don't update. You will not see the benefit anyway.
Secondly, if you are upgrading software you don't have to check every line again. You look at the list of changes that the new code has implemented and then look at the diff code between the version you already have and the version that you are updating to. Very often bugs are fixed by a change to a few lines not a complete rewrite. Again, it is easier if they have included a test suite of some kind - but if they haven't then they aren't approaching the task very professionally.
There is a difference between a short program that aims to scratch your own itch and something that you hope will reward you with some form of payment in the future. The latter demands significantly more effort and attention to detail.
But essentially you are correct - it takes a lot of effort to write good, reliable code. Whether you write your own or put your trust in somebody else's library is a personal decision.
(Score: 3, Informative) by HiThere on Thursday May 05 2022, @01:44PM (7 children)
https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf [cmu.edu]
Even if you're doing something really simple, you've got to trust some group of others. There's really no alternative.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 3, Insightful) by janrinok on Thursday May 05 2022, @02:16PM
I agree, and that repeats what another comment has already pointed out. At some point you have to decide who you trust and who you don't.
I will confess to having downloaded somebody else's offering, looking at how (s)he did it, and then reimplementing my own version but that is only possible for relatively small libraries. But that is the value of OSS and the various licences that are available. Something like Flask or SQLAlchemy I trust because the maintainers are well known, there are many books explaining the library and, frankly, I just don't think I could write anything anywhere near good enough to do what they do.
(Score: 2) by FatPhil on Friday May 06 2022, @02:42PM (5 children)
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by HiThere on Friday May 06 2022, @03:05PM (4 children)
No. It presumes that you don't know whether every system is compromised. And you don't. You can estimate probabilities, or you can personally vet ALL the code at the machine level until you're sure...but you can't do that.
So you've got to trust at least some people.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 2) by FatPhil on Friday May 06 2022, @04:00PM (3 children)
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by HiThere on Friday May 06 2022, @07:38PM (2 children)
We must be using word to mean different things, as I can't imagine how you could reach that conclusion from what I said.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 2) by FatPhil on Saturday May 07 2022, @10:06AM (1 child)
You're coming over as someone who's never read Wheeler's DDC thesis. Maybe acquaint yourself with the field before professing some kind of expertise. Academia didn't grind to a halt in 1984, you know.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by HiThere on Saturday May 07 2022, @01:26PM
OK. One person cannot "bootstrap". It requires too much time and effort to be possible. A society can bootstrap, and have actually done so, but to have a society requires trusting others.
If you see a flaw in that assertion, I'd like to know what it is.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 5, Insightful) by Anonymous Coward on Thursday May 05 2022, @08:02AM (4 children)
So proprietary software for all? \o/
This sounds like it's more about jealous control of code (and a lust to keep it private/black boxed) by Google.
We must defend open source software and hardware with all of our strength, or we will lose it to big corporations.
The only reason Linux still exists is because Microsoft (and/or other companies) hasn't been able to BUY it all up.
We must defend distributions like Debian even more so because of the freedom and liberty it provides us.
Otherwise we'll be virtually sodomized by the corporations who want control over everything and they don't
care about us at all. It's all about money, greed, control, power.
(Score: 5, Insightful) by maxwell demon on Thursday May 05 2022, @09:34AM (3 children)
No. The problem is that in those repositories, there is no difference between some hobby project by a sole coder with unknown skill and a project by a trustworthy developer or group. Yet the standardized interface gives the appearance that all the packages available are endorsed by the language maintainers. How would you differentiate, without a web search, between a trustworthy and a non-trustworthy Python package on pip?
Note that this does not mean no open source. For example, Linux distributions come with a lot of Open Source packages, but the distribution's repository is not open for anyone to write. If you want to get your software into it, you must at least convince the maintainers that it is worthy of inclusion. Which doesn't mean you can't distribute Linux software that's not in the repository; you can provide your own repository that users can explicitly add in their package manager, or provide just an .rpm or .deb for your software, or provide an installer that works completely outside the package manager, or provide it through another software management system, or even just provide the source if your users are able and willing to compile for themselves.
In all those cases, the user explicitly knows that whatever is installed is not in the responsibility of the distro maintainer, because it needs to be added explicitly.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 0) by Anonymous Coward on Thursday May 05 2022, @12:00PM (2 children)
For a business, you pay someone to vet the modules for you. There are companies that do that.
(Score: 3, Informative) by PiMuNu on Thursday May 05 2022, @12:41PM (1 child)
I didn't realise that PyPI was not vetted. The python documentation is misleading:
https://packaging.python.org/en/latest/guides/tool-recommendations/ [python.org]
Phrases like "Use pip in a secure manner to install a Python application and its dependencies during deployment." - the link sends through to some stuff saying check the hashes before running anything. Nowhere does it say and ps: the code you pull from these repos is arbitrary junk/virus code. Note this is the official python documentation.
This is not consistent with other package management tools like apt, or indeed (dare I say it) google play store. As a dumb user, the distinction is not clear to me.
(Score: 4, Interesting) by janrinok on Thursday May 05 2022, @01:10PM
https://security.stackexchange.com/questions/79326/which-security-measures-does-pypi-and-similar-third-party-software-repositories [stackexchange.com]
The last one was asked and answered in 2015 - it is very much a case of caveat emptor when using PyPI. If a library has been available for quite some time you can accept (at your own risk) that it is probably OK to use. That is just my €0.02 worth.
(Score: 0, Troll) by adamantine on Thursday May 05 2022, @08:32AM (2 children)
Repositories for Javascript and Python? Thank goodness SN is in Perl!
(Score: 5, Insightful) by janrinok on Thursday May 05 2022, @10:49AM (1 child)
Which you should know has its own repository; try searching for CPAN [cpan.org]. Our code relies on modules pulled from it, so I have to ask 'What's your point?'
And the same is true of almost all software languages in use today - rust, D, Go etc. The problem are those programmers who simply download something from a repo assuming that it works as they expect it to, and then just accepting that it is secure. That is about as stupid as buying a house based solely on an internet image or believing everything a auto salesman tells you.
A responsible programmer will test updated software before it gets anywhere near production code.
(Score: 0) by Anonymous Coward on Thursday May 05 2022, @01:38PM
It goes beyond that, because some language tools will automatically update from the official servers at build time, even replacing local packages with remote packages of the same name if the remote version number is higher. And of course they automatically pull in dependencies. And by 'some' I mean all of them are moving that way. It's nuts.
(Score: 5, Insightful) by Anonymous Coward on Thursday May 05 2022, @09:12AM (2 children)
First generate some fear and doubt about random coders on the big bad internet
Then centralise code in vetted app-stores where people can only upload once they have submitted photo ID. Did we say photo ID ? We meant biometric. Much safer. Voice print google has already. Semen sample will be added in the next product, google wank - just to be sure.
Then the license to own a general purpose computer. Telling a computer what to do is best left to the professionals, not the snotty kids. Kids ? We meant terrorists, money launders and drug dealers.
(Score: 0) by Anonymous Coward on Thursday May 05 2022, @07:36PM
for security reasons users will be all too happy to reestablish handshake posture daily, will they offer this at airports soon?
(Score: 2) by Joe Desertrat on Friday May 06 2022, @12:14AM
Exactly. Any fears we might be warned about in open source projects are probably already in play in proprietary software. While it might appear to be doing what you want it to do, discerning that it is doing things like violating your privacy, etc., will take effort far beyond what ordinary users are willing to effect.
OK, now this is just plain funny. I can see the advertising for it now. "Let Google Wank handle your porn searches based on your determined preferences".
(Score: 5, Interesting) by anubi on Thursday May 05 2022, @09:57AM (7 children)
I face this situation a lot and installed several malicious packages. Been lucky, I suppose. Two of them cost me the time to reset my phone to factory and reinstall my stuff.
I started doing this:
Take a MD5 hash of my downloaded apk.
https://f-droid.org/en/packages/com.hobbyone.HashDroid/ [f-droid.org]
Cut and paste the hash code to Virus total to see if they have seen it before...
https://www.virustotal.com/gui/home/search [virustotal.com]
If they have seen it, they will tell you what they think the file you hashed is.
And if they found anything wrong with it.
If they haven't seen that hash, then they won't have the slightest idea what it is, and they will tell you that as well.
If they haven't seen it, I would be really wary about installing it.
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 4, Funny) by janrinok on Thursday May 05 2022, @10:56AM (1 child)
I hope that is a mistype... apk is not usually welcome around here.
(Score: 2) by inertnet on Thursday May 05 2022, @11:04AM
From now on, just call him application/vnd.android.package-archive.
(Score: 1, Interesting) by Anonymous Coward on Thursday May 05 2022, @12:19PM (1 child)
This is likely the underlying motivation for Google's take on the topic. Google wants you to believe that installing applications from anywhere else but their repository is dangerous and you should only trust them. The ting is, Google doesn't vet the applications in their app store very well either, and they certainly don't vet the libraries used by application developers to build the apps in their app store.
(Score: 2, Interesting) by anubi on Thursday May 05 2022, @01:57PM
Well, that's the way I've been vetting my downloads from "anonymous" sites. Incidentally, this same paradigm works for a lot of Windows .exe installation files too. However, my expertise kinda stopped at Windows 7 , when the guy I used to work with got caught up in family matters, and he had to move 500 miles away - and I did not want to move to Denver.
This is a way I can make sure that the file I get from a repository is the exact same file that Virus Total has vetted. Well, it's going to be so much trouble to design a rogue file that has the same MD5 that it's way too much work just to foul up a phone.
I can't vet the code, same reason I have to trust the pharmacy to not sell me bad pills.
But software is really neat in this aspect: Either it is or is not an exact copy. Doesn't make any difference where it came from. Change just one bit and it's MD5 will be wildly different.
Personally, I have far greater peace of mind from a file I downloaded from a completely unknown source whose IP maps to somewhere in Screwistan, after VirusTotal vets it for me, than I have for anything I download from a play store, and I did not have it vetted first. How do I know someone did not upload screwy code to the repository?
I trust VirusTotal, and I trust the MD5 hash function, far more than I trust any repository.
That MD5 means I do not have to upload the whole shebang to VirusTotal, just 32 hexadecimal digits.
If they have vetted this package before, they will recognize the signature. And I just calculated my own MD5 signature from what is often a multi megabyte executable that I just downloaded from God-knows-where, using a small local tool which I have verified.
As long as VirusTotal vets what I submitted is the same as what they analyzed, I will consider it properly vetted and install it.
I have been using MD5, since the days of DOS, where I had chose coding a MD5 algorithm in Borland TurboC for a class project. I used it as a tripwire to make sure my critical files were not monkeyed with by those pesky viruses of the day that I would pick up via BBS and sneakernet. I could put it on a 360K bootable floppy, and it would boot up, verify itself and every file in it's list on the hard drive, and tell me if any had changed. We are talking IBM PC here. DOS 3.3. 1MB RAM, 20 MB Seagate HDD. And lots of 360K floppies.
Those were the days. I actually understood exactly what I was doing. I knew what every byte of code was there for.
Yes, MD5 can be monkeyed with, but it sure is a lot of trouble to do it.
If I were into mil grade, I'd use both MD5 and SHA on it.
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 3, Touché) by maxwell demon on Thursday May 05 2022, @02:05PM (2 children)
An MD5 hash? So all the hacker has to do is to make a malicious file and a harmless file with an MD5 collision, upload the harmless file, let Virus total know about it, and then later replace it with the malicious file. Virus total will recognize the MD5 and “confirm” that it is harmless.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 1) by anubi on Thursday May 05 2022, @02:38PM (1 child)
Yes, that can happen.
However, if the original author is so inclined, there are so many ways of coding in a backdoor into anything that is a lot easier to do than colliding MD5 from files that are both executable and having both of them actually execute. But then, a lot of "junk code" can be included in the program, whose sole function is to provide diddle-able bytes for the function of facilitating a MD5 collision. Like preloading buffers with specific crap used solely to influence MD5 calculation.
Once the word gets out on it, people will use something else, hell, even a CRC32 will do, to see the download through a different lens.
Sure is a lot of work, especially when you don't know that everyone will use MD5. I use it because I have it and it's handy. VirusTotal accepts other hash formats besides MD5.
I use MD5, but others can pick other hash functions.
That's what makes this paradigm of vet-by-hash so frustrating to spoof.
That's quite a job to spoof 'em all simultaneously!
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 0) by Anonymous Coward on Friday May 06 2022, @12:05AM
MD5 has been known to be vulnerable since 1996 and has been fully broken for over a decade. There is no excuse to keep using it. Even SHA1 is deprecated and should be phased out.
(Score: 4, Interesting) by inertnet on Thursday May 05 2022, @11:02AM
Some years ago I needed to install npm to review some code. After seeing the ugly thing that npm actually is I immediately banned it from my system.
Recently I moved Postman into a seperate VM because I noticed it uses a similar folder with thousands of javascript files. I need Postman for debugging, but I refuse to install a package that uses countless of libraries in which probably thousands of angry adolescents can 'contribute fixes'.
(Score: 5, Insightful) by JoeMerchant on Thursday May 05 2022, @12:15PM (2 children)
It is just as possible for an open source project to be secure as a closed/proprietary/commercial product.
Both require diligence, review of submitted code, pen testing, etc. All these things are costly, and not much fun for most developers whether in open or closed source.
In my experience, open source projects led the way in source control, unit test coverage, continuous integration, and similar initiatives over the last 30 years which were viewed as "too costly and no fun" before they became more or less standard practice in larger projects.
In the end, it is much easier to evaluate the process maturity of an open source project than a closed source product. In many cases it is simply impossible to evaluate a proprietary product's true security process maturity, and dependence on a proprietary component puts your product 100% at risk for problems in the component, termination of vendor support, etc.
My hope is that focus on security ultimately drives software toward simplicity, a reduction in library proliferation, collapsing of redundant layers and efficient design and use of clean layers. Oh, and I want a pretty unicorn pony for my birthday too.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 2) by bart9h on Friday May 06 2022, @12:49AM (1 child)
Exactly.
I always avoid Node and Python based software, because npm and pip are huge mess of dependencies from who knows what origin.
(Score: 2) by JoeMerchant on Friday May 06 2022, @01:02AM
I avoid the fat ugly snake as much as possible also... but when it's time to do an AI/ML project, there's little practical choice available right now.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 5, Insightful) by Rich on Thursday May 05 2022, @01:53PM
This has nothing to do with open source or not. The first part of the title can be omitted. It's just "It's Too Easy to Upload 'Devastating' Malicious Software (*)" in general. Quite to the contrary, with open source you at least have the theoretical chance to find out. And with free software, it is at least not guaranteed that the package is provided to somehow profit off you (while with a corporate offering, it is the whole point).
The solution may be a ring-of-trust network of individuals, where each developer signs their own product, and we try to figure out their trustworthiness through heuristics (e.g. how long known, how many releases, how many hops through how trustworthy intermediates, and so on). Of course that wouldn't eliminate all risks - but neither do the app stores. It's more like on ebay where you're safer than in ordinary retail when the vendor has 10k+ 99.5% feedback, or you are taking risks with 250 87.8% feedback.
(*) The wording "Packages" in the original text makes clear that this is a just a propaganda thing from Google to push App Stores. Some MBA drone probably figured out that they want a cut from software rent seeking in in the future, and the press release is the result of that.