562282 - All cookies shown as secure

Status: RESOLVED FIXED

(Camino Graveyard :: Preferences, defect)

Description

[Ilya Sherman]

All cookies in the cookie manager have the value "yes" for the Secure column.

STR:
1. Open Preferences
2. Go to the Privacy tab
3. Click on "Show Cookies..."

Comment 1

[Chris Lawson (gone)]

Two questions:

1) Are you sure this is a bug? The NSHTTPCookie documentation doesn't ever really define what a "secure channel" is. (SSL/TLS-encrypted? Originating server only? Who knows...way to go, Apple.) Core, along with RFC 2109

http://www.ietf.org/rfc/rfc2109.txt

and its successor, RFC 2965

http://www.ietf.org/rfc/rfc2965.txt

is equally vague about what "secure" means, too. Apple's docs do say, for the NSHTTPCookieSecure property, "providing any value for this key indicates that the cookie should remain secure", so it's possible we're somehow confusing things in the conversion. It looks like we're providing a string value of "FALSE" there, so that'd be the first thing I'd check. This may be something that was undocumented in the NSHTTPCookie API before, because the revision history says "2009-10-15: Updated the discussions of the cookiesWithResponseHeaderFiles:forURL method, the NSHTTPCookieSecure key, and the NSHTTPCookiePath key." (For that matter, something in the API may have changed, too, so it might be OS-dependent.)

2) If it is indeed a bug, it's *gotta* be a regression -- though, as mentioned above,  possibly an OS-based regression -- because I'm positive that column used to be a mix of no and yes.

For quick reference, here's an MXR link to the line where we do our conversion:

http://mxr.mozilla.org/mozilla/source/camino/src/embedding/CHCookieStorage.mm#120

(Very strange: Gecko is refusing to store that URL in my history. No idea why, and I don't have time to file a bug right now, but someone remind me later.)

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Per irc, ilya's on 10.5 and philippe's on 10.6, and this is only in 1.9.2 builds.  The values are right in the cookies.sqlite, so either the conversion is failing, or the Gecko API we're using has changed somehow (but not the one Firefox uses), or possibly we're seeing something bizarre when linking on 10.5 with the 10.4 SDK (vs. on 10.4 with the 10.4 sdk in 1.6/2.0/2.1-M1.9).

Comment 3

[philippe (part-time)]

So, it doesn't appear to be limited to camino-gecko1.9.2. At least on 10.6.3.

I moved my default profile out of the way, and started with Camino 2.0.2 release build (virgin profile). Accessed cb-o/welcome (default - set google cookie), then caminobrowser.org/ that pages sets cookies (google analytics - utma/...). I don't think those are 'secure'. Next I visited bugzilla.mozilla.org and logged in (sets a secure cookie - if I compare to 'fox builds).

Result: all cookies are reported as 'secure'. Viewing cookies.sqlite in SQLite Database Browser, it reports different values in the isSecure column (0 or 1).

Comment 4

[philippe (part-time)]

Attachment: screenshot, comment 3

I masked the value for the bm-o login cookies there...

cl, I'll mail you the resulting cookies.sqlite file. don't want to attach it.

Comment 5

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: Match current docs

The current NSHTTPCookie docs on developer.apple.com say:

NSHTTPCookieSecure
    An NSString object indicating that the cookie should be transmitted only over secure channels.
    Providing any value for this key indicates that the cookie should remain secure.

On 10.5, Stuart says they said:

    String value must be either "TRUE" or "FALSE". Default is "FALSE".

So this has been broken basically forever on 10.5 (and 10.6). If it worked before on 10.4, it should still work on 10.4 because now we only set TRUE and the old default was FALSE; if it didn't work before on 10.4, this will fix it there, too.

(Just for the sake of completeness, it *did* work on 10.3 in 1.6.x.)

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #5)
> So this has been broken basically forever on 10.5 (and 10.6). 

"…and the docs were just lying until 10.6." is the way that sentence was supposed to end.

I guess we may as well take this in 2.0.3, too, while we're accumulating patches for it :P

Comment 7

[Stuart Morgan]

Comment on attachment 442138 [details] [diff] [review]
Match current docs

sr=smorgan

Stupid Apple.

Comment 8

[Chris Lawson (gone)]

This might be partly my fault. :-p

I filed rdar://6827180 a while back about NSHTTPCookie docs being faulty as part of the related investigations we did (although I didn't know about this part being wrong; the bug was about not specifying that NSHTTPCookiePath was required if NSHTTPCookieDomain was used), and they just marked it FIXED a month or so ago.

Thanks for fixing this, Smokey.

Stuart: where'd you find old NSHTTPCookie docs? Old ADC DVD or something? (There isn't a WWW "changelog", is there, other than the vague revision history?)

Comment 9

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

http://hg.mozilla.org/camino/rev/453b2e4d4031 and cvs trunk+CAMINO_2_0_BRANCH.