I don't disagree that there might be a security use-case, and regardless of how realistic it is businesses need people to tick boxes (that doesn't seem like something core should worry about?), but what is the actual security risk of an unspec'd map value, or things being referenced and unused? The ocaml (strict) type system allows for this for example with row polymorphic records.
On Tue, Oct 3, 2017 at 1:25 PM Didier <didi...@gmail.com> wrote: > | Spec-tools (https://github.com/metosin/spec-tools) has some tools for > this: the spec visitor (walking over all core specs, e.g. to collect all > registered specs) and map-conformers: fail-on-extra-keys and > strip-extra-keys. > > I understand the core team wanting to take a minimal approach to spec, and > that open is easier to restrict later. But I worry that already in alpha > state, spec is unpractical for many people as is, and Orchestra and > Spec-tools are already needed supplement. > > For instrumentation, it's no big deal, but for specs I think it is. Having > a canonical set of specs accross Clojure shops is a way to form a common > language. If I start having my custom map specs, and so does everyone, I'd > be tempted to say something core is missing. Strict map specs which also > vallidates each key has a registerer spec I think is a glaring omission. > > Having used spec in one of my design, I've had to justify already to 6 > people, some being senior security engineers, why the validation allows for > open keys. Other team members were just confused as to why that was, and > the only argument I had was that Rich doesn't like to break APIs :p. But > I've had to add validation on top to pass security audit. So I think while > not breaking APIs when incrementally adding specs to legacy code is a good > use case, there's the security and safety use case which seems to be shared > by a large swat of Clijurist, and I think spec is in need of a core support > for it. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
