JavaScript dev deliberately screws up own popular npm packages to make a point of some sort Two popular open-source packages were recently sabotaged with mischievous commits, creating confusion among those using the software and exacerbating concerns about the fragility of the open-source software supply chain. The npm packages, faker.js and colors.js, were not hijacked by outsiders, as has been known to happen; …
If it's widely used, *pay the creator real money*. As well as a community fund of a non trivial amount, sign up for a support contract if it exists.
If you can't contribute money, contribute effort. If you can do neither you shouldn't rely on the product staying around.
Never, ever, blindly pull the latest version into your product without thorough testing, always have a local staging server of known good versions.
For particularly broken but still useful products (thinking of the huge OpenSSL debacle), consider bringing the product in-house and develop your own fork, as the OpenBSD team did with libressl.
Regardless of what opinions the creator has this has happened before, and not enough has been done about it. We should all think ourselves lucky that what the developer did wasn't malicious.
This is perfectly possible to set up, if open source people wanted to.
GitHub could move to the YouTube model of “channels” that are monetised, per download, split between what gets pulled in.
For extra credit, each project gets labelled as Unranked, Bronze, Silver, or Gold. If your download is Gold, you can only pull in Gold, etc. Since you are reaping the rewards of monetisation, you have an incentive to *check* what you are pulling in.
To be Bronze, you just need a certain number of downloads, and then GitHub enforces some sort of maintained version tree automatically, rather than just latest and greatest.
To be Silver, requires maintaining some level of quality to standardised rules, and verified by GitHub. Paid for by the monetisation.
Gold requires an agreed bug and security support contract between author and GitHub.
Platinum establishes a level of forward planning and reviewed roadmap, where the author commits to upgrade features as requested and also commits not to add insecure feature bloat that they felt like on a Wednesday.
Yes, I’m aware how many terms of open source licenses that violates. And yet it fixes many of the problems of open source useability, and incidentally of library bloat. You aren’t going to pull in hundreds of unexamined and unnecessary libraries, if doing so costs you financially handing over a percentage of your download fees to them.
Open source “contributors” who prefer the current Wild West approach can stay on Bronze if they like. People who actually want to get paid for their work can work to a more structured and managed approach.
Don’t you think that the huge dependency load of popular frameworks might be *part of the problem*?
And that maybe transitioning the industry to a set of incentives where it costs even 0,01cents per dependency, might cause magically reduce framework bloat by x100 overnight? And in exact proportion become 100x more secure by reducing its attack surface.
Who's going to pay it? The open source developers that decide to include those dependencies and all the dependencies those dependencies depend on?
All of web development is built on a house of cards. And not a shiny new deck of cards, some of these cards have been been flapping away on your bike spokes for so long that they are barely holding together
"How are you going to sign for support contracts for each of them?"
That's entirely your problem. If something is important for running your business, then you either have some sort of contract or payment involved, or you have a damn good disaster recovery plan. It's exactly the same situation as a company like Facebook complaining it's too difficult to moderate posts because there are too many of them. You are not entitled to a profitable business model. If it costs too much to run your business the way you'd like, it's not anyone else's responsibility to come up with a solution for you. Too expensive to moderate comments? Then you don't get to make a profit. Too difficult to track down dependencies? Then you don't get to complain if your business collapses when something breaks.
Part of the problem will be that the people in the business most adept at managing risk will have zero knowledge, view, or oversight over this area of risk. Most people's view of IT is "works or doesn't" and they don't want to know how the sausage gets made. Most devs are under time pressure to get work out for people that don't understand "quick or properly, choose one" and will therefore add to the fragility either knowingly or not. The modern world is unfortunately built on short-termism.
The obvious answer to me is : At the point of commercialization.
Redhat
Minecraft
IBM
Vizio
Just like "Ethical investing" there can, in theory be ethical purchasing "do you support monetarily the freeware developers of the open source you are using".
Need a project to create a cryptocurrency that issues coins based on open source code contributions, updates and identifying security flaws?
Would need to create a resale market for the coins so would likely need a new licence that forces large users to either contribute code or buy these coins on the resale market.
Wishful thinking?
It's not *difficult*, but because of the way software worked around the time GPL was developed, you had to have your own copy - software as a service didn't exist*. So open-source licenses basically said 'you can use this freely, just not sell it'. It didn't prohibit running the software and renting out the service offered by the software.
Not sure if open source licensing has caught up now, but a 'fairer' model would say - if you're making money off this (or more than a certain amount), pay a fee or a %age. If it's a pet project or a small enterprise, use it for free.
Incidentally, my understanding of the the origins of free software is that code should be reusable and available for public viewing / analysis / bug fixing. The 'free' was never as in 'free beer'. It's just that it's difficult to go chasing after Oracle or Amazon for your cut if they're using your OSS.
* though I'm sure some greybeard will refer me to some decades-old mainframe-time rental or some such :)
To me there's two sides. It makes no sense as a business to pay for something you can get for free. The developer's real mistake is the level of support they've offered the product for no cost. A business will think "good on you, keep the updates coming". On the other hand it makes little sense as a business to utterly rely on something which may contain a critical flaw that may not get fixed once discovered because the developer has got the pox with freeloaders. Given the source code is available businesses may be willing to ride that roller-coaster based upon previous developer support. It is also a short-term view vs a long-term view and most planning is decidedly in the short-term camp as it fits with rewards.
OMG how much open source we use at work (Fortune 100) and nobody has even the time to talk about it, let alone pay for it, or even dedicate some time to contribute. All we do is just glue it all together. If I had a company card I would definitely pay and support the maintainers but it is not how big companies operate. Also, nobody really cares because there is no accountability, I’m not going to push my manager tomorrow to pay some random developer I think needs support, I want to be promoted at the end of the day.
On the other hand why the hell developers use those permissive MIT licenses and then sob when their code is monetised without leaving them any coins? Is there no license which would say it is free but only if your turnover is less than $250mil? Surely you want to retain some copyright power in these situations. Or maybe consider using a copyleft license to make sure future generations will have access to this code?
If the code is used without modifications neither permissive nor copyleft licences are going to make much difference. If it is modified then if it's copyleft the distributor has to make the changes available to the recipient but it still doesn't bring payment.
If someone has developed a package and posts it on Github or anywhere else there's nothing that requires them to make any further changes to it. If a corporate user wants something added then either they do it themselves - forking it if necessary - or offer to pay someone such as the original developer to make the changes. Either way the developer shouldn't feel pressured to simply keep on maintaining it let alone make changes without payment.
These situations seem to arise from someone feeling obligated to continue to maintain something without payment and consequently an expectation by others that they will. That doesn't have to happen.
You are wrong abou copyself licences. Even if code is used without modification if it is redistributed the source has to be made available. In the case of the GPL and AGPL the source for any software that uses a library must be open source too.
You can use that to make money by offering dual licensing to those who do not want to open source their code.
it does not cover all situations, but it covers many.
I agree if someone develops something they are not obliged to maintain it forever free.
"the source has to be made available"
There's what the licence says, and there's what happens in reality.
And in reality, it takes legal pressure to get a company to release anything at all, and those things that are released are often the things deemed strictly GPL, meaning they have fulfilled their obligation but the result is essentially useless as all the magic is missing (even as a binary blob). And, of course, there's a bazillion little no-name companies importing tat from China and sticking their badge on the front. Ask about the GPL, they don't even bother to reply.
And anyway, in neither case does the open source programmer see anything whatsoever for their efforts. Oh, okay, maybe an NFT "merit badge" for their work being used in X, but merit badges don't put food on the table or keep the person supplied with tea/coffee.
Even if code is used without modification if it is redistributed the source has to be made available.
That sounds to me like "if it is used in a product that is distributed to others" i.e. to catch software vendors. However if I'm a multi-billion dollar enterprise and I use the library internally and it helps me keep the money rolling in this means I am under no obligation as I have redistributed nothing. To me that sounds like the situation in the story.
It's all about balance though, right? I mean, you can absolutely take that stance, but then you lose the right to complain when a committer goes rogue, breaks all your stuff, and you're getting chewed out by your boss because your system is down and you have no idea how to fix it because its all cobbled together with third-party code and. no support.
You pays your money, you takes your choice. Or not, in this case.
I mean, you can absolutely take that stance, but then you lose the right to complain when a committer goes rogue, breaks all your stuff, and you're getting chewed out by your boss because your system is down and you have no idea how to fix it because its all cobbled together with third-party code and. no support.
But that only happens if you're an idiot that pulls latest versions and doesn't test. If you're happy with v1.0, it works, and you don't need to move on then there's no issue. If you do then you comprehensively test right?
Slight tangent, but related to a point that BinkyTheMagicPaperclip brings up previously: "Never, ever, blindly pull the latest version into your product without thorough testing"
"colors.js is incorporated into almost 19,000 other npm packages and gets 23 million downloads a week."
This scares/worries the systems engineer in me.
If on a WEEKLY basis 23,000,000 downloads (requires/imports) are being done across ~19,000 dependencies, and if a similar relationship holds for other critical dependencies, that seems to suggest a huge number of projects frequently iterating builds and deployments.
Bearing in mind this is a single package the security vulnerabilities of this practice seems stark across the Node.js ecosystem.
The numbers are scary but a bit misleading. In a naive js project (most of Github) you would automatically build it upon every commit or a PR which in turn does “npm install”. Now, PRs are automated these days through the use of various bots and could be opened/closed on a regular basis without the intervention of the programmer (more downloads). This does not mean that the software downloaded from NPM is deployed to a server, lambda, or becomes part of the website js code.
Agreed about the numbers - but my primary point is the sheer complexity of verifying the combined effect of the sheer number of dependencies in most large applications, especially where there is a frequent commit cadence across the application and its dependencies.
Also, in respect to CI/CD those won't be doing a rebuild and test cycle on each commit or PR on all those dependencies - or randomising the test harness to reflect real-world client connections.
I can easily imagine one of the many dependencies introducing subtle, conditional, behavioural changes that don't do anything different when in a test environment but could trigger malicious payloads on very specific request parameters (IP address, referrer, user-agent, date/time, request parameters, etc.).
Yep, it's a long-standing problem that, seemingly, many others (19,000?) don't care about one jot. That's the way of the Web though.
The other major dependency that everyone takes totally for granted is the web browser. We're able to wake up one morning to find that Google (or whoever) has taken it upon themselves to change something about How The Web Works, pushed out a Chrome (or whichever) update, and broken a ton of stuff. That's not really an ideal situation either... Ok, so Google and the other browser publishers generally don't do it overnight (there's betas, announcements, press releases, etc), but Google seem to have a not wholly collegiate approach to it; they do whatever suits Google.
Indeed. I too am somewhat amazed that many just blindly go out to the Internet to pull stuff at build time.
A few years back we had some interns writing some little web-based thing for some monitoring. They complained to me (the ever helpful sys admin!) that they couldn't do something which was blocking their work. That something was pull some sort of library from the Internet. I had to explain that for one we don't have direct access we use proxies. Also I posed the question that the library they were downloading may not be there one day, what would happen then? This was not long after the left-pad debacle.
Things have moved on a bit now and we have a Sonatype Nexus proxy thing which can retrive/store/scan such libraries/repositories so that you should always have your own known good local copy to use.
Obligatory XKCD
Maybe this would be a solution; do a subscription model like spotify and distribute the revenues to the different projects according to popularity.
The article says that
"colors.js is incorporated into almost 19,000 other npm packages and gets 23 million downloads a week."
If the developer(s) get 0.01 (EUR) cent per download, that's 2300 EUR per week.
Not too shabby I think?
Additionally: Add a "donate" button like on twitch.tv or something similar.
That might also help.
So we basically just need a money distribution platform integrated into GitHub.
I would say its easier than that. Let gh sponsors work by analysing dependencies (easiest to start with projects that are published as packages that list dependencies npm nuget rpm yum apt etc) , and divine a royalty based on distance from sponsored project the dependency is referenced in the dependency chain.
Then just credit the projects account with their share. That way the popular projects consistently feedback to the building block projects, and the low level projects included everywhere benefit from there ubiquity
Youtube does a similar thing with its subscriptions. A portion of the amount you pay every month goes to the creators you use. Similarly a portion of paid-for GitHub accounts' fees could go to open source dependencies.
That should be pretty hard to game, as you can't get back more than you pay for, and the amounts involved will be small.
GitHub suspended Squires's account and in the meanwhile, his repos remain publicly accessible. The Register has asked GitHub to explain its rationale for doing so but we've not heard back.
...
GitHub is committed to ensuring the health and security of the npm registry," the organization told The Register.
"We removed the malicious packages and suspended the user account in accordance with npm’s acceptable use policy regarding malware, as outlined in our Open Source Terms."
El Reg's implication is, by their direct action, GitHub has essentially stolen the code, and the rights to said code, from the person who actually creates and continues to maintain it.
And I fully agree with El Reg's assessment.
Seems fair enough, deliberately sabotaging popular widely distributed libs isn't much different to locking someone up who threatens to burn house down after lighting some small fires
Loosing write access seems sensible in this case. Your ip rights and personal freedoms are less important than your ability to commit hand grenades
You're opening up a real can of worms though by taking control of someone else's property (and it is their code after all) just because they do something you might not like.
What if they just added a 5 second interrupt to the code, where it displayed the author's name and the, for example, Patreon site where you could donate to help out the author. That's going to annoy a lot of people - might even ruin a few packages which require it to operate without an interrupt. Is it still "sabotaging" the code?
What about an author who removes a bit of functionality (because it was proving too tricky to maintain or whatever reason to be honest - it's their code), but which some other people rely on, is that sabotaging the package? Should they lose their access rights to their code just because some people make use of something they dont want to maintain anymore?
What this guy did, sure sounds like he's a bit of a wanker. But taking away someone's rights to their own code, because they did something that upset other people really doesnt sit well with me. That way leads to big corporations pushing for someone to lose access to their code, because they use it and they dont want any changes being made that might impact their products. And dont tell me that would not happen, because we've all seen that sort of predatory behaviour lots of times...
The author hasn't lost his code; it's still on his machine.
He then uploaded it to somebody else's computer, under the terms of an agreement that he'd previously clicked "Yes" (or possibly "whevs", but still, he clicked).
If he's broken the terms of that agreement, then Github deciding to roll-back one of the repos that they serve to commit n-1 seems reasonable.
Given that we’re now nearly four decades into the idea of open-source, there are many open-source projects that are no longer actively maintained by the person who started them. What if the original author of one of these gets into a spat with the current maintainers, then decides to use their commit privileges to continuously vandalise the repo as part of their tantrum. Sure, it’s easy to revert changes, but in the meantime, every contributor has to add “dealing with that guy’s shit” to the already long list of thankless tasks involved in contributing to FOSS projects.
What would you, as a contributor to that project (let alone someone who depends on its stability) want to happen to that user’s commit privileges?
Lots of people in the Open Source community are altruists - the model wouldn’t work otherwise - some to the point of idealism. But that altruism and idealism blinds them to the fact that sometimes, just sometimes, people act like dickheads, and the common good often means that you can’t be friends with everyone.
Lots of people will jump on NPM as being the problem in this case, but it’s not, really: it’s just exposing an existing culture of developers lazily pulling in whatever’s at the tip of the tree into their code without considering what that really means. If you care about the quality of your software, you edit your dependencies list to remove all references to “latest” or “head”, and then schedule someone to do dependency updating at times that suit you.
Nope sorry if your code grows out of control and becomes infrastructure blindly included by thousands of other projects then no you don't get to have a hissy fit commit or a protest commit, knock on effect is too great.
You wouldn't argue for the right of a bridge designer to blow the bridge up because they are having a bad Tuesday. But here it's OK because it's their code, knock on effects be damned. I agree it's a bad precedent but if you have a widely used project you can't be reckless and should have consequences
So if GitHub (or the powers that be) decide that your code would be "better for the community" if you changed x, y, and z at their direction, and then kicked you out if you refused, that would be OK? Then why even have individual repos? Why not just turn the whole thing into a giant linux kernel-type structure where any change that's made to a repo has to be approved by the powers that be? Why even put up the facade that the code is "yours", when it's actually "the community's"? I agree with the OP, this is setting a dangerous precedent. Why didn't GitHub just fork the code into a new project that only they control, and redirect requests to the original? It seems like they could have handled this better than what they did.
Seems fair enough, deliberately sabotaging popular widely distributed libs isn't much different to locking someone up who threatens to burn house down after lighting some small fires
Errr, it's their code. GitHub just effectively issued a big fuck you to the open source community. Your code is no longer your code. Best move on.
I wish I could say I destroyed my github repos in a similar fit of pique, but they were just obsolete and useless code that was starting to nag me a lot with security dependency alerts because it was so old and crufty. Rather than continue the treadmill of maintaining github repos for code that I neither used nor wanted to use any more, I got rid of them.
Certainly over the years I've seen many projects disappear. One should always maintain a copy of the source they depend on so they can build from it - and make sure you actually can build it!!! I've been on no shortage of projects that didn't do so, and found themselves with an orphaned library or jar that they couldn't reproduce or maintain.
@themeerkat
The old big 3 of *x scripting languages were Perl, Python, and Tcl, no? There was not at time of creation anyone in particular that they were undercutting, that I can think of. Perl allowed one to do things that were inconvenient or difficult in an awk | set pipeline, Python in its early days might have been considered to undercut Perl, and I can't think of what in the "glue" space Tcl would have competed with.
So it seems to me that there are fair-sized areas of open source where the intent is to supply a perceived need, not to write a better X, or a worse but free and still usable X.
Of course, you could point to Postgres as competing with and undercutting Oracle and SQL Server. But if sympathy were electricity, I don't think I could power an LED Christmas-tree light with the Commentariat's sympathy for Larry Ellison and Bill Gates.
So the packages were good and updates by the mantainer were good as long as they were useful. Now, the same maintaner pushes a commit they don't like and it has become "malicious"
It is not malicious, github, that commit has made the package useless. Which is not the same. If useless software repos are banned from github then about 50% of github (unfinished pet projects, obsolete snippets, etc) should be banned also.
I mean, no one is holding a gun to your head. Make a final commit that says "thats it I'm done good luck" and move on with your life.
Let people fork it who have the energy/ resource to continue. If a big company forks it, maybe you can bargain your way into a job with them?
Being bitter about not being able to monetize isn't going to help, you should have thought a bit harder about that when you decided to go open. Lesson learned for next time.
(Terribly easy for ne to say such things when I'm unlikely to ever be in a similar position...).
"Faker.js is incorporated into more than 2,500 other npm packages and is downloaded 2.4 million times per week; colors.js is incorporated into almost 19,000 other npm packages and gets 23 million downloads a week."
That is over 25 million web sites (or at least web pages) that outsource their functionality to a guy they don't know and don't pay every day of the year.
Are you out of your fucking minds ?
I'll never stop repeating this : your production server should have all of its code local and you should know all the code you put into it.
You find a package that is useful ? Fine, download it, test it and incorporate it into your code. But YOU DO NOT LINK TO IT.
It's called security. It's a bitch, but it works.
Bear in mind every build will pull in the package afresh. There might be hundreds of builds to support a live change.
Also this is faker. Generally used for faking data in nonproduction. Lots of the packages that depend on it probably use it as a test dependency.
No, every build should absolutely not pull in the package afresh.
Pull in the package. Test it. Keep the version you've tested. Use that in your builds.
Want a new version? Repeat that process.
Look at the time, cost and effort needed to address the Log4J vulnerability. Don't replicate that vulnerability intentionally in your build process!
There are a huge number of excellent reasons why everyone should follow a controlled process for bringing in and caching dependencies - much reduced regression defects, assured availability of packages, reduction of some kinds of software supply chain risk, repeatable builds, robust configuration management, CI performance, bandwidth efficiency and probably many more.
However, Log4j ain't one of them. Those naively pulling in the latest version (especially if replicated all the way down the dependency chain) with every commit build were probably among the first to close that particular security risk - albeit entirely unintentionally...
It happens in *some* shops (too many, obviously) that don't bother trying to do the absolute minimum with maintaining a known set of dependencies that are not directly pulled from the source.
How can you maintain a product if everything is constantly being modified beneath the hood? Leaving aside the amazingly glaring security hole, of course.
On one hand, this guy is right. His work is exploited by many big companies to make a lot of money without giving him a cent.
On the other hand, that guy made it possible by providing for free his work to anybody.
Was he too idealist? Probably. But we live in a cruel world, and it didn't start yesterday, he should know that.
Do people really think they can make an earning on writing Javascript micro-libraries?
I am not being too pessimistic but imagine you wrote a small library (in any language), complete with sales / marketing page and a shopping cart system to allow people to buy it. I can guarantee that it would remain painfully unused.
Why do developers think that because they can put their library next to hordes of others on an NPM, PIP, CPAN or other language specific repo, it is suddenly going to take in money? This is a warped sense of what these services are for; the design of them is basically for free snippets. They are not app stores.
People do need to put in *slightly* more work before they will make money. They are on the right track but micro-libraries just undershoot the bar.
If you believe otherwise, I would actually be interested in some discussion on this. Perhaps I am undervaluing my own work XD
I know of a guy who paid for half his house with a works-with-all-edge-cases CSV library for .Net.
The target platform is the difference, though. Whatever you may think of .Net (and I don’t want to derail an interesting topic with opinions of Microsoft), it is a system used predominately by organisations who are paying directly for the software they are using. In that scenario, there is a genuine market for components that will save time, and thus money.
libcurl and sqlite are other examples of software libraries that people would pay for, as they solve problems that are difficult, but don’t contribute much to the primary functions of the tool or application that uses them.
There’s actually nothing in GPL that prevent you charging for your work (go back and read it), but Stallman’s decision to make Gnu free as in beer and speech set the pattern for everything following.
The problem of compensation is solvable (each project has a fund account, and you can figure out how to distribute it based on ownership of codebase changes), but it’s the culture of “work for free on a project to land a cool job in Google/IBM/RedHat/whoever” will take a lot more time to change...
If nothing else, it's convinced me once and for all to stay the hell away from Node, NPM and JS in general and anything related.
JavaScript is a bastard language, used by people claiming to be software developers who've never coded in a real language and yet feel they deserve a place at the dev's table. Sadly JS use is so ubiquitous now that we'll be shot of it and the cretins who's entire career centres around a single language that should have been strangled at birth!
When you say "real coding" you mean assembly, right?
Because, beyond that, a programming language is, pretty much, a programming language. They all have their idiosyncrasies, but are ultimately rooted in the same principles, or a subset of. Jumping from JavaScript to C# or Java, or Go isn't as big a leap as you might like to think it is. They aren't 'harder', they just have different rules.
So unless you language of choice looks like 'MOV R0 R4', wind your neck in, we all started somewhere.
@deadcow "Is it the best language for its purpose when used correctly? Yes."
.. well, its pretty much the only language for some types of async client side web functionality, so that's not much to shout about...
Although WebAssembly might disrupt things - I (unfortunately) expect a big embrace of WebAssembly as it will shaft user control of their browser (bye, bye enforcing privacy / ad blocking) .. though given non trivial nature of rearchitecting web sites it may take a while, but be afraid.
So, shit language & total PITA that it is, we may come to lament the days of lots of JS in web sites as being the days when at least we could control what our web client did to some extent (if WebAssembly essentially takes over.. currently can easily disable it )
I fully agree with sentiments regarding the typical Javascript eco-systems with regard to pulling in miscellaneous dependencies without review although I feel the language itself (sans strong typing) is as good or bad as any other, depending on the project requirements.
I get most upset by 'live' dependencies in web-sites to third party served code - the code being served can be trivially modified by the server based on the requesting user agent identity, IP address, and other heuristics, to deliver a highly targeted malicious payload that the web-site/application developers could never trigger.
For $deity's sake copy and serve the verified code/resource to your own server on the same domain as the primary resource!
However, a similar dependency eco-system exists with Rust crates and GoLang imports.
I was quite interested in certain GoLang projects until I dug deeper and two things stood out in particular to me and my requirements:
1. On Linux, code making syscalls needed (at the time I reviewed it - may have changed) to run a C-language co-process to call into the kernel. This aspect introduced some 'interesting' complexities and rather spoiled some of the GoLang promise (and performance - learned via 'crun' - the C-language alternative to 'runc').
2. In typical projects the source-code has an alarming number of "import "github/user/project" which relate to external dependencies fetched using "go get ..." so these external dependencies (and the graph of dependencies in a typical application-level project) have a similar security/review cycle issue.
Similar issue for point 2 in Rust Crates. Each Cargo.toml may well include lines of the form "some_external_library = { git = "https://github.com/SomeRandomAccount/SomeExternalLibrary" }"
Same applies to Perl with CPAN and others.
It seems to me there's a seesaw sliding-scale between Convenience and Trust and currently the scale is tipped too far in favour of Convenience.
Trust comes from reviewing the code - either yourself or your team, or by people you trust (typical web of trust). For example in Linux distributions we typically favour the package maintainers with implicit Trust when installed dependencies.
The problem, and challenge, for 'import the latest from $pseudo_random source' is the lack of a web of trust for each version/release/commit.
Regarding the Rust story, there’s not much you could do about your problem #1, but you can’t pin #2 on the language; bad engineering practice works across all languages.
Un-versioned dependencies are a timebomb. At best you waste days chasing a bug that’s actually down to some anonymous developer’s commit the day before, at worst you run the risk of silently opening security holes in your code every time you do a build.
There’s also the joy of trying to recreate an old build. You might think you’d never have to do something like this, but if a legal action is taken that involves your code, it’s really, really important that you’re able to prove exactly what was built at any given date, which may have been years ago. Your source-code repo can give you your contribution to the product at any date, but if your checked-in dependency-list was “latest” for every package, that’s not even half the story...
> Un-versioned dependencies are a timebomb.
Well, all dependencies are a potential timebomb, but un-versioned ones are definitely ticking. But yes, you're absolutely right, particularly on the recreating an old-build issue. And remember folks, it's not just the source: keep a versioned history of the build environment too.
I can see how the practice arose over time, but the current dev methodology of seemingly just cobbling together a bunch of packages from any number of repositories, resulting in a 'packagebase' rather than a codebase is frankly insane. I'm absolutely not suggesting that we reinvent the wheen every time anybody wants to start coding a new project, but there has to be a better way to manage code libraries that this, surely?
Ask the VisualBasic guys. This was the norm in classic "VB" 20+ years ago - lots of VBX/OCX modules to do the "hard stuff", held together with a sprinkling of glue code and some event handling. Of course, back then, the modules were static, not something fetched from a web server every time you compiled. But the principles are very similar.
Nobody goes into open source from the money. Some careers happen to be able to spin out of it; typically an interested big business or university; or perhaps a consultancy wrapped around using a particular open source project.
Case in point - OpenFOAM. Good luck to anyone attempting to use that from a completely blank page without prior work in that domain.
If this was a malicious act motivated by poor career prospects of being a software maintainer, it is a poor show and only jeopardises future work with their name on it. And if it was a point made about the maintainability and supply chain vulnerabilities that exist in complex software, well, it does that but did it really need a field demonstration? There have been ample already.
If anything, events like this only push the agenda of closed source and/or limited ownership of trusted code i.e. professional maintainers working directly for specific institutions. Cue popular folks like Poettering and the inevitable criticism!
Trust is earned and easily damaged. Damaging it in the name of demonstrating weaknesses is somewhat missing the point. Perhaps, as a working solution to this, a system of peer review around open source code is perhaps what is needed. Although even that of course would not be immune to abuse. There are examples of poorly peer reviewed papers to demonstrate the vulnerability of those checks and balances too.
I'd say if you want it doing right do it yourself, but it's just too big a subject to handle without effective teams. Virtual or otherwise.
Dunno where this ramble is going. Beer time.
What about these packages constitutes malware? Github can get f*cjrdgf. This guy has some real stupid views and I don't like him, however, rules should be consistent regardless of what stupid thoughts are rolling around in somebody's head.
If we enforced things based on how much we like a person, nothing would get done ever, because almost all people think most other people suck.
They're his software, he can do what he wants with it. It was free, go make your own if you want it to run different. Criminy.
It was malicious, because he committed code with the express purpose of messing with the end users. As maintainer he is free to make mistakes with the same outcome, but he didn't make a mistake. When you intentionally create a bad outcome for someone else, it's malice. That said, he was in an unenviable position, minorly because of his own doing and majorly because of forces beyond his control.
"almost all people think most other people suck"
Not me. I think most other people are great. My theory is only a small percentage of people are responsible for nearly all the man-made misery (there are other kinds of misery). How they treat other people creates knock-on effects and pretty soon neighbors can't get along.
"he can do what he wants with it"
No, that's not the standard. He can do what a reasonable developer would do. He can do what the law permits. He can't do just _whatever_ he wants.
At what point did the code stop being his IP?
What gives M$ the right to steal the maintainers code?
If they removed updated versions and prevented him from publishing new ones I could agree with M$, but as soon as they took control of his code I think they stepped over the line.
What laws are being broken here? In any jurisdiction? What "reasonable" developer is sucking code off a source they don't control directly into their own products? What enforceable guarantees are there that the code is fit for purpose and does what it says on the tin?
There's convention, as you say. There's even malice in their actions, especially if they know that people that pull the code are that stupid they don't do basic checks before modifying their own products. As to some kind of ~actionable intent, well, if it's not breaking cybersecurity laws - seems unlikely - that's something else.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
