Bug 158778 - Don't leak the names of [private] functions in JS built-ins
Summary: Don't leak the names of [private] functions in JS built-ins
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Bindings (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 143211
  Show dependency treegraph
 
Reported: 2016-06-15 01:51 PDT by Adam Bergkvist
Modified: 2016-06-22 02:05 PDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Bergkvist 2016-06-15 01:51:28 PDT
If I implement a function add() as a JS built-in based on a private function @privateAdd(), I need to duplicate all type checking done in @privateAdd() to prevent error messages to reveal the "privateAdd" name.

For example: "Argument 1 ('item') to Bar.privateAdd must be an instance of FooItem"

The approach with adding a native JS function to both a 'name' and a '@name' slot,  mentioned in [1], makes this less of an issue.

[1] https://bugs.webkit.org/show_bug.cgi?id=158777
Comment 1 Adam Bergkvist 2016-06-21 22:35:16 PDT
Since [1] is fixed now, I'm OK with closing this as WONTFIX.

[1] https://bugs.webkit.org/show_bug.cgi?id=158777
Comment 2 youenn fablet 2016-06-22 01:39:42 PDT
Let's keep it open for now.
There may be cases where this issue might arise again.

Also, usually, the caller of the private method should ensure that parameters passed to the function are all fine. In such a case, the checks should become assertions.
Comment 3 Adam Bergkvist 2016-06-22 02:05:39 PDT
(In reply to comment #2)
> Let's keep it open for now.
> There may be cases where this issue might arise again.

OK with me.

> Also, usually, the caller of the private method should ensure that
> parameters passed to the function are all fine. In such a case, the checks
> should become assertions.

I haven't looked into the effect of the UNLIKELY macro, but it sounds like something we might want to use it if we still want to keep the "second step argument" checks in native code.