781–790 of 827 posts
Earlier quoted context omitted.
This seems like a serious security risk. Is there any solution? Would using version numbers without the caret work?
Not only is there a solution, but it's pretty well known computer science. Use public key cryptography to create a digital signature. It's not even a novel use of this -- .NET has been using this to sign assemblies and packages from day one.
Earlier quoted context omitted.
Yes, but I can publish an evil left-pad@0.0.10, and if you're not shrinkwrapping or any sub-dependency has left-pad: "^0.0.3", it will pull in the evil 0.0.10 version. EDIT: I stand corrected. See below, looks that's not the case specifically for "0.0.x" versions, but gets progressively more relaxed if there's a non-zero minor version specified. However, many of the unpublished packages had varying major and minor ve…
No it won't... The caret specifier for 0.0.x packages means "this version and this version exactly ".
Earlier quoted context omitted.
The Apple thing doesn't work though, for a specific reason: it's a very common word/name. Smith is a very common surname. If one person starts the Smith Automobile Company and another person starts the Smith Farm, obviously there's no issue there. That's because none of us invented "Smith", it's understood to be a common name, etc. On the other hand, if I start "The Google Paper Company", I'm pretty damn sure I would…
That is not how trademarks work. Feel free to start the Google Paper Co. Uniqueness is not a merit for trademark infringement. To infringe you have to be a competitor.
Earlier quoted context omitted.
The go solution seems more reasonable and achievable- the host is part of the namespace. Instant decentralization.
There's nothing preventing decentralization with npm now; it's a matter of configuration. Tying the namespace to a host seems more like instant excessive coupling.
If you want to be your own provider then host your packages on your server(s) and tell your users to add npm.cooldev.me/packagename to their configuration.
If you don't want to host your own then you can choose from a few public providers like npmjs but then have to be subject to their guidelines, policies, and fees.
Throw in some automatic bittorrent support in the client to help offload costs and you've got something great.
Earlier quoted context omitted.
That is incorrect. You are also infringing if people could reasonably assume an affiliation due to your use of the trademark, which would definitely be the case with Google Paper Co. You're basically piggy-backing on (and diluting) the brand recognition they've built.
You are correct in that my Google example would likely be trademark infringement because Google is a famous mark. Kik is not a famous mark, so for this case the famous/well-known aspect of trademark infringement is entirely moot. And keep in mind that the OP I was responding to was arguing that if the name is unique it gets extra protection. That's false. Fame offers extra protection, uniqueness does not.
Are you sure a court wouldn't consider that qualifying as a famous mark? I'm not going to dig into case law, but my guess is it very well could be.
"Evidence relevant to the fame of a trademark may include sales, advertising and revenue figures; geographical scope of use; channels of trade; registrations in home and other countries; past enforcement efforts; and the results of consumer recognition surveys (provided the survey methods are approved by the courts in that jurisdiction)." http://www.inta.org/TrademarkBasics/FactSheets/Pages/FamousW...
Earlier quoted context omitted.
There's nothing preventing decentralization with npm now; it's a matter of configuration. Tying the namespace to a host seems more like instant excessive coupling.
Tying namespaces to a hostname isn't really that controversial -- it's no different than email. If you want to be your own provider then host your packages on your server(s) and tell your users to add npm.cooldev.me/packagename to their configuration. If you don't want to host your own then you can choose from a few public providers like npmjs but then have to be subject to their guidelines, policies, and fees. Throw…
Earlier quoted context omitted.
react_demo$ du -sh node_modules/ 25M node_modules/ react_demo$ ls node_modules/|wc -l 79 react_demo$ cat $(find node_modules/ -type f ) | wc -l 287767 I think I installed react, react-dom, browserify (globally), babel. The exact details are not really important, being inexperienced with react I probably installed stuff that is not strictly necessary. However, the ease of pulling in a huge amount of dependent code mak…
That's amazing. I had no idea things were so bad.
It's the ecosystem that's being complained about here it seems, rather than react specifically.
Earlier quoted context omitted.
> A lot of times, lawyers will send out letters without caring how the recipient responds -- they only need to have sent the letter at all to have covered their bases. That is not what happened here though.
Any chance someone at Kik the company wanted to create an npm module and decided the escalation to lawyers was the right way to resolve things? Seems like the lawyer was more interested in getting possession of the name on npm then actually fighting for a trademark. It doesn't even sound like they bothered with a formal cease and desist.
Even on small projects, basic build engineering dictates that you are cognizant of which package versions against which you are building. Furthermore, all packages should be locally cache-isolated on your build server (or local box if you do not have a build server). Building against the most "up-to-date" versions of remote dependencies puts you completely at risk for situations such as this, let alone at the mercy of malicious updates to such remote dependencies.
What sane (pun intended) person would ever build against the most recent version of all packages (including small ones such as this) from a remote build server? Also, for larger (i.e. more than several employees) type operations, how could QA possibly function when building from "most recent version of all packages"?
All these entities that are suffering because of this should immediately fire all their build engineers, because they are not only a reliability concern, but, more critically, a vulnerability concern.