[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