Slashdot Mirror
Does Code Reuse Endanger Secure Software Development? (threatpost.com)
msm1267 quotes ThreatPost: The amount of insecure software tied to reused third-party libraries and lingering in applications long after patches have been deployed is staggering. It's a habitual problem perpetuated by developers failing to vet third-party code for vulnerabilities, and some repositories taking a hands-off approach with the code they host. This scenario allows attackers to target one overlooked component flaw used in millions of applications instead of focusing on a single application security vulnerability.
The real-world consequences have been demonstrated in the past few years with the Heartbleed vulnerability in OpenSSL, Shellshock in GNU Bash, and a deserialization vulnerability exploited in a recent high-profile attack against the San Francisco Municipal Transportation Agency. These are three instances where developers reuse libraries and frameworks that contain unpatched flaws in production applications... According to security experts, the problem is two-fold. On one hand, developers use reliable code that at a later date is found to have a vulnerability. Second, insecure code is used by a developer who doesn't exercise due diligence on the software libraries used in their project.
That seems like a one-sided take, so I'm curious what Slashdot readers think. Does code reuse endanger secure software development?
The real-world consequences have been demonstrated in the past few years with the Heartbleed vulnerability in OpenSSL, Shellshock in GNU Bash, and a deserialization vulnerability exploited in a recent high-profile attack against the San Francisco Municipal Transportation Agency. These are three instances where developers reuse libraries and frameworks that contain unpatched flaws in production applications... According to security experts, the problem is two-fold. On one hand, developers use reliable code that at a later date is found to have a vulnerability. Second, insecure code is used by a developer who doesn't exercise due diligence on the software libraries used in their project.
That seems like a one-sided take, so I'm curious what Slashdot readers think. Does code reuse endanger secure software development?
Glad we got that resolved.
If you use a third-party library that has a bug in it, you'll be exposed to the same bugs that everybody else using that library are. On the other hand, if you go at it alone, your implementation will have bugs of its own. And if the library is well-maintained, it'll have fewer bugs than the thing you make from scratch.
Implementing the common functionality from scratch can easily become another kind of "not exercising due diligence", particularly when dealing with complex code. Or to put it another way: code reuse may endanger secure software development, but not reusing code may also endanger secure software development.
Most people just install software like they would a washing machine, once it's in, they don't touch it anymore except to run it, after all, a washing machine has a strong motor, some controls, valves and a belt, there is virtually no maintenance necessary and if it ever does, it's cheap enough and long-lasting enough you can just throw it out and replace it.
Maintenance is a necessary part of anything that is a very complex machine and is not protected. A car is a good example, it sits outside so it needs to be protected against burglary but also against the elements, salt and accidents as well as regular maintenance to replace worn and outdated parts.
Computer systems are as complex and vulnerable as cars, they sit 'outside' on the Internet, where they have to be protected against 'bad people' and just regular outdatedness but often they are considered as dumb appliances (if not actually called that by a vendor).
People need to pay more attention and fund their "computer-mechanics", not just the manufacturers of their "car" and demand that they are able to inspect and repair their own stuff regardless of who invented it.
Custom electronics and digital signage for your business: www.evcircuits.com
The alternative, which is everyone writing their own mostly terrible implementations, is far worse.
Because you could certainly code up a more secure implementation of SSL yourself. That's probably the funniest thing I've seen on slashsot, ever.
Granted, if it's closed-source you have to trust the library vendor. If it's open-source, you either have to do due dilligence or trust someone else who claims to have done so.
I assume we are talking about re-using source code, linking with staticly-linked libraries, and using and "private copies" of shared libraries binaries (e.g. /usr/local/bin/applicationname/lib/lib1.so or C:\Program Files\Application\DLLs\MyDll.dll). With "public" shared binaries (/usr/lib/sharedlib.so or C:\Windows\...\MSDLL.DLL), you are relying on the library or OS vendor to keep things patched.
Here's an example:
I know of a popular product that uses its own private copy of Java. If the vendor doesn't update their customer's versions of Java on a regular basis, an attacker can exploit it, even if the user is updating the "Oracle" version of Java on a regular basis. That's bad. On the other hand, they would probably be in a worse of a position of the vendor re-wrote the functionality of Java in-house, as that code would have its own set of bugs and it would likely NOT be as maintined as Java is. The solution is to use the "Oracle" version of Java instead of a private copy, OR push out updates to the private copy within a day or two of Oracle pushing out their updates.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
...
It little behooves the best of us to comment on the rest of us.
... upon whether or not the reused code is written in a manner that is proper and secure. If insecure code is reused, well, all bets are off. If secure code is properly reused, then the results can be good.
What's needed is better operating system management, not better development practices.
Once a piece of software is patched, the problem is fixed. That's not the issue at hand. The issue is that that fix then does not make it back to production systems in a decent time.
What's needed - and I've posited this a number of times for a number of things - is a central repository which lists which, say, linux packages are secure and which are not. Which algorithms, hashes and cryptosystems are compromised or not.
Then there needs to be an API - running a production system live on the Internet? It will check its version numbers and package hashes against the centralised "uncompromised" versions service. If there's a discrepancy -a package that's been marked as potentially compromisable, but which has an updated or patched version available - the OS is tainted much like the kernel is tainted. If MD5 is retired and any software on the machine still utilises it, the system is marked as tainted as soon as it checks into the centralised API.
We've needed this for hashs and crypto systems for a long time. SHA-1 is retired, but how do you KNOW that? And how do you know what uses that? Nobody would recommend building a system using WEP or MD5 in this day and age but nowhere is that listed in a queryable manner.
And then you start saying "Why weren't Facebook checking their systems against the Secure Software Database? Their own fault if they were compromised.", "Why did Yahoo not re-hash with a listed-good algorithm as soon as their existing hash was obsolete?", "Why were they compromised? Because they turned off database checks and updates? Idiots".
There needs to be a way for production systems to algorithmically say "This is no longer acceptable practice" and start making a fuss such that the system maintainers are forced to start upgrading, with specified timescales (the API could easily obsolete stuff on a set timescale, with warning enough to test changes to newer algorithms).
Then, if you're compromised because you ignored this, or because you hard-coded MD5 instead of using libraries, all the fault will be in the your third-party, unlisted libraries. And then you might be able to actually start forcing vendors to publicly state "All our software uses the latest database-compatible algorithms, software and patches" rather than just hope that someone at Google isn't just running Slackware 2.0.
The software can be fixed in a trice. The problem is getting that fix out to production systems in good time, and not being able to sufficiently shame those who don't manage their systems (it's easy to blame a hack on the software, rather than your lax update practices).
Code reuse is a fundamental tenant of secure software development lifecycles. You reduce the chance that you introduce new vulnerabillities by limiting the amount of new code per project to the core business logic and leveraging existing modules for the support infrastructure.
That said, if the module you reuse has problems then you aren't necessarily better off. The modules need to be vetted and maintained appropriately. Code reuse isn't the problem so much as taking random crap from the internet that solves your problem without assessing its suitability for inclusion given your threat model or properly assessing it for vulnerabilities.
Monoculture can be an issue from certain perspectives -- flaws in the libssl portion of OpenSSL affect a huge percentage of the internet. However, they only need to be fixed once and consumers of the library can all receive the update, assuming proper patch management in the environment. If your company uses 15 different libraries to perform a specific software function across different product lines without a basis in engineering requirements constraints, you're doing it wrong.
Security being a subset of correctness, I think overall it is b.s. to say code reuse is a problem. You just need to make sure you are reusing correct, vetted and maintained code. I.e., don't take strange code from someone's github to use in your enterprise software without reviewing it.
You're responsible for the code you write, and if you are using existing libraries, you are responsible for tracking the packages you use. If they update, and your installer includes it, you need to update your installer. You may not feel this justifies pushing updates, especially if the change is to functions you did not use, but the program really should be checking for library updates and asking the user if they should be updated – and sometimes there are reasons why they cannot. At that point, it becomes the user's problem.
How is the Riemann zeta function like Trump rallies? Both have an endless number of trivial zeros.
Dearth of independent audits endangers secure software development.
But eventually security researchers will shake out the bugs, and as long as new features stop being added to 3rd party software, then those libraries may become very secure indeed.
Until all software is formally verified like SEL4 there will be software vulnerabilities. After that it will be a matter of choosing how much distributed verification and redundancy is necessary to mitigate hardware vulnerabilities. Fast homomorphic encryption will be the final nail in the coffin for globally accessable vulnerabilities.
Obviously, code reuse means that a given vulnerability will show up in more places than it otherwise would; but you can't meaningfully size up the costs of that without considering the alternatives. If people aren't reusing code, odds are that they are rolling their own(quite possibly cutting nontrivial corners since reinventing the wheel is slower than just grabbing whatever library is popular and slapping it in). Is that what secure software development looks like?
Code reuse does increase the odds that people poking at somebody else's product will find an exploit that works on yours; but it also increases the number of people with an incentive to provide a fix that you can drop in to solve your problem.
That won't save you if your setup is totally hopeless(eg statically linked vulnerable library and no updates to fix that, or embedded/otherwise locked down system where updating shared libraries isn't an option for the user); but if that is the quality of what you are shipping with the convenience of reusing big chunks of code, just how optimistic am I supposed to be about your all-in-house product?
..reinventing the wheel. Which can easily be done badly.
Even for the most common search / sort algorithms, there's a good chance you won't code them perfectly first time.
Code re-use, code-from scratch. Both have their place. Both require intelligent thought.
"developers failing to vet third-party code for vulnerabilities"
LOL. What would you suggest? Code inspection by magically infallible developers who have their own work to do creating new features probably wouldn't recognize vulnerabilities in their own code?
Most companies and projects do not employ security researchers and specialists, not for their own code and certainly not for anyone else's, and they are not about to do so. And even if they could afford it, I wouldn't be too hopeful of the bugs actually being found. In fact, spending the time to find the bugs in the first place probably creates more vulnerability than would otherwise exist.
Because Java! Not the worst programming language ever, but the problems that come from garbage collection and programmers who THINK they understand it.
We need to get off of the HTML/CSS/ crazy drunken bandwagon and get back to basics! Re-boot and re-tool the the entire process because if we don't we are just screwed and more break ins will happen as the things become more and more complex. You need to let DBA's build the database portions of things and secure access. You need to let Systems people write HARDENED code. Let web guys make things pretty. You need to stop demanding a a single point tool and go back to individual inter working parts, written by competent coders, which are then put through a very severe hardening process.
Hey KID! Yeah you, get the fuck off my lawn!
A well known, maintained library such as OpenSSL? You're far more secure using the open source library. Not only do you need to be an expert to correctly and securely implement that level of cryptography, but it can contain all sort of subtle bugs you're unlikely to catch.
Now if you're talking about some random library you found on github because some guy on stackoverflow said to use it? That makes you less secure. Don't put random things you found on the internet into your program without reading the code, understanding what it does, and doing a full audit on it first.
And there's a special place in hell for anyone who uses gradle, nvm, or anything else that automatically downloads the library for them without specifying an exact version. You're just asking to be screwed by a trojan horse. Leftpad was about the best case scenario, imagine if leftpad had changed their code to be a backdoor instead?
I still have more fans than freaks. WTF is wrong with you people?
So does reinventing the wheel. So does cut-and-paste coding.
Code reuse leads to insecure software in much the same way that breathing leads to cancer.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Does OpenSores Fester At Your Organization?
The answer when we come back.
When we come back next time.
NO! We don't listen to the Jenny Mcarthy's of this world! WE VACCINATE! and stay clear of faster poooo and so should yoooo!
Code Re-use and open source software lead to super-reliable, robust, and secure code that is the foundation of the Internet. With all the eyes constantly looking over the code it continues to get better and better. And since no program or company has time to write everything from scratch, code will be reused until we can teach computers how to write code.
It's just that people don't give a shit about writing secure code. They just want a fast production cycle.
Good code is good code. Bad code is bad code. Knowing the difference is what makes you a "programmer".
As has already been stated, you generally want to prefer to use a third-party library over a custom implementation, for most security-related code. This is doubly true for well-defined algorithms, which are implemented in well-tested (and preferably open source) libraries.
However... there's an inherent danger in adopting third-party libraries based on uninformed assumptions about quality, as I'm personally well acquainted with. If you have a manager who is prone to making baseless assumptions, and downloading random packages off the internet which purport to be semi-related to the current problem development is experiencing, and insisting they be integrated as the "easy" solution for that problem, you're going to end up with bad quality software (or worse).
As the saying goes: garbage in, garbage out. If you're doing software integrations based on garbage processes, you're still going to get garbage out, no matter what the quality of each third-party module.
I understand your logic. You're not being stupid, but you are misinformed.
> hacking scripts will become useless since every system will have different vulnerabilities
The fact is, over 90% of the CVEs are the SAME 12 or so vulnerabilities - hard-coded default passwords, SQL injection, etc. I can and do write scripts that find "new" vulnerabilities in software we've never seen before. One-off, custom software, especially web applications will pretty reliably have one or more of a gew specific vulnerabilities. You may have heard of the "OWASP Top 10"; most one-off software contains at least two or three of those ten.
Once I (or the script) detects anything else about the software, we can know more specifically which vulnerabilities it has, before we even test it. For example, I've seen a dozen different scripts named "download.php" or similar. All but one suffered from the exact same three vulnerabilities.
> central repository which lists which, say, linux packages are secure and which are not. Which algorithms, hashes and cryptosystems are compromised or not.
>
> Then there needs to be an API - running a production system live on the Internet? It will check its version numbers and package hashes against the centralised "uncompromised" versions service
That's precisely what I spend 40 hours a week building and maintaining. It's a very helpful part of a comprehensive security strategy. Other good parts are having security experts available to help you make sense of the flags and decide on the best way to remedy the issues. You mentioned MD5. If you find out your HTTPS server is running MD5 and RC4, which aren't strong, which algorithms should you replace them with? Should you allow either as a fallback? Also similarly monitoring and analyzing your logs, using both good automated tools and experts. The last thing I'll mention is actually the most important - tested off-site backups.
The version and configuration testing that you mentioned, the system I maintain for a living, is called Cloud Insight.
Hackers will typically target the most popular libraries, because these will be found on the largest number of computers. If you want your software to be more secure, use the #2 or #3 library, assuming they have appropriate functionality. Hackers are less likely to attack these.
This principle is beneficial in other ways as well. If you are using commercial libraries, the #2 or #3 brand will try harder to support you, the customer, because they want to catch up with #1. The #1 brand, on the other hand, tends to sit on its laurels, often failing to adequately maintain its code.
Analogy time: Imagine homes with no Circuit Breakers. Any short circuit anywhere could burn down a house. Lawyers and lawmakers arrive on the scene and declare that everything you want to plug in needs to be short proof. Every product has to be certified not to burn down houses, no matter what failure happens. The designers of even a simple lamp can end up being charged with murder, and as a result nobody really wants to use electricity.
We have circuit breakers, which limit the amount of current to be supplied to an appliance. If you have a special big appliance, like an air conditioner, you have to use a special circuit to supply it with power. Circuit breakers serve to limit the side effects that are possible when you use electricity.
There is no analogous circuit breaker in our widely used operating systems. When you run an application as a user, ALL of your authority is given to the program, and you have to just hope that it does the right thing. There are systems which do place limits on the side effects of a program when you run them, and they are even user friendly and fairly easy to understand.
It's up to us to start to use operating systems that have the ability to limit the side-effects of programs. One example is the Genode project. There is also the perennially late GNU Hurd
For example, I've seen a dozen different scripts named "download.php" or similar. All but one suffered from the exact same three vulnerabilities.
They all suffer from P, H and P.
There's really no comment needed.
Oh fuck too many beers.
See the problem here?
One of the best examples of Betteridge's Law of headlines I've seen in quite a while! :)
No, code reuse obviously does not endanger secure software development. It was hard enough for the experts to get ssh right, and you think you're just going to whip one up from scratch? Yer a freakin' idiot if you think that!
Code reuse (like pretty much everything else associated with software development) has risks and benefits. Learn what those risks and benefits are, and stop searching for magical "silver bullets" that fix all your problems. Because they don't exist.
There is (conceivably) a remedy available under Copyright Law. Many "Internet of Things" devices (in particular, network cameras) run (at least some) libraries that were licensed under the GNU LGPL. One of the conditions of the LGPL is that users be able to - at will - replace the device's LGPL'd libraries with their own version (with the same API). If these devices do not have such an 'upgrade' mechanism available (and I suspect that few, if any, do), then they could find themselves legally liable.
If the device manufacturers feel that they're at legal risk here, then this may motivate them to make their products more easily updatable in the future.
The only benefit I can see in rolling your own assuming comparable code quality from a security perspective is your specific use case may allow you to significantly reduce overall complexity vs. more generalized solutions.
When we integrate third party libraries we do try to review code and have contributed back bug fixes as a result. Yet frankly for some very commonly used libraries including OpenSSL I don't believe anyone has ever bothered to try. I don't consider this a defensible position. If your going to save a bunch of time or gain a capability that would otherwise take multiple lifetimes to implement yourself for free you should at least be willing to review the code in a way you are reasonably able to.
There are other libraries we have looked at and rejected as too dangerous and then proceeded to implemented our own. Much of the time these efforts are not specifically about security but reliability. What we find often just amounts to poor coverage... unchecked resource allocation, unchecked I/O, nonsensical concurrency semantics and severe misuse of dangerous functions.
Then there are the critically important libraries you can't possibly rewrite which are so helplessly fucked up they must have been written by Adobe. These we normally use IPC to talk to in an isolated process space not because security because we don't want to hear our customers bitching.
The reality is most companies don't care about security.
When was the last time your boss added a security audit to your sprint? When was the last time someone said, "make sure you add enough time on this task to make it secure."? Security is not a priority for companies, so we don't spend time thinking about it.
For these reasons I advocate irresponsible disclosure: we need to give companies motivation to improve their code.
Irresponsible disclosure is responsible
It's well documented that car drivers have lots of accidents when they share roads. Can anyone share their experiences of driving without roads? It's not like there can be any downsides, surely?
My argument is that many programmers design needless complexity into things because they believe they can just "outsource" their problems.
For example people design systems with complex file formats they could not parse themselves, then they load a script interpreter which will parse it for them.... and as a side effect execute any code in that file.
If they would have chosen a simpler file format, a few lines of code would have been able to parse it perfectly well.
Also there is one particularly toxic way of code reuse and that's dynamically linked libraries. While those sound like a decent idea at first, in reality they have the big disadvantage of not only making your system a lot more brittle, but also increasing start-up times. Increased start-up times mean that, to use the functionality of another program you can no longer economically just start up that program to do you bidding as it would take far to long. Instead people now run things like TLS in a library running in the same memory space so that buffer overruns can simply read the keys and data of other connections or even the rest of your program.
So while code reuse has it's advantages, it can go terribly wrong when it's done wrong... and it's often done wrong.
Not entirely wrong.
Code variety becomes less with higher level languages so it is not surprising that the security issues are alike.
It is also possible to argue that the problem comes from using PHP in which we are back at code reuse.
Using a high level language with a built in library with a lot of complexity isn't really different from pulling in an external library with a lot of complexity.
The main problem I see with code re-use is that the library functions often only do almost what you want but not entirely.
You often end up getting a lot of security holes from functionality you didn't want to begin with.
It's not a problem when a programmer pulls code out of his archive to put it to new use. What is a problem, though, is people googling their problem du jour that they cannot solve, find code that more or less does what they want, adapt it to their specs and consider that programming.
What you will usually find as one of the first hits that way is tutorial code that showcases the function that you might be after, but without any sanity checks and without the even barest minimal security in mind, simply because it is supposed to TEACH without distracting by adding code that doesn't contribute to the function.
That's why injection is still, after over ten years, the number one on the OWASP Top 10 list.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Glad we got that resolved.
But it WILL give democrats an excuse to say they were hacked by Russians.
It is indeed simplistic and one-sided to assert that "using libraries exposes systems to bugs". The problem is far deeper, and affects both library and bespoke code bases. First, consider the somewhat psychological problem that often happens when using libraries. The various flavors of public code (e.g., Open, Free, etc.) have as an implicit or explicit basis the presumption that since the source is freely available, those using the libraries will peruse the source, either to fix shortcomings or to correct bugs. In effect, it is distributed vetting. Unfortunately, as the Heartbleed vulnerability with OpenSSL demonstrated, there are many who slipstream when using such packages. When the incident occurred, the list of major computer software enterprises using OpenSSL without internal vetting (or for that matter, externally funding the OpenSSL committee's audit functions) was long and distinguished. In essence, each responsible management said to itself "Everyone else is vetting, why should I?". Those who attended a basic Economics course should recognize this as a version of the "Commons" problem (although the examples invariably discuss the origin of the problem, English common sheep grazing pastures). There is a significant (> US$ 100,000/project) benefit to NOT vetting and relying on "someone else in the community". At least until it becomes obvious that almost everyone has been assuming that someone else was vetting the code. Internally-developed code is often limited in its specification, development, and testing. Since it is developed for a specific project, the effort to make it widely applicable is often lacking. Often, bespoke code developed for one project is appropriated, officially or unofficially, for other projects. Unofficially appropriated code is particularly problematic, as the connection between the original copy and the new copy is often the developer's recollection. When corrections are made, they do not propagate to all of the copies. In summary, the problem is less code-based than human-based. Shortcuts save money and time in the short run, but cutting corners leads to quality issues.
except for every thing else.
Economics seems to focus private code efforts on features over bugs. (See Micr^H^H^H^H who's on top of the security alert list.)
Open source's published, commonly used code makes it easier to develop exploits.
But the code review and wide testing it can provide is probably our best hope for making bullet proof code.
Unfortunately, a lesson from SSL is that for all the users, there does not appear to be that much review going on.
Open source is our best hope, but we need more incentives for review.
why are non technical people writing technical articles... it's like they've never heard of open source or libraries
But more accurately, code reuse permits more software development in general, including insecure software development.
Put a string of password like alphabet soup in a routine. Then when that routine becomes ensconced in some other application it can still be searched for and noted for replacement of removal. It would only take about 128 bytes to clearly note application, programmer, usage, date, time, etc. It used to be a size issue but with todays Gigabyte memory size, that issue has diminished dramatically.
The big issue I see in my daily work life is that management acts as if using a third-party solution, be it proprietary or open-source, means we will receive perfect code at the beginning and never have to update it. We lock versions early in the dev cycle, but if a new version comes out mid-development there is a general distrust of changing to the new one.
And then, when the inevitable critical issue is discovered after we have release, we have no efficient plan on how to update. At least GPL solves that; when users have a pure-GPL system, they can always recompile/relink everything themselves after the big patch. But if I statically link a proprietary license library into our proprietary product, we have to step in and rebuild to get the fix out there. And the lack of preparation for this process does endanger security.
The management teams I've worked with are typically better at estimating and preparing for critical field breaks in "our" code. But that's why they like third-party, and that assumption of "perfect" that makes the future look so much better. So the bigger issue is that managers endanger secure software development.
The problem with unbounded pointer vulnerabilities (stack smashing, return value changing, parameter changing) is the unboundedness of the pointer. ONLY the programmer and (for some languages) the compiler know what values are legal for a pointer offset.
Programmers aren't enough.
So I use GoLang (but Java, Rust, Node are all similar in this regard) because I know that all my pure-GoLang 3rd-party libs cannot have unbounded pointer errors. This means Go's SSL, not Go's OpenSSL wrapper. A Userspace written in entirely managed pointer languages cannot have these problems (except at the kernel level).
Science & open-source build trust from peer review. Learn systems you can trust.
See subject: It's a huge danger of "OpenSores" https://www.google.com/?gws_rd=ssl#q=Efast+chrome/ having it reused for nefarious purposes (fake Chrome browser exploit).
* It's the SINGLE BIG REASON I don't give away code I write in APK Hosts File Engine 9.0++ SR-4 32/64-bit https://www.google.com/search?hl=en&source=hp&biw=&bih=&q=%22APK+Hosts+File+Engine%22+and+%22start64%22&btnG=Google+Search&gbv=1/
(I won't give it away to have an "evil doppleganger" of my work out there doing folks wrong...)
APK
P.S.=> Especially since that program does users nothing but RIGHT giving them more speed, security, reliability & anonymity than any other "so-called 'solutions'" do for FAR less resource consumption slowness + bloat & moving parts for breakdown/exploit yet does FAR more using what you have natively already... apk
In a previous life (several, in fact), we followed the "write once" rule. If you needed a queue, you looked to see if there was one, made sure it did what you wanted, and used it. If it didn't, you filed a bug and a patch, then you used it. Reuse tended to cause code review, at least enough to make sure it wasn't going to fail in the new use, and additional testing. As a result, the quality slowly increased with each additional use.
davecb@spamcop.net
Yeah, because its oh-so-smart-and-wise to reinvent the wheel in a vain attempt to show how clever you are.
Grow up, twit.
If you manually install libraries this is also going to be problematic. I've often found myself my own package maintainer. It's hard to keep track of everything and some libraries or packages can break each version needing code changes. In niche cases the libraries are being build not simply because they are out of data on the system and newer is needed. Sometimes they need to be patched in a way that wont be accepted upstream which raises the maintenance code for upgrading. VCS helps but it's still a big hassle. I try to make an effort to keep everything up-to-date but occasionally things slip. Luckily for me a lot of it isn't a security concern for most packages as they are internally used.
The situation is actually sometimes worse with automatic package managers that bring in dependent libraries. The issue there is that you have a swarm of new development for things like npm, composer, etc but no quality control. A lot of repositories have issues with this. Things like cpan and Pear I notice has a lot of problems with lots of old unmaintained packages of varying dubious quality. Newer systems have a lot of new content with very little review and varying use or feedback. Lots of quality issues are found there as well as things like ten people developing the same thing. No one appears to even be doing basic checks before letting these packages be listed on central official repositories. Some people in the associated communities even resent the suggestion of any kind of quality control or banding for packages as some kind of foreign non-inclusive notion. It reminds me of when the schools tried to eliminate performance tiers and to make everyone a winner. These attitudes are annoying especially when its merely a grade that doesn't have to eliminate new content from being accessible, merely help people make the right choice about whether to use it or not. Grading isn't a perfect art but it can be done fairly well based on standards checks, web of trust, usage and maintenance statistics, etc.
The problems are on multiple fronts, security, stability, compatibility, bloat, portability and even potentially licensing issues if people have bundled things inappropriately. An example of the absurd is recently I wanted to install a package for being able to execute and intercommunicate with language A from language B. Normally this process by default would compile a library for language B that uses the system includes and library for language A. Instead of doing this the package downloads the maintainers entire binary build of language A which is huge and not even compatible with the system. An option to use a custom compile of language B rather than the system is fair as an extra-option. This package however was simply half baked and wrong. I then encountered multiple other packages that did similar things.
I tend to care and try to do what I can to verify the quality of something including things like checking how recently it has been maintained and so on. However it's really very difficult to do a really thorough job of it.
Either you replied to the wrong comment or you have trouble with reading comprehension, which one is it?
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.