[plt-scheme] planet: help submitting bugs & a question

From: Robby Findler (robby at cs.uchicago.edu)
Date: Tue Sep 2 10:08:15 EDT 2008

On Tue, Sep 2, 2008 at 8:58 AM, Grant Rettke <grettke at acm.org> wrote:
> On Tue, Sep 2, 2008 at 8:44 AM, Robby Findler <robby at cs.uchicago.edu> wrote:
>> On Tue, Sep 2, 2008 at 8:37 AM, Grant Rettke <grettke at acm.org> wrote:
>>> Rather than worrying about anonymizing data, you could allow PLaneT
>>> packages to include a public key provided by the author. Encrypt the
>>> whole enchilada that gets sent to trac.
>> Well, the user of the package is the one who could be divulging
>> information, not the package author.
> How else then would you submit accurate bug reports to the package
> maintainer? As I type this, I suppose the goal is not to do that, it
> is only to report contract violations.
> The notion of asking the user (non-programmer) whether they want to
> submit details regarding contract violations is unrealistic.
> How would a user know what they should and they should not send when a
> contract is violated? It would be confusing.

I'm sorry -- we seem to be miscommunicating.

When I wrote "user" I meant the user of the planet package (a
programmer), not an end user of the software.

I think that encrypting things in the manner you suggest would help
protect the author of the planet package, but it is not (always) this
person that needs protection. Instead, it is the programmer who is
using the plant package. Altho proper blame assignment (like we have!)
suggests that in many cases the values that end up in the bug report
will be values that originate with the planet package being blamed,
that is not always the case. For example, imagine I wrote a function
like this:

  parse-cc-number : (-> string (between/c 0 (expt 2 32)))
  ;; accepts the contents of a form and returns a creditcard number string
  ;; removes intermediate spaces and checks well-formedness

and packaged it up via planet. The contract on the range is broken, so
when you first use it, this will produce a contract violation that
includes the properly parsed credit card number but will be sent to my
package and thus encrypted with my key, not with the credit card
author's key.

Does that make more sense?


Posted on the users mailing list.