231–240 of 520 posts
Wonder if npm, Inc. would view a decentralized registry as a threat to their business model?
Earlier quoted context omitted.
Already counting down the days before yarn is considered old and broken and people are recommending switching to the next hot package manager/bundler...
It badfles me that technologists commonly complain about new technology. As far as I can tell your complaint boils down to “people should stop making and switching to new things”.. I find it hard to understand why someone with this attitude would be a technologist of any kind, and I find the attitude really obnoxious.
Earlier quoted context omitted.
Because it is... It's mollochian complexity heaped on top of layers of excrement and ducktape, and we have collectively entered a state of mass Stockholm Syndrome about the situation. I really would love to ditch web dev and all its myriad tendrils, and go back to native desktop software.
Somehow i imagine a native C-Desktopdev and a Webdeveloper meeting in No-Mans Land each party escaping from its own nightmare with that line on the lips, starting with a "Dont run into this direction-"
It seems to me that if packages "disappear" from upstream, it shouldn't have any effect other than preventing an update due to the missing dependency.
PSA: Please be cautious because this is an excellent opportunity for taking over packages and injecting malware by malicious people. Example: https://www.npmjs.com/package/duplexer3 which has 4M monthly downloads just reappeared, published by a fresh npm user. They published another two versions since then, so it's possible they've initially republished unchanged package, but now are messing with the code. Previously…
And all this is happening just as after the public release of a serious exploit which allows malicious code to do all sorts of nefarious things when it is somehow installed on the target machine . Hmm. Given that there's hints, at least, that the problems were caused by some particular developer's actions, I wonder about the security model for package-managed platforms altogether now. If I were a big cybercrime ring,…
Although, I've never considered this in the case of an actual attack. It would make sense to actually fingerprint the entire source tree and record this too somewhere, so when you build it you know you are getting the right thing. Teapot basically defers this to git.
Earlier quoted context omitted.
How does RubyGems handle a package being removed and replaced by a different (and maybe malicious) actor? Not allow a package to be deleted? Block the package name from being claimed by someone else?
From http://help.rubygems.org/kb/gemcutter/removing-a-published-r... : > Once you've yanked all versions of a gem, anyone can push onto that same gem namespace and effectively take it over. This way, we kind of automate the process of taking over old gem namespaces.
Earlier quoted context omitted.
I’m pretty sure they’re referencing the Byrds song and not the Bible directly: https://m.youtube.com/watch?feature=youtu.be&v=pKP4cfU28vM
No. The Byrds song, which is itself an excerpt/phrase of Ecclesiastes, does not have phrases like " and a time to pluck up that which is planted "
This may be a stupid question - I'm not that familiar with NPM or modern javascript development so forgive me, but does it not allow storing your dependencies locally? Is that not considered best practice? Just download your entire dependency tree and don't touch it unless you have to. It seems to me that if packages "disappear" from upstream, it shouldn't have any effect other than preventing an update due to the mi…
- The missing packages can be replaced by someone who wasn't the original package author (e.g. a malicious hacker) - It's not easy to catch this ^^^ because NPM doesn't have support for signing versions in your project's dependency configuration... (I bet it will after this.) - Almost every modern website has a dependency on NPM somewhere in their build chain - NPM being down means loads of sites can't deploy properly
So yeah. This may be a really big deal.
Earlier quoted context omitted.
You don't need a full blockchain for this: the relevant property is (somewhat tautologically) that it's an append-only data structure. By convention, everyone processing the blockchain looks to make sure that the new blockchain they get is a descendant of the previous blockchain they already have. There are lots of other structures that work like this. Git is one - when git fetches a branch, git will check whether th…
> By convention, everyone processing the blockchain looks to make sure that the new blockchain they get is a descendant of the previous blockchain they already have. This is not true. Bitcoin-esque blockchains are NOT append only. The only thing clients do is: 1) ensure the blockchain they have received is valid, and 2) that it is longer (more total PoW). If those conditions are met, they will consider that new chain…
The key thing here is that there is an obvious central authority for software releases (the NPM registry, or GitHub, or Debian, or whatever), so proof-of-work-style systems are overkill because you don't fundamentally need decentralization. You could imagine some sort of decentralized first-come-first-serve software registry, but that doesn't seem obviously better than a central one.