Gemnasium can alert you when your npm dependencies are not up-to-date: https://gemnasium.com
On Mon, Dec 30, 2013 at 4:11 PM, Mark Hahn <[email protected]> wrote: > > You have to remember to check for updates on some schedule > > It would be nice to have a "watch" feature that would email you about > updates and even tell you when the contents of an existing version change. > This would go a long way to all the concerns on this thread. In other > words allow mutability but force transparency and notifications. > > > On Mon, Dec 30, 2013 at 11:35 AM, Tim Caswell <[email protected]> wrote: > >> 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. >> > > -- > -- > 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 a topic in the > Google Groups "nodejs" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/nodejs/fDs5-Wl3I8c/unsubscribe. > To unsubscribe from this group and all its topics, 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.
