Fair enough. However I still think "distance" could solve the typo problem. As in evanzc/elm-graphics would not be allowed as its too "close" to an existing package name.
On Saturday, June 11, 2016 at 2:29:05 PM UTC-6, Joey Eremondi wrote: > > elm-package could require package names to be at a certain "distance" from >> one another > > > That still doesn't resolve the problem of running arbitrary code. If our > community gets big enough that I don't know and trust every author from > this mailing list, we need a way to stop people from being malicious. > Elm is about reliability. We're trying to be better than JavaScript, so > the security needs to be airtight. > > Usernames increase the risk, I'd say. Someone could make > evanzc/elm-graphics, and the typo is a lot harder to spot at first glance. > And by your method, if evanzc was a legitimate elm developer, they'd need > to make a whole new github account just to make a package. > > The name collisions aren't the problem. Running arbitrary untrusted code > at compile-time is. We can avoid this, but it needs to be central to the > design, not an afterthought. > > On Sat, Jun 11, 2016 at 1:18 PM, Isaac Shapira <[email protected] > <javascript:>> wrote: > >> @Maxime Call it what you will. Pre-processor, Macro, Template, they have >> different meanings but solve the same problem, generate code rather than >> write tedious code when possible. Regardless it going to mean some edits to >> the Haskell side, since it needs some kind of compile time support, as well >> as package management support. >> >> @Joey I understand the concern, but I think its worth the risk. Thank and >> typo-squatting seems like it could be resolved another way. elm-package >> could require package names to be at a certain "distance" from one another. >> That and since user names are required in the package name, the risk is >> much lower. >> >> >> On Saturday, June 11, 2016 at 2:03:21 PM UTC-6, Maxime Dantec wrote: >>> >>> Jumping in ! I said in the github issue that I was in favour of macros, >>> but macros imply hacking the (haskell) core of the compiler. Wouldn't >>> preprocessor be a better description ? >>> >>> On Saturday, June 11, 2016 at 9:39:28 PM UTC+2, Isaac Shapira wrote: >>>> >>>> @mgold <https://github.com/mgold> If you are suggesting that tedious >>>> to write elm code should be addressed by a distributed series of >>>> independent browser based online code generators, I'm going to say that's >>>> not a real solution. I don't want to go to a different set of browser >>>> bookmarks for different common derivable code scenarios. Nor do I want >>>> code >>>> generation outside of my build process. >>>> >>>> If you are suggesting using things like json-to-elm inside of a build >>>> process, then we are potentially in some kind of module loader hell. >>>> json-to-elm looks like it uses python for generation, so now python is >>>> in the stack, and there is no consistent standard for how these >>>> distributed >>>> set of tools should work. If we wish to address 10+ boilerplate heavy >>>> scenarios, we now have to custom install and rig together disparate apis >>>> of >>>> these different generation tool into our build. And once all that is >>>> working, essentially we just invented fraken macros, where macro code is >>>> separate outside of .elm files. >>>> >>>> A proper macro system seems like the only solution to me atm. That's >>>> not to say there is only one way of going about it. >>>> >>>> One way that might address the "One Language" and maintainability >>>> concern, is to have macros that are outside of Elm. As in elm-make >>>> provides >>>> a facility to pipe code into an external process for expansion. Then type >>>> checks the expanded code. This could also mean that elm-package now needs >>>> the ability to let code generator authors package an executable with any >>>> surrounding elm files. I feel this could also discourage the abuse that >>>> can >>>> come from macros, as there are more barriers to set up the external code >>>> gen process and wire it in. >>>> >>>> On Saturday, June 11, 2016 at 1:26:55 PM UTC-6, Isaac Shapira wrote: >>>>> >>>>> Continuing the discussion started here: >>>>> >>>>> https://github.com/elm-lang/elm-compiler/issues/1413 >>>>> >>>> -- >> You received this message because you are subscribed to the Google Groups >> "Elm Discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" 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/d/optout.
