Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deno 1.0

deno.land

Post reply on HN
Print view View original

431–440 of 598 posts

Re: Deno 1.0

#431

Post by austincheney »

giorgioz wrote: post #408

I have two questions: 1) How to port a node package to deno? 2) How to keep both a node and deno packages in the same repo? Clearly without packages we are not going to use deno. Also I don't want to switch from well-proven packages like express/koa to an new unknown http server just because it supports deno.

There are some manual things you can do to ensure portability from Node to Deno:

* separate out the Node APIs from the rest of your application logic as much as possible as those will be different unrelated API conventions.

* convert your application from using require to using ES6 modules. This won’t work if you have more that few highly trivial dependencies as Node requires picking one way of importing files and that one way extends to your dependencies as well.

* Node uses callbacks for asynchronous logic where Deno uses promises, so ensure all callback functions are passed by reference so that the difference is an API difference instead of a logic difference.

Re: Deno 1.0

#432

Post by a_humean »

Tade0 wrote: post #409
nojvek wrote: post #393

> TSC must be ported to Rust. If you're interested in collaborating on this problem, please get in touch. This is a massive undertaking. TSC is a moving target. I occasionally contribute to it. It’s a fairly complex project. Even the checker + binder (which is the core of TS) is pretty complex. One idea that comes to mind is to work with Typescript team that they are only using a subset of JS such that tsc can be com…

I wonder how possible it would be to just use this: https://github.com/swc-project/swc It's still not feature-complete, but there aren't any alternatives written in Rust that I know of.

SWC does not do any typechecking. It is equivalent to babel.

Re: Deno 1.0

#433

Post by realharo »

crabmusket wrote: post #403
ecares wrote: post #402

Well, there is a known MITM vuln in Deno by design and the team refuses to fix it soooooo REF: https://github.com/denoland/deno/issues/1063

Lockfiles should be used for production code, as per https://deno.land/manual/linking_to_external_code/integrity_...

Can checksums/hashes be specified directly in the source file?

EDIT: I mean hashes of dependencies.

That is important for single-file scripts, if this is meant to be useful as a bash replacement for scripting.

Having to download two separate files for a script and execute it with special arguments already adds too much friction to that scenario.

Re: Deno 1.0

#435

Post by 1_player »

ecares wrote: post #404
crabmusket wrote: post #403

Earlier quoted context omitted.

Lockfiles should be used for production code, as per https://deno.land/manual/linking_to_external_code/integrity_...

That is not enough at all and there are other attacks! I can't belive in 2020 some people still need to be explained why not enforcing https is a terrible thing! For instance, will a lockfile prevent someone from eavesdropping on the download of a modules through http? If so, please kindly tell me how!

https prevents MITM but doesn't prevent the modules being backdoored or otherwise altered at the source.

I would prefer https-only, sure, but it doesn't buy you very much security.

Re: Deno 1.0

#436

Post by virgilp »

yoz-y wrote: post #416
danShumway wrote: post #347

Earlier quoted context omitted.

> That combined with the 'download random code from any url What protection does NPM actually give you? Sure, they'll remove malware as they find it, but it is so trivially easy to publish packages and updates to NPM, there effectively is no security difference between an NPM module and a random URL. If you wouldn't feel comfortable cloning and executing random Github projects, then you shouldn't feel comfortable ins…

> What protection does NPM actually give you? Dependency version pinning comes to mind. The main difference between this and a random URL is that at least you know that if the module gets bought by a third party, your services or build system won't auto update to some rando's version of the package. IIRC there have been cases when a version was replaced as well. I think this could be fixed quite easily if one could a…

Arguably you can get (even more reliable) version pinning by copying typescript from that random URL & storing it in your own S3 bucket. Sure, you have _some_ work to do, but it's not that much and you 100% control the code from there on.

Re: Deno 1.0

#437

Post by another-dave »

yoz-y wrote: post #416
danShumway wrote: post #347

Earlier quoted context omitted.

> That combined with the 'download random code from any url What protection does NPM actually give you? Sure, they'll remove malware as they find it, but it is so trivially easy to publish packages and updates to NPM, there effectively is no security difference between an NPM module and a random URL. If you wouldn't feel comfortable cloning and executing random Github projects, then you shouldn't feel comfortable ins…

> What protection does NPM actually give you? Dependency version pinning comes to mind. The main difference between this and a random URL is that at least you know that if the module gets bought by a third party, your services or build system won't auto update to some rando's version of the package. IIRC there have been cases when a version was replaced as well. I think this could be fixed quite easily if one could a…

Yeah, basically sounds like they could implement it à la Content Security Policy in the browser and it would be well understood right off the bat.

Or similar to node_modules, have some way to pull your dependency graph & host locally — At least for enterprise-y adoption I imagine that people will want to have _their_ copy of the code and choose when to update it even if in theory the remote code is locked down.

Re: Deno 1.0

#438

Post by haack »

ecares wrote: post #419
DarkWiiPlayer wrote: post #417

Earlier quoted context omitted.

That's really just a HTTP problem though, isn't it? If you use HTTP, you're exposing yourself to MITM attacks; that's on you. Is there any possible way to face this vulnerability without either 1) linking to a resource over HTTP or 2) loading a resource from someone else who linked to another resource over HTTP? Case one is the devs fault for doing it; case two is also the devs fault for not even checking their depen…

well, most of Deno marketing is that it is safe by default. In 2020, not enforcing a secure protocol to share source code is a no go at all. I really don't get your point here defending something that has not made any sence since the end of last decade. Knowingly leaving this kind of things in the codebase totally invalidate Deno being secure. There is not possible discussion in 2020 about https not having to be enfo…

Would you say linux is insecure because a user can download an arbitrary shell script and run it?

I know it's not an identical problem, but it does demonstrate that we probably agree that the onus is on the user to assess the risk of any arbitrary code they run on their machine, including the risk associated with the transport they use to obtain that code.

Funnily enough I actually agree with you that I would prefer to prevent http imports by default. However doing so won't make importing a library secure, and conversely allowing it doesn't mean it is insecure.

As an aside, I noticed you have posted the same one line message about the risk of a MITM attack with http imports 4 times in this thread. You might find it more helpful to contribute to the discussion by explaining why you think that.

Re: Deno 1.0

#439

Post by reaktivo »

pimterry wrote: post #376
batmansmk wrote: post #144

Earlier quoted context omitted.

I thought a lot about it, and it seems as secure as node_modules, because anybody can publish to npm anyway. You can even depend to your non-npm repo (github, urls...) from a npm-based package. If you want to "feel" as safe, you have import maps in deno, which works like package.json. Overall, I think Deno is more secure because it cuts the man in the middle (npm) and you can make a npm mirror with low effort, a simp…

> I thought a lot about it, and it seems as secure as node_modules, because anybody can publish to npm anyway npm installs aren't the same as installing from a random URL, because: * NPM (the org) guarantees that published versions of packages are immutable, and will never change in future. This is definitely not true for a random URL. * NPM (the tool) stores a hash of the package in your package-lock.json, and insta…

This is why I think a content addressable store like IPFS would shine working with Deno

Re: Deno 1.0

#440

Post by speedgoose »

pedalpete wrote: post #44

Does anyone else see the import directly from URL as a larger security/reliability issue than the currently imperfect modules? I'm sure I'm missing something obvious in that example, but that capability terrifies me.

You are not alone, this is very unsafe in my humble opinion.
Post reply on HN