This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-08-02
Channels
- # announcements (14)
- # beginners (133)
- # cider (27)
- # cljs-dev (7)
- # cljsjs (13)
- # clojure (105)
- # clojure-dev (58)
- # clojure-italy (1)
- # clojure-nl (17)
- # clojure-russia (33)
- # clojure-spec (5)
- # clojure-uk (154)
- # clojured (1)
- # clojurescript (35)
- # cloverage (4)
- # cursive (35)
- # datomic (58)
- # duct (8)
- # editors (9)
- # emacs (15)
- # events (1)
- # figwheel (47)
- # figwheel-main (132)
- # hyperfiddle (5)
- # immutant (29)
- # instaparse (21)
- # luminus (3)
- # off-topic (5)
- # onyx (5)
- # overtone (5)
- # pedestal (8)
- # re-frame (7)
- # reagent (6)
- # reitit (3)
- # schema (2)
- # shadow-cljs (178)
- # spacemacs (49)
- # specter (2)
- # sql (1)
- # tools-deps (110)
@alexmiller what do we want to do about that deserialization test?
to me it looks completely useless -- what's the point of a test that checks for deserialisation throwing when we already checked that serialisation is not possible?
I have no problem regenerating the seralised binaries but I don't see much point in maintaining that test
well the idea was to manually construct the object that an attacker could produce that previously was able to run arbitrary code
to verify it doesn’t (still) work
I have been on the fence about maintaining it
right but isn't it just testing that if an attacker produces code that is unserialisable then we can't deserialise it? I may be reading the test wrong
don’t all tests verify something you think is true?
the object is hard-coded and generated from a modified version of the code before the check was introduced iirc
I’d be ok with just commenting it out - I’m not sure that it’s worth the cost of maintenance
I do think it’s a good canary for your change though that the class name has changed - does this mean that new clojure wouldn’t find proxy class files from old clojure?
I can regenerate the classfiles this evening once I get to a machine with java 8 through 11, or I can comment it, I leave it up to you :)
@alexmiller kinda sorta
isn’t that foiling aot then?
which should not be an issue as you interop with proxy objects type hinting the interfaces
it's just that if you have an AOT compiled proxy pre-patch + a JIT compiled proxy post-patch, they won't reuse the same underlying impl
that makes sense to me
stepping back steps further, you might ask whether redefing interfaces is a supported use case at all
it might break code if somebody was crazy enough to type hint a method call using {:tag (class the-proxy-object)}
-- but there's nothing special about it, it's the same situation that would happen for defrecord/detype
just want to make sure we’re not adding scope
seems like redefinition of protocols kind of has the opposite problem - too tied to particular instances rather than names
I think either way the current behaviour is broken: definterface supports realoading but reloading of proxy backed by a reloaded definterface breaks
well I’d rather make everything more reloadable :)
inames is a sorted set so should always hash the same
interfaces is arbitrarily ordered
not sure if it matters given that you’re going to a more fine-grained approach anyways
but it’s different
is that concat doing anything?
wouldn’t just (hash (conj interfaces super)) be sufficient?
an alternative patch I was considering wouldn't change the naming scheme but instead would decide whether to use the cached class or regenerate one
are the interface objects here comparable?
>seems like redefinition of protocols kind of has the opposite problem - too tied to particular instances rather than names I didn't get this btw
in my mental model being tied to instances rather than to names is what we want (speaking about interfaces anyway)
and all the problems we've had till now has been about correctly pointing the names at the latest instances
the problem you run into with protocol redefinition is that records extending those protocol are tied to the old protocol interface class
that is, they are class instance based
so what you're saying is what clojure needs is a meta-object protocol, am I hearing it right? :P
(http://clhs.lisp.se/Body/f_upda_1.htm is what I'm referring to)