| Summary: | Don't leak the names of [private] functions in JS built-ins | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Adam Bergkvist <adam.bergkvist> |
| Component: | Bindings | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW --- | ||
| Severity: | Normal | CC: | cdumez, joepeck, youennf |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Bug Depends on: | |||
| Bug Blocks: | 143211 | ||
Since [1] is fixed now, I'm OK with closing this as WONTFIX. [1] https://bugs.webkit.org/show_bug.cgi?id=158777 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. (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. |
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