> These are the kind of things documentation absolutely can solve. I would agree that people ignoring recommendations in the documentation, or ignoring the docs completely, is something we can't solve with more documentation
Ah, yes - I was only referring to the latter concern. But (from looking through proposals) it seems like there are a lot of general usability issues that could be addressed through documentation. > In my experience I haven't encountered any cases where people were using crypto incorrectly, but that may just be luck on my part. Or bad luck on my part? Outside of Plug, I'm not sure I've seen it used securely :P > I hope this means you'll take the discussion to the OTP team! Yes! Though, if I'm going to the OTP team my proposal will probably be a lot different. So I probably won't start the discussion there until I've had time to think about the best way to approach the issue in Erlang itself. On Mon, May 14, 2018 at 3:33 PM Paul Schoenfelder < paulschoenfel...@gmail.com> wrote: > > I disagree that documentation improvements and best practices would > solve these problems. In practice, I definitely haven't seen that to be the > case. > > In my own experience, the primary issue I ran into with `crypto` was the > inability to understand why certain arguments would result in `badarg` - I > had to go fishing around in the C source to figure it out. These are the > kind of things documentation absolutely can solve. I would agree that > people ignoring recommendations in the documentation, or ignoring the docs > completely, is something we can't solve with more documentation, but the > crypto module in particular is not one you can just use blindly without at > least skimming the docs, it is not an easy module to use. Warnings are very > clearly presented in the Erlang manual, and along with specific > recommendations in function docs (say for example `encrypt`), I suspect few > would be able to dive in without having read one or the other, if not both. > I don't think it should be a goal to prevent people from using old > encryption/hashing algorithms, simply for compatibility reasons, so if > people want to ignore recommendations, I think you have to assume that it's > for a reason. In my experience I haven't encountered any cases where people > were using crypto incorrectly, but that may just be luck on my part. > Regardless, if nothing else I think documentation is the first effort that > should be undertaken - the existing docs are barely useful. > > > Although, unfortunately, a new interface doesn't really solve the > problem of the developer still needing to figure out which interface to use. > > With `rand` and `random`, there is a compiler warning when you use the > deprecations, the same would apply with a new crypto module, which > effectively guides you to the right interface. Likewise, the documentation > would need to state at the top that the module is deprecated and to refer > to the new interface moving forward. I think the issue of developers trying > to figure out which interface to use is only a problem when you either > introduce a third-party library, or an extension to Elixir core, as > compiler warnings can't be used to drive people towards the "new" module. > > > I'll start poking around for potential solutions elsewhere. > > I hope this means you'll take the discussion to the OTP team! They don't > bite! I suspect the primary reason it hasn't gotten as much attention is > simply time and priorities, having someone interested in driving > improvements forward would likely be very welcome indeed. > > Paul > > > On Mon, May 14, 2018 at 3:13 PM, Griffin Byatt <byatt.grif...@gmail.com> > wrote: > >> > it doesn't change the fact that both its documentation and the >> handling of invalid arguments should be improved, and that should happen >> _in_ Erlang, not anywhere else. A lot of the issues you have mentioned >> could be solved simply by improving the documentation to be explicit about >> what represents "good" selections vs "bad", what gotchas to be aware of, etc >> >> Agreed that documentation improvements and argument handling should >> happen in Erlang. I disagree that documentation improvements and best >> practices would solve these problems. In practice, I definitely haven't >> seen that to be the case. >> >> > I see no reason why the OTP team wouldn't be amenable to a new crypto >> interface which is safer and easier to use, or at least open to discussion >> about it. >> >> Perhaps that is the best solution. Although, unfortunately, a new >> interface doesn't really solve the problem of the developer still needing >> to figure out which interface to use. >> >> Anyway, I appreciate the input :) I'll start poking around for potential >> solutions elsewhere. >> >> >> >> On Monday, May 14, 2018 at 2:02:29 PM UTC-4, Paul Schoenfelder wrote: >>> >>> I think despite that Erlang has to keep some APIs for legacy reasons, it >>> doesn't change the fact that both its documentation and the handling of >>> invalid arguments should be improved, and that should happen _in_ Erlang, >>> not anywhere else. A lot of the issues you have mentioned could be solved >>> simply by improving the documentation to be explicit about what represents >>> "good" selections vs "bad", what gotchas to be aware of, etc. Erlang has >>> also evolved APIs in the past by introducing new modules, and slowly >>> deprecating the old (see `rand` and `random`); I see no reason why the OTP >>> team wouldn't be amenable to a new crypto interface which is safer and >>> easier to use, or at least open to discussion about it. I just don't think >>> this is a good fit for the Elixir standard library, or even a third-party >>> library - this is a prime case of where contributing things upstream to OTP >>> benefits everyone, even if its a slower process. I would try opening an >>> issue there first, getting some discussion going, and if it fails to gain >>> traction, reviving this thread to see what people think. >>> >>> Paul >>> >>> >>> On Mon, May 14, 2018 at 1:40 PM, Griffin Byatt <byatt....@gmail.com> >>> wrote: >>> >>>> My concern with leaving it as a library is primarily that the onus is >>>> still on the developer to figure out which library to choose, so it doesn't >>>> really alleviate the issue. As it stands, developers already have >>>> out-of-the-box crypto tools when they are using Elixir, but they aren't the >>>> easiest or most secure to use. >>>> >>>> I *do* think that keeping it minimal is important. Non-basic features >>>> could absolutely be relegated to a library. But I don't know of any >>>> languages without some crypto support, and, as a secure/modern language, I >>>> think Elixir is in a good position to offer a saner API. >>>> >>>> (Only somewhat related) I also think that any non-core crypto library >>>> would do better to wrap libsodium than Erlang's crypto module. >>>> >>>> On Mon, May 14, 2018 at 1:02 PM Tallak Tveide <tal...@gmail.com> wrote: >>>> >>>>> Why shouldnt it start out as a library, then if it proves useful >>>>> discuss whether to include in elixir core? >>>>> >>>>> My feeling is that this belongs outside a language, Erlang has too >>>>> much stuff included. This was probably the right call back when Erlang >>>>> didnt have package managers, but elixir has great package support... >>>>> >>>>> -- >>>>> You received this message because you are subscribed to a topic in the >>>>> Google Groups "elixir-lang-core" group. >>>>> To unsubscribe from this topic, visit >>>>> https://groups.google.com/d/topic/elixir-lang-core/J-Idvs6ije8/unsubscribe >>>>> . >>>>> To unsubscribe from this group and all its topics, send an email to >>>>> elixir-lang-co...@googlegroups.com. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/elixir-lang-core/018f200b-6586-4c53-b3c9-2addc069a73b%40googlegroups.com >>>>> . >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "elixir-lang-core" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to elixir-lang-co...@googlegroups.com. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/elixir-lang-core/CAMURSkG0bMQ48%2BKncciXdj7ugrmCSe4pur%2BCTGWh7JhHvofYZA%40mail.gmail.com >>>> <https://groups.google.com/d/msgid/elixir-lang-core/CAMURSkG0bMQ48%2BKncciXdj7ugrmCSe4pur%2BCTGWh7JhHvofYZA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "elixir-lang-core" group. >> > To unsubscribe from this group and stop receiving emails from it, send an >> email to elixir-lang-core+unsubscr...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/ab2aec1a-1e2c-4be7-84e1-8862cf011fa7%40googlegroups.com >> <https://groups.google.com/d/msgid/elixir-lang-core/ab2aec1a-1e2c-4be7-84e1-8862cf011fa7%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to a topic in the > Google Groups "elixir-lang-core" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/elixir-lang-core/J-Idvs6ije8/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > elixir-lang-core+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/CAK%3D%2B-TsQnAoJ68V2jxjdMafbNkF%3DuMdk4H3GSqn0787EcYE%2B6Q%40mail.gmail.com > <https://groups.google.com/d/msgid/elixir-lang-core/CAK%3D%2B-TsQnAoJ68V2jxjdMafbNkF%3DuMdk4H3GSqn0787EcYE%2B6Q%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAMURSkHf1nV24%3D_w%2BG50beaVjfAzwKuFDKTGm17gJ%3D4hu9Cevw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
