* Posts by chilinux

3 posts • joined 24 Sep 2017

NPM apologizes for ham-fisted handling of recent staff layoffs


The blessing and curse of centralized software module sites

It seems like several modern languages never learn the lessons that two decades of Perl's CPAN should have taught.

The history that seems often repeated goes something like this:

(1) Someone comes up with a clever new programming language and runtime

(2) The primary APIs and modules are created for the language that are provided standard

(3) People start extending the language with modules that aren't accepted for inclusion in the standard

(4) Someone eventually suggests it should make things easier if there was a centralized site for all these additional modules

(5) Someone creates a solution that seems to scratch that itch

(6) Everything seems to be working great for 1-2 years, long enough for the solution to become established

(7) Issues come up that make it clear the full lifecycle of a module was not covered in the original governance model

(8) The central authority comes up with quick fixes to appease the masses and keep them hooked on the established central model

(9) Eventually the lifecycle governance breakage results in a mass of modules of which the majority are no longer maintained, no provision exists for establishing a new maintainer, code that breaks due to updates in the language/API and code which never really work as described.

NPM seems to be in stage 8 of the CPAN history. Also, much like CPAN, NPM is both the name of the tool and the name of the site/service that the tool defaults to. And much like CPAN, the tool is not designed to make it easy to have multiple competing public sources. Instead, the tool encourages everyone to put all their faith in the tool/site authors/maintainers.

Sometime check the documentation for what is involved in trying to create a secondary public NPM using npm-registery and get others to add the registery to the npm configuration. For Python and GoLang, the ability to have multiple sites publishing modules under difference governance rules is clearly a design goal of the tools that come with those languages. That level of flexibility doesn't seem to really be intended as part of NPM.

I really thought the drama of Kik leveraging NPM to bully the author of left-pad should have been a wake up call that governance of NPM was more self serving than in the interest of the community. The Isaac Schlueter post on how to apologize makes it clear that transparency is a requirement. The first two steps in the apology must contain "clear explanations" and the final step of the apology is to explain what will be done "to make sure [it] never happens again." That level of transparency in an apology seems critically important when the installer tool encourages users to trust a single source of governance of the public modules. Yet, NPM fails to provide that level of transparency all. It replaces clear explanations with excuses and deflection. Lastly, after screwing up to have an action plan of '[working] hard to uphold our values every day" seems to speak volumes of how little their values really count for anything. This statement neither provides a clear explanation how the NPM values allowed the problem to take place or provide clear direction on how it will never happen again.

They forked this one up: Microsoft modifies open-source code, blows hole in Windows Defender


Unrar is *NOT* Open Source and Microsoft needs to be sandboxing malware detection

The Open Source Initiative (OSI) provides an Open Source Definition (OSD) and the Unrar license does not qualify. The OSI provides a list of licenses that have been reviewed for their compliance with the OSD and the Unrar license is not listed. The Fedora Linux distribution project does have a written review of the license which starts off with:

"This license is BAD, and should not be used in anything in Fedora. It has use-restrictions that make it GPL-Incompatible and non-free."

So, Unrar is source-available but no Open Source. From a practical standpoint, Unrar probably does not get the same level of code review and community contributions because the license causes the code to fall outside the scope of the Open Source community.

It is understandable that a part of the malware scanner must run with LocalSystem rights to ensure it has read access to all the files, but once the file is read into memory the decompression and detection engines should be able to run unprivileged. Even if Microsoft addresses unrar related exploit, the fact they perform any decompression at LocalSystem level indicates a much more serious and fundamentally flawed design. The OpenSSH service has a long history of avoiding full privilege level exploits because it is designed with privilege separation of the different code. Microsoft has claimed to be doing something similar for the Edge web browser. It is unbelievably incompetent of them not to do the same for an anti-malware service.

Any "security" service that is not written to withstand itself being under attack is providing security in name only. It seems like "Security Essentials" was designed just to get the approval of a rubber stamp that they provide malware protection. In terms of getting the approval of the security community, this product clearly violates modern best practices.

Facebook U-turn: React, other libraries freed from unloved patent license


Not really an U-turn, still an attack on the Open Source Definition

Adam Wolff makes some very troubling statements:

(1) "Next week, we are going to relicense our open source projects React, Jest, Flow, and Immutable.js under the MIT license."

(2) "This shift naturally raises questions about the rest of Facebook's open source projects. Many of our popular projects will keep the BSD + Patents license for now."

Both of these statements clearly indicate Facebook considers their Patents license clause to still be part of an Open Source license. This claim throws away the community established Open Source Definition as stated by the non-profit Open Source Initiative by replaces it with Facebook own for-profit definition of "open source." Their corrupted BSD license is not an OSI approved license and therefore none of the projects covered by it is Open Source. There is no such thing as "rest of Facebook's open source projects." There is simply the rest of Facebook's projects which are source code available under non-open source terms.

While Adam Wolff's announcement that React, Jest, Flow and Immutable.js will now finally be put under a true open source license is a welcome change, the fact he feels Facebook can unilaterally redefine them as always having been open source is a major problem.


Biting the hand that feeds IT © 1998–2021