We should use long-long to specify timestamps

NEW
Unassigned

Status

()

--
critical
5 years ago
2 years ago

People

(Reporter: julienw, Unassigned)

Tracking

Trunk
ARM
Gonk (Firefox OS)
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
See Bug #939302 for more information.

Boris is saying we should not use Date in our idl. Since these structs are stored on the heap, that means that they value they're holding can just become garbage any time a GC happens.

He strongly recommends, in this order of checkins:

1) Using a numeric timestamp here, not a Date object.
2) Not using xpidl dictionaries.
3) Not using JSAPI directly, because any attempt to do so will generally go wrong.


I think we should just use 1.

Boris, since the Contacts API is using WebIDL, is it less serious than in bug 939302? Or is it basically the same?
Why is this sec-critical?
(Reporter)

Comment 2

5 years ago
I cloned from bug 939302 (I assumed: same bug, same consequences), feel free to fix it if this needs to be evaluated again.
Contacts is implemented in JS, not in C++, right?  So there shouldn't be these issues of having JS values on the stack or heap that are not being traced...

The reason to not use Dates is because Date is going to be removed from WebIDL, or at least deprecated.
(Reporter)

Comment 4

5 years ago
Ok thanks then it's not security-sensitive and we can remove the security-sensitive flag (except if the comment 0 is pointing too hard to the other problem).
Keywords: sec-critical
I think this isn't sec-sensitive, yeah.  Just an API design issue.
Group: core-security
Date objects in general has all sorts of issues. So we shouldn't use them in APIs. See long thread here:

http://esdiscuss.org/topic/frozen-date-objects
You need to log in before you can comment on or make changes to this bug.