For what it does and what it was designed for, the current NPM central repository system works great. It wasn't meant to be a secure system with evil actors that can't trust eachother, but must work together. It does at least have basic authentication so that an author has to change evil after publishing a successful package. (Or get their password hacked). NPM is a tool for sharing code and information, not for build dependencies for your production servers. Yes we use is that way because it's not been a problem and it's very convenient, but it could be.
I'm designing a more secure system based on the immutable concepts of git trees, but there are other hard parts to solve related to discovery and the lack of central control. (plus I've been busy with other stuff) Like I said before, you can get the security benefits of this new system by using git submodules or adding your dependencies to your parent git tree, but it's a lot of work to keep things up to date manually. You have to remember to check for updates on some schedule and review all the changes to make sure no backdoors or bugs get introduced in the changes. On Mon, Dec 30, 2013 at 10:16 AM, Alain Mouette <[email protected]>wrote: > Em 30-12-2013 14:10, Mark Hahn escreveu: > > > and people start to depend on it, it should be hard to remove it. > > Are you referring to some central authority you would have to petition > to be allowed to remove? I can't imagine any other process that could be > implemented to stop me from removing my module. > > > In fact that is the essense of Public Licences like MIT > > A working solution would be to work like a Version control system: move > that module's version to some frozen/not recomended/whatever branch but > keep it there because some people may be using it. Either in production or > for study only > > That is very close to Github's working, which is already the repositoy of > choice... > > Alain > > > > In other words a computer can't make things harder except maybe to make > you type "I want to unpublish this module" a thousand times. And then some > clever person might figure out how to script that. :-) > > > On Mon, Dec 30, 2013 at 4:04 AM, Richard Marr <[email protected]>wrote: > >> > i'm not disagreeing with you but when you say things like "change in >> behavior" you're sort >> > of sugar coating the fact that packages will fail to install at a >> greater rate than they do now. >> >> I think the core problem there isn't that removing force-republish >> would encourage greater use of unpublish, it's that npm allows anyone to >> unpublish so easily that it can be done for any reason they like... whether >> for a serious reason (legal issues, malware, etc) or on a whim, or drunk, >> or in a fit of anger over some community drama. >> >> I don't want to go too far down the road of conflating these two >> problems, but I do think it's currently far too easy to unpublish modules. >> If a module has been provided to the community, and people start to depend >> on it, it should be hard to remove it. >> >> Perhaps it'd be more natural to talk about making unpublishing hard >> before we talk about removing mutability. >> >> BTW. Thanks Mikael, and everyone else who's contributed to this thread. >> I'm certainly learning new things. >> >> Rich >> >> >> On 23 December 2013 00:36, Mikeal Rogers <[email protected]> wrote: >> >>> >>> On Dec 20, 2013, at 2:45AM, Richard Marr <[email protected]> >>> wrote: >>> >>> Mikeal, >>> >>> To sum up the way I currently see it, switching to immutable packages >>> would: >>> >>> * solve a whole class of subtle problems caused by unrequested code >>> changes >>> >>> >>> sure. >>> >>> * allow aggressive caching, reducing the cost of the npm registry and >>> making npm use faster for most use cases >>> >>> >>> this isn't an issue. the cache control can, and must, be proactively >>> invalidated on _changes from the database for document urls anyway, it's >>> trivial to do the same for tarball changes. it can literally cache forever >>> so long as it responds to pro-active invlaidation. >>> >>> * change behaviour only for version-locked dependencies when that >>> (and only that) specific patch is unpublished >>> >>> >>> i'm not disagreeing with you but when you say things like "change in >>> behavior" you're sort of sugar coating the fact that packages will fail to >>> install at a greater rate than they do now. this "change in behavior" is >>> not trivial, there is no notice sent to someone when their package can no >>> longer resolve a dependency, it will usually require someone to see a >>> failed install, report an issue, and the maintainer to intervene. the only >>> way to avoid this is to never version lock your dependencies which we know >>> people don't do and that there are tens of thousands of packages in npm >>> today with some number of version locked deps. >>> >>> >>> That's two HUGE wins, and one downside. The downside can be reduced >>> into obscurity being very rare by making it hard to unpublish, so that >>> authors only bother to do it if they genuinely need to... i.e. serious >>> legal or security reasons... cases where it's actually the right thing to >>> do to break dependent apps. >>> >>> >>> From what I've heard so far, force republish is mainly used to keep >>> patch numbers slow and sequential, which seems like a much lower priority >>> requirement than introducing behaviour changes silently and unexpectedly >>> into dependent apps. >>> >>> Please do contribute more if you have more time... I do want to >>> understand the root cause of your replies, and please set me straight if >>> I've missed or misunderstood any of your comments >>> >>> >>> I don't misunderstand you, I don't even think that we disagree on what >>> would or would not happen and the potential wins and loses. What I don't >>> think we are in alignment about is the severity of the up and down sides of >>> the available options. >>> >>> We don't get a clean slate. At this point in time we can't afford to >>> make changes that might break parts of the existing ecosystem even if it >>> makes the future a little better. We can only really entertain strategies >>> that make current and future packages less prone to these problems without >>> the potential to break existing ones. >>> >>> >>> Rich >>> >>> >>> >>> >>> On 19 December 2013 23:49, Mikeal Rogers <[email protected]>wrote: >>> >>>> They won't :) >>>> >>>> Oh well :) >>>> >>>> It's better for things to work than for everyone to agree. >>>> >>>> -Mikeal >>>> >>>> On Dec 19, 2013, at 3:47PM, Alex Kocharin <[email protected]> wrote: >>>> >>>> >>>> Well okay, just one silly argument. How will these people know that >>>> they're doing the wrong thing if nothing will ever break? :) >>>> >>>> >>>> 20.12.2013, 03:42, "Mikeal Rogers" <[email protected]>: >>>> >>>> First off, if someone version locks they are already doing the wrong >>>> thing. Saying "make my package ignore bugfix releases" is almost always the >>>> wrong thing. In this case it's better to keep their package working for >>>> them since they clearly don't know what they're doing. >>>> >>>> If they **really** didn't want any changes coming in that they didn't >>>> know about then they had two other options that would still work: 1) check >>>> the module in to git if they are deploying at app or shrinkwrap publish if >>>> it's not something being deployed 2) stick the md5 in package json to >>>> ensure nobody can give them another tarball for the same version. >>>> >>>> We have to deal with what people are doing in practice when they don't >>>> necessarily understand the best practice and it's especially important when >>>> you maintain a common dependency to do what you can to keep everyone who >>>> relies on you working even when they don't do things correctly. >>>> >>>> -Mikeal >>>> >>>> >>> -- >>> -- >>> Job Board: http://jobs.nodejs.org/ >>> Posting guidelines: >>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines >>> You received this message because you are subscribed to the Google >>> Groups "nodejs" group. >>> To post to this group, send email to [email protected] >>> To unsubscribe from this group, send email to >>> [email protected] >>> For more options, visit this group at >>> http://groups.google.com/group/nodejs?hl=en?hl=en >>> >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "nodejs" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> -- >>> -- >>> Job Board: http://jobs.nodejs.org/ >>> Posting guidelines: >>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines >>> You received this message because you are subscribed to the Google >>> Groups "nodejs" group. >>> To post to this group, send email to [email protected] >>> To unsubscribe from this group, send email to >>> [email protected] >>> For more options, visit this group at >>> http://groups.google.com/group/nodejs?hl=en?hl=en >>> >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "nodejs" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> >> >> -- >> Richard Marr >> -- >> -- >> Job Board: http://jobs.nodejs.org/ >> Posting guidelines: >> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines >> You received this message because you are subscribed to the Google >> Groups "nodejs" group. >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> For more options, visit this group at >> http://groups.google.com/group/nodejs?hl=en?hl=en >> >> --- >> You received this message because you are subscribed to the Google Groups >> "nodejs" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > > --- > You received this message because you are subscribed to the Google Groups > "nodejs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > > --- > You received this message because you are subscribed to the Google Groups > "nodejs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
