[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #14059 [Tor Browser]: Revision of existing double key cookie logic to meet requirements



#14059: Revision of existing double key cookie logic to meet requirements
-----------------------------+----------------------------
     Reporter:  michael      |      Owner:  michael
         Type:  defect       |     Status:  needs_revision
     Priority:  normal       |  Milestone:
    Component:  Tor Browser  |    Version:
   Resolution:               |   Keywords:
Actual Points:               |  Parent ID:  #3246
       Points:               |
-----------------------------+----------------------------

Comment (by gk):

 Replying to [comment:16 michael]:
 > Replying to [comment:15 gk]:
 > > 3) nsICookie2.idl: Why is `aOrigin` of type `ACString` and not
 `AUTF8String` (like `host`, `rawHost` etc.)?
 > >
 > Most host string variables in implementation files are of type
 `nsACString` or `nsCString` which implies the IDL variables should use
 `ACString`. I assumed that's why you and Dan Witte made it `ACString`, but
 I agree that there should be some conformance.
 >
 > Too bad there's so much AUTF8String already in nsCookie (frozen I think)
 so I'll change `origin` to be of type `AUTF8String` to conform.

 Well, I was just wondering for the rationale behind it and did not look
 that deep. I mainly feared that it could break the cookie logic in a
 subtle way but testing indicated that I was wrong. Or maybe my tests were
 not elaborate enough.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/14059#comment:19>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs