@asilentmurmur: If there was such a thing as a "global" system flaw, it would usually be isolated to a specific ingredient (such as the Kernel itself, a software application, a hardware driver, etc.)
In cases where there's a security flaw that could affect our users, someone in the forum will bring it to our attention if it's not already under investigation - something that severe wouldn't get past our community. What ever the "vulnerability" would be, that one ingredient is updated when the flaw is corrected.
For example: Let's say someone found a flaw in the Chrom(ium) web browser software, which I'm picking on web browsers only because they're constantly scrutinized since everyone uses them and if you gain entry to back-end a browser, you virtually "own" the user's web environment and if it goes deep enough, their entire computer. A browser is a single package and/or possibly one or more of its dependencies which will require attention from their authors, not the tens of thousands of ingredients/extensions that are currently on the books. If by chance it were possible that other packages which use libraries and the likes FROM Chrom(ium) and would possibly also fall into the same category, they too would be investigated, but that tends to be less common as the correction at the top of the hill tends to cover most of those below it.
Misconception of what it means to be a maintainer: EXTENSION maintainers are not normally responsible for the "fixing" or "updating/enhancing" of other people's software; that's normally up to the authors themselves. Extension maintainers normally just compile other people's software applications and when needed, look into compilation issues/problems that arise over time as things in the overall picture change; more times than not we don't have to modify the application or its dependencies - nor would we want to, otherwise, it would create a unique fork in the road which would likely break when the author(s) created an update on their end. We do have a few patches for the Kernel, BusyBox and a few of the toolchain apps which are Tiny Core specific, but we keep things like that to a minimum and based on necessity.
Lastly, let's say there's an extension, as you mentioned, dated 2013... let's say for sake of argument that the extension version is 3.2.1 and the current version is 3.2.6.
Sometimes a maintainer will leave well enough alone with an extension which has no updates in a long time or has updates which wouldn't really affect the Tiny Core environment or its overall functionality, so they'll decide "If it's not broken, why change a good thing!" Another path that happens is sometimes an update to an extension also makes it much larger in file size where it's decided the "changes" don't outweigh the "Tiny Core" principle and thus they're left alone -- still functioning for their purpose, just not as "new" (and "fat") as "Current" would make it. This is where our users tend to compile the newer version for themselves if something in the newer version is wanted, but very few others would feel the same way. Sometimes, it only takes a few people to request the newer version for an informal "vote" to go into motion and the maintainer ends up upgrading the app to appease the public - and sometimes they'll just offer a hand to help the user do it themselves if the upgrade doesn't conform to the TCL way of things. Finally, sometimes the "latest and greatest" Package "A" ends up breaking Packages B, C and D in the process. This all has to be weighed.
To put your mind at ease... not many things around here are avoided due to laziness or complication - everything is usually done by choice for what's best for Tiny Core.
Welcome
FAQ
Downloads
Wiki
