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

441–450 of 598 posts

Re: Deno 1.0

#441

Post by haack »

nkozyra wrote: post #169
polishdude20 wrote: post #163

Earlier quoted context omitted.

But isn't this an inherent problem in software development that is really super hard to not do? Let's say you are deciding how to make node when it was first conceived and how it would work. You've made decisions about how the thing fundamentally works. Then after using it and developing for it many years and after having millions of critical software projects dependant on it, you slowly start to see the shortcomings…

I think the answer is a break in backwards compatibility on a major version release. People in JS/frontend world are willing to drop the world for the latest new thing, I see this as less jarring than, say, Python 2 -> Python 3.

I find it amusing that you use the example of Python 2 -> Python 3, a breaking change in a widely used language, that has famously been very difficult and long for organisations to deal with.

Compare that with javascript which has never had a breaking change. On top of that Typescript is a backwards compatible superset of javascript.

More to the point, Ryan has a humble explanation of what regrets he has about Node.js[1], why they exist and in some cases why there isn't an easy fix.

The point that I assume you're making, that sometimes it is better to spend significant energy to fix something, rather than throwing the baby out with the bath water, is a good one. However I'd suggest this is not one of those cases.

[1] https://www.youtube.com/watch?v=M3BM9TB-8yA

Re: Deno 1.0

#442

Post by ecares »

haack wrote: post #438
ecares wrote: post #419

Earlier quoted context omitted.

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…

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

Linux is not branded as a "Secure thing" right? Here Deno is building marketing on something inacurate.

Re: Deno 1.0

#443

Post by yoz-y »

virgilp wrote: post #436
yoz-y wrote: post #416

Earlier quoted context omitted.

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

Well, I suppose they do (or will) provide a self hosted version of the registry. Like npm does.

Re: Deno 1.0

#444

Post by richthegeek »

tuukkah wrote: post #413
regularfry wrote: post #405

Earlier quoted context omitted.

So it's reimplemented chmod and iptables?

Typically, chmod and iptables are not used to restrict applications. Applications are restricted by virtual machines, containers, sandboxes, AppArmor profiles, SELinux policies…

chmod/chown has been the de facto (if not de jure) method securing LAMP stacks for as long as I have been alive. Not that I recommend taking the advice of a LAMP stack too seriously :)

Re: Deno 1.0

#445

Post by ecares »

realharo wrote: post #433
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_...

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.

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

That would defeat their point actually :D malicious attacker could inject any script by hacking on the network and replace modules that are downloaded through http

Re: Deno 1.0

#446

Post by veidr »

fermienrico wrote: post #345
fiddlerwoaroof wrote: post #340

Earlier quoted context omitted.

The whole idea of a URL is that it’s a standardized way of identifying resources in a universally unique fashion: if I call my utility library “utils”, I’m vulnerable to name collisions when my code is run in a context that puts someone else’s “utils” module ahead of mine on the search path. If my utility module is https://fwoar.co/utils then, as long as I control that domain, the import is unambiguous (especially if…

Allow me to provide an extremely relevant example (medium sized code base). About 100 python files, each one approximately 500-1000 lines long. Imagine in each one of these files, there are 10 unique imports. If they are URLs (with version encoded in the URL): - How are you going to pin the dependencies? - How do you know 100 files are using the same exact version of the library? - How are you going to refactor depen…

The Deno docs recommend creating a deps.ts file for your project (and it could be shared among multiple projects), which exports all your dependencies. Then in your application code, instead of importing from the long and unwieldy external URL, import everything from deps.ts, e.g.:

    // deps.ts
    export {
      assert,
      assertEquals,
      assertStrContains,
    } from "https://deno.land/std/testing/asserts.ts";
And then, in your application code:

    import { assertEquals, runTests, test } from "./deps.ts";
https://deno.land/manual/linking_to_external_code#it-seems-u...

Re: Deno 1.0

#447

Post by HeavyStorm »

jeswin wrote: post #309
bgdam wrote: post #151

Earlier quoted context omitted.

See the thing about the sandbox is that it's only going to be effective for very simple programs. If you're building a real world application, especially a server application like in the example, you're probably going to want to listen on the network, do some db access and write logs. For that you'd have to open up network and file access pretty much right off the bat. That combined with the 'download random code fro…

> That combined with the 'download random code from any url and run it immediately', means it's going to be much less secure than the already not-that-secure NPM ecosystem. What deno does is move package management away from the framework distribution. This is great - one thing I hate about node is that npm is default and you get only as much security as npm gives you. (You can switch the npm repo, but it's still the…

But if Lib itself imports from "unsecure-location.com" deno will access that location and get that file.

Re: Deno 1.0

#448

Post by Rotareti »

thebradbain wrote: post #94
xg15 wrote: post #87

Earlier quoted context omitted.

How would this work with transitive dependencies? Sure I can control which parts I import myself, but how do I keep a vendored file from pulling in another URL a level deeper?

Unlike node, recommended deno practice is to check-in your dependencies to the VCS. > Production software should always bundle its dependencies. In Deno this is done by checking the $DENO_DIR into your source control system, and specifying that path as the $DENO_DIR environmental variable at runtime. https://deno.land/manual/linking_to_external_code

    du -hs node_modules
    
    1.7G node_modules

Re: Deno 1.0

#449

Post by tuukkah »

richthegeek wrote: post #444
tuukkah wrote: post #413

Earlier quoted context omitted.

Typically, chmod and iptables are not used to restrict applications. Applications are restricted by virtual machines, containers, sandboxes, AppArmor profiles, SELinux policies…

chmod/chown has been the de facto (if not de jure) method securing LAMP stacks for as long as I have been alive. Not that I recommend taking the advice of a LAMP stack too seriously :)

If the de facto method refers to "chmod 777", I wouldn't call that securing ;-)

But indeed, if there is a separate user account for the application, then chmod can be used for some control to its access to files and directories.

Re: Deno 1.0

#450

Post by uryga »

noahtallen wrote: post #356
uryga wrote: post #89

Earlier quoted context omitted.

> I don't understand why Microsoft doesn't have their own native TypeScript runtime engine by now what would they do with it? ship it in Edge? great, now some small fraction of users can run TS natively. but most can't, so everyone would still transpile to JS anyway... it could work if Google did it, but i don't think MS has enough market share to have an influence here

It would work for server-side tools (like Deno). For example, cloud functions on various cloud platforms often support TS.

yeah but i don't think MS uses TS-on-the-server enough or has enough Azure TS users to justify putting in the effort
Post reply on HN