> 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 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.
