Blame for contracts on applicable serializable structs

[Philip McGrath]

I'm confused about why the following program is blaming the server for the client's misuse of an applicable struct instance. More generally, I've tried doing this in several different ways, and I can't figure out how to make applicable structs that are still protected by contracts after deserialization and blame the client module for misusing them.

Thanks,

Philip

#lang racket

(module server racket

  (require racket/serialize)

  (provide (contract-out

            [adder (-> natural-number/c (-> natural-number/c

                                            natural-number/c))]))

  (struct adder (base)

    #:property prop:procedure

    (λ (this x)

      (+ (adder-base this) x))

    #:property prop:serializable

    (make-serialize-info (λ (this) (vector (adder-base this)))

                         #'deserialize-info:adder-v0

                         #f

                         (or (current-load-relative-directory)

                             (current-directory))))

  (define/contract make-adder

    (-> natural-number/c (-> natural-number/c

                             natural-number/c))

    adder)

  (define deserialize-info:adder-v0

    (make-deserialize-info make-adder

                           (λ () (error 'adder

                                        "can't have cycles"))))

  (module+ deserialize-info

    (provide deserialize-info:adder-v0)))

  

(require 'server racket/serialize)

((deserialize (serialize (adder 5))) 'not-a-number)

[Matthias Felleisen]

On Jul 23, 2017, at 8:54 PM, Philip McGrath <philip....@gmail.com> wrote:

I'm confused about why the following program is blaming the server for the client's misuse of an applicable struct instance. More generally, I've tried doing this in several different ways, and I can't figure out how to make applicable structs that are still protected by contracts after deserialization and blame the client module for misusing them.

Thanks,

Philip

#lang racket

(module server racket

  (require racket/serialize)

  (provide (contract-out

            [adder (-> natural-number/c (-> natural-number/c

                                            natural-number/c))]))

  (struct adder (base)

    #:property prop:procedure

    (λ (this x)

      (+ (adder-base this) x))

    #:property prop:serializable

    (make-serialize-info (λ (this) (vector (adder-base this)))

                         #'deserialize-info:adder-v0

                         #f

                         (or (current-load-relative-directory)

                             (current-directory))))

  (define/contract make-adder

    (-> natural-number/c (-> natural-number/c

                             natural-number/c))

    adder)

You defined make-adder with a contract. As far as it is concerned, its contract is with the surrounding module, which is server. Hence if it is misapplied, the server broke the contract of always protecting its entry channels (with a natural-number/c test). 

  (define deserialize-info:adder-v0

    (make-deserialize-info make-adder

                           (λ () (error 'adder

                                        "can't have cycles"))))

  (module+ deserialize-info

    (provide deserialize-info:adder-v0)))

  

(require 'server racket/serialize)

((deserialize (serialize (adder 5))) 'not-a-number)

--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Philip McGrath]

Aha — so it isn't really an issue with serialization at all. If I (now) understand this correctly, when a function produces a contracted higher-order result, it is the responsibility of the caller of the original function to ensure that the result function is always applied to appropriate arguments. That would explain why this version blames intermediary:

#lang racket

(module server racket

  (provide (contract-out

            [adder (-> natural-number/c (-> natural-number/c

                                            natural-number/c))]))

  (struct adder (base)

    #:property prop:procedure

    (λ (this x)

      (+ (adder-base this) x))))

(module intermediary racket

  (require (submod ".." server))

  (provide add5)

  (define add5

    (adder 5)))

(require 'intermediary)

(add5 'not-a-number)

I had previously intuited that the obligation would be on the caller of the result function, whoever that might be.

When serialization is in the mix, is there a correct way for server to protect itself from instances of adder being abused after they are deserialized? 

-Philip

To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscribe@googlegroups.com.

[Matthias Felleisen]

On Jul 23, 2017, at 9:43 PM, Philip McGrath <phi...@philipmcgrath.com> wrote:

Aha — so it isn't really an issue with serialization at all. If I (now) understand this correctly, when a function produces a contracted higher-order result, it is the responsibility of the caller of the original function to ensure that the result function is always applied to appropriate arguments. That would explain why this version blames intermediary:

#lang racket

(module server racket

  (provide (contract-out

            [adder (-> natural-number/c (-> natural-number/c

                                            natural-number/c))]))

  (struct adder (base)

    #:property prop:procedure

    (λ (this x)

      (+ (adder-base this) x))))

(module intermediary racket

  (require (submod ".." server))

  (provide add5)

  (define add5

    (adder 5)))

(require 'intermediary)

(add5 'not-a-number)

I had previously intuited that the obligation would be on the caller of the result function, whoever that might be.

A contract is always between two parties.  For define/contract, it’s the definition and the surrounding module (which is btw a nested contract party). If a party promises to always apply some function to an odd number (say) but then hands out the function to other parties — without protection — it is its fault if the function is misused (abused). 

For module exports, it’s obviously the module and its client(s). Here server and intermediary enter into a contract that obliges the latter to apply adder to a natural number and the function that it creates also to an N. The intermediary module uses add5 correctly but then hands out the result w/o protection. So when the client (main module) misuses add5, intermediary must be blamed. It promised to hand an N to the (curried) second argument of adder and didn’t. — The fix is to either not hand out add5 or to equip it with a contract so that the client (main) module is also obliged to call it with an N. 

At some point I wrote all this up for the contract doc (as the opening paragraphs). I can’t see it right now. 

When serialization is in the mix, is there a correct way for server to protect itself from instances of adder being abused after they are deserialized? 

Serialization is semantically the identify function. I can’t see how it plays a role. 

[Matthias Felleisen]

[replying to myself]

> On Jul 23, 2017, at 9:58 PM, Matthias Felleisen <matt...@ccs.neu.edu> wrote:
>
>
> At some point I wrote all this up for the contract doc (as the opening paragraphs). I can’t see it right now.

Still there:

http://docs.racket-lang.org/guide/contract-boundaries.html

[Philip McGrath]

Here is the problem with serialization, without my attempts to mitigate it:

#lang racket

(module server racket

  (require racket/serialize)

  (provide (contract-out

            [adder (-> natural-number/c (-> natural-number/c

                                            natural-number/c))]))

  (serializable-struct adder (base)

    #:property prop:procedure

    (λ (this x)

      (+ (adder-base this) x))))

(require 'server racket/serialize)

;; would report a contract violation in terms of adder

;; and blame this module

;((adder 5) 'not-a-number)

;; reports a contract violation in terms of +

((deserialize (serialize (adder 5))) 'not-a-number)

-Philip

[Matthias Felleisen]

I see. Not surprisingly serialization strips the contract of (structural) functions as you can see with this slightly different example: 

#lang racket

(module server racket

  (require racket/serialize)

  (provide (contract-out

            [adder (-> natural-number/c (-> natural-number/c natural-number/c))]))

  

  (serializable-struct adder (base)

    #:property prop:procedure

    (λ (this x)

      (+ (adder-base this) x))))

(require 'server racket/serialize)

;; would report a contract violation in terms of adder

;; and blame this module

;((adder 5) 'not-a-number)

;; reports a contract violation in terms of +

(define f (adder 5))

(with-handlers ((exn? (λ (xn) (displayln xn))))

  (f 'not-a-number))

               

((deserialize (serialize f)) 'not-a-number)

[Matthew Flatt]

The original example had an explicit deserializer:

At Sun, 23 Jul 2017 19:54:43 -0500, Philip McGrath wrote:
> (define deserialize-info:adder-v0
> (make-deserialize-info make-adder
> (λ () (error 'adder
> "can't have cycles"))))

You're constructing the deserializer with `make-adder` --- the variant
from inside the `server` module, so it doesn't have a contract.

I think this is where you want to draw a new boundary by giving
`make-deserialize-info` a variant of `make-adder` that has a contract.

[Philip McGrath]

If I'm following correctly, I think that's what I was trying to do, but I'm unclear how to give `make-deserialize-info` a variant of `make-adder` that has a contract. The initial example with `define/contract` was the closest I've come: it at least reported violations in terms of `make-adder` rather than `+`, but (as I now understand) it blamed the `server` module for all violations.

-Philip

[Matthias Felleisen]

On Jul 23, 2017, at 10:50 PM, Philip McGrath <phi...@philipmcgrath.com> wrote:

If I'm following correctly, I think that's what I was trying to do, but I'm unclear how to give `make-deserialize-info` a variant of `make-adder` that has a contract. The initial example with `define/contract` was the closest I've come: it at least reported violations in terms of `make-adder` rather than `+`, but (as I now understand) it blamed the `server` module for all violations.

-Philip

On Sun, Jul 23, 2017 at 9:27 PM, Matthew Flatt <mfl...@cs.utah.edu> wrote:

The original example had an explicit deserializer:

At Sun, 23 Jul 2017 19:54:43 -0500, Philip McGrath wrote:
>   (define deserialize-info:adder-v0
>     (make-deserialize-info make-adder
>                            (λ () (error 'adder
>                                         "can't have cycles"))))

You're constructing the deserializer with `make-adder` --- the variant
from inside the `server` module, so it doesn't have a contract.

I think this is where you want to draw a new boundary by giving
`make-deserialize-info` a variant of `make-adder` that has a contract.

Don’t you just want this: 

#lang racket

(module server racket

  (require racket/serialize)

  

  (provide (contract-out

            [adder (-> natural-number/c (-> natural-number/c natural-number/c))]))

  

  (struct adder (base)

    #:property prop:procedure

    (λ (this x) (+ (adder-base this) x))

    #:property prop:serializable

    (make-serialize-info (λ (this) (vector (adder-base this)))

                         #'deserialize-info:adder-v0

                         #f

                         (or (current-load-relative-directory)

                             (current-directory))))

  

  (define deserialize-info:adder-v0

    (make-deserialize-info adder (λ () (error 'adder "can't have cycles"))))

  

  (module+ deserialize-info

    (provide deserialize-info:adder-v0)))

  

(require (submod "." server) racket/serialize)

(local ((define serialize values)

        (define deserialize values))

  (define x (serialize (adder 5)))

  (define f (deserialize x))

  (f 'not-a-number))

[Philip McGrath]

That is precisely the contract violation I'd like to see reported, but, without the shadowing of serialize and deserialize, the error is reported in terms of `+`. (And, if it wasn't clear, I do intend to actually read and write the serialized instance.)

I (think) I understand why deserialization strips the contract from the instance: the contract is added at the module boundary using the chaperone/impersonator infrastructure, and deserialization uses the unprotected form of `adder` passed to `make-deserialize-info` within the server module. 

What I don't understand is how to give `make-deserialize-info` a function that (1) has a contract where (2) fulfilling the range part of the contract becomes the deserializing module's obligation — if such a thing is possible. Aside from attempts with `define/contract` (which as I now understand achieved point 1 but not point 2), I've also tried putting the definition of `deserialize-info:adder-v0` in a different module, so that its version of `adder` has a contract, but then the binding isn't seen by `make-serialize-info`.

-Philip

[Matthias Felleisen]

> On Jul 24, 2017, at 1:35 PM, Philip McGrath <phi...@philipmcgrath.com> wrote:
>
> That is precisely the contract violation I'd like to see reported, but, without the shadowing of serialize and deserialize, the error is reported in terms of `+`. (And, if it wasn't clear, I do intend to actually read and write the serialized instance.)
>
> I (think) I understand why deserialization strips the contract from the instance: the contract is added at the module boundary using the chaperone/impersonator infrastructure, and deserialization uses the unprotected form of `adder` passed to `make-deserialize-info` within the server module.

The second half of your sentence is the fundamental reason. The serialization is specified inside the module so the operation sees the un-contracted adder. This is a deliberate design decision:

inside a module, a programmer can’t do wrong.

It turns out that other languages (Eiffel, Spec#, C@) struggle with this problem a lot because they want to give developers the chance to use their own functions/methods outside of the contract’s specs but cannot and that has serious consequences.

> What I don't understand is how to give `make-deserialize-info` a function that (1) has a contract where (2) fulfilling the range part of the contract becomes the deserializing module's obligation — if such a thing is possible. Aside from attempts with `define/contract` (which as I now understand achieved point 1 but not point 2), I've also tried putting the definition of `deserialize-info:adder-v0` in a different module, so that its version of `adder` has a contract, but then the binding isn't seen by `make-serialize-info`.

The code I sent blames the deserializing module. I don’t get what you still need. (I just gave it ‘adder’, which has a contract from the outer module boundary, and that applies to the nested module+ boundary as you can see.

[Philip McGrath]

It occurs to me that one approach is to use the low-level `contract` form directly. It gives better blame than `define/contract`, at least. The program:

#lang racket

(module server racket

  (require racket/serialize)

  

  (provide (contract-out

            [adder (-> natural-number/c (-> natural-number/c natural-number/c))]))

  

  (struct adder (base)

    #:property prop:procedure

    (λ (this x) (+ (adder-base this) x))

    #:property prop:serializable

    (make-serialize-info (λ (this) (vector (adder-base this)))

                         #'deserialize-info:adder-v0

                         #f

                         (or (current-load-relative-directory)

                             (current-directory))))

  

  (define deserialize-info:adder-v0

    (make-deserialize-info

     (λ (base)

       (define inst (adder base))

       (contract (-> natural-number/c natural-number/c)

                 inst

                 '(definition adder)

                 `(deserialization ,inst)

                 (object-name adder)

                 #f))

     (λ () (error 'adder "can't have cycles"))))

  

  (module+ deserialize-info

    (provide deserialize-info:adder-v0)))

  

(require (submod "." server) racket/serialize)

((deserialize (serialize (adder 5))) 'not-a-number)

reports the error:

adder: contract violation

  expected: natural-number/c

  given: 'not-a-number

  in: the 1st argument of

      (-> natural-number/c natural-number/c)

  contract from: (definition adder)

  blaming: (deserialization #<procedure:adder>)

   (assuming the contract is correct)

-Philip

[Philip McGrath]

Sorry for the crossed emails. If I understand what's happening correctly, the code you sent only blames the "deserializing" module because it shaddows `serialize` and `deserialize` to mean `values`, so the instance is never actually deserialized or serialized and `deserialize-info:adder-v0` is never consulted. If I remove the `local` block, the error is displayed in terms of `+`.

#lang racket

(module server racket

  (require racket/serialize)

  

  (provide (contract-out

            [adder (-> natural-number/c (-> natural-number/c natural-number/c))]))

  

  (struct adder (base)

    #:property prop:procedure

    (λ (this x) (+ (adder-base this) x))

    #:property prop:serializable

    (make-serialize-info (λ (this) (vector (adder-base this)))

                         #'deserialize-info:adder-v0

                         #f

                         (or (current-load-relative-directory)

                             (current-directory))))

  

  (define deserialize-info:adder-v0

    (make-deserialize-info adder (λ () (error 'adder "can't have cycles"))))

  

  (module+ deserialize-info

    (provide deserialize-info:adder-v0)))

  

(require (submod "." server) racket/serialize)

(define x (serialize (adder 5)))

(displayln x)

(define f (deserialize x))

(f 'not-a-number) 

-Philip

[Matthias Felleisen]

Ouch, my fault. I deleted the wrong bindings.

[Matthew Flatt]

At Mon, 24 Jul 2017 12:35:51 -0500, Philip McGrath wrote:
> I've also tried putting the
> definition of `deserialize-info:adder-v0` in a different module, so that
> its version of `adder` has a contract, but then the binding isn't seen by
> `make-serialize-info`.

In case you still want to pursue that direction, you can use the pair
form of the second argument to `make-serialize-info`, which pairs a
symbol with a reference to an exporting module. See the example below.

(I think there's probably a library that's better to use than a raw
`variable-reference->module-path-index` plus `module-path-index-join`,
but I forget.)

I don't see a way to blame the module that calls `deserialize`.

----------------------------------------

#lang racket

(module server racket
(require racket/serialize)
(provide (contract-out
[adder (-> natural-number/c (-> natural-number/c
natural-number/c))]))
(struct adder (base)
#:property prop:procedure
(λ (this x)
(+ (adder-base this) x))
#:property prop:serializable
(make-serialize-info (λ (this) (vector (adder-base this)))

(cons 'deserialize-info:adder-v0
(module-path-index-join
'(submod "." deserialize-info)
(variable-reference->module-path-index
(#%variable-reference))))

#f
(or (current-load-relative-directory)
(current-directory))))
(define/contract make-adder

(-> natural-number/c (-> natural-number/c
natural-number/c))

adder)

(module* deserialize-info racket/base
(require (submod ".."))
(require racket/serialize)
(provide deserialize-info:adder-v0)

(define deserialize-info:adder-v0
(make-deserialize-info adder
(λ () (error 'adder

"can't have cycles"))))))


(require 'server racket/serialize)

[Robby Findler]

One approach would be to not expect the clients to use deserialize
directly but provide a thin wrapper module which would be the place to
hang the blame information (and it would use `contract-out`).

Robby

> --
> You received this message because you are subscribed to the Google Groups "Racket Users" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.