mozilla :: #security

14 Mar 2017
00:48k_59Hi I'm interested in Tor Experiment gsoc project if I could have more details about it that would be great
00:51ulfrPing tjr
01:07tjrk_59: Hi! Send me an email please, I'm not available at the moment.
01:08tjrtom@mozilla.com
01:08tjrThanks!!
11:42Dexterheya! Does anybody here know about signing requests from the Firefox client going to a service we own (Mozilla)?
11:47ulfrsigning... http requests?
11:48Dexterulfr, that's a good question. Yes
11:48DexterSo, what I would like to do is making sure that requests that come to the service we're building are really coming from a Firefox client
11:48Dexter rather than brute-forced through curl, for example
11:48Dexter(sorry for the cross-chatting :) )
11:49ulfrDexter: you can't authenticate requests made by firefox clients
11:49ulfrthat would require distributed static credentials that could easily be stolen from the firefox binaries
11:50ulfrthe only way to achieve what you're looking for is through statistical fraud detection techniques
11:50ulfrand signature-based detection, like fingerprint of user-agents, TLS handshakes, etc.
11:50DexterI see
11:50Dexterthanks ulfr
12:53freddybDexter: can you elaborate the whole scenario? maybe there's still something we can come up with
13:08Dexterfreddyb, sure!
13:08Dexterpm :)
13:19freddybulfr: filed a bug, CCd you
13:28Dexterthanks guys, you've been super helpful so far :)
13:29Ms2gerNot just guys around here, you know ;)
13:30freddybyeah, mostly lizard people
13:32DexterWhoops, sorry
13:32DexterI can blame my poor knowledge of the English language :-D
13:33DexterAdjusting the aim: "thank you humans, you've been super helpful" (sit tight, no bot will replace you in the near future)
13:34freddybthat still offends the lizard people :D
19:46rbarnesjkt: is there an ETA on https://bugzilla.mozilla.org/show_bug.cgi?id=1310447 ?
19:46firebotBug 1310447 NEW, jkt@mozilla.com Add a pref to display a negative indicator in the URL bar for non-secure sites
19:55jktrbarnes: I was hoping to get back on it this week
19:56jktrbarnes: the tests just need a fix up last time I was working on it
19:56jktrbarnes: I added another section of code so that all mixed content locks look the same as the broken padlocks too
19:57jktrbarnes: had some fun containers stuff but should be this week hopefully
19:58rbarnesjkt: that mixed content thing sounds maybe more aggressive than i would be
19:59jktrbarnes: it's two distinct prefs so we can use them seperately :)
19:59jkt* separately
20:02rbarnesjkt: ah, ok
23:22dholbertkeeler: hi! I believe I can get around that warning by adding to the CLANG_CXX warning list section in moz.build. (which seems to be friendlier to old clang versions, as I noted on the bug)
23:23dholbertkeeler: I'm happy to steal the bug and post a patch that does that, but I don't want to step on your toes now that you've started on it -- happy to leave that in your hands too
23:23keelerdholbert: ok. The reason I was going with the pragma push/pop method was to limit it to just that declaration
23:24dholbertkeeler: yeah, #pragma is strictly better from that perspective
23:24keelerwould it be possible to add something like && __clang_major__ == whatever to match the specific clang version?
23:24dholbertkeeler: I think that is possible, yes
23:24keelerdholbert: ok - cool. I was going to try that but I didn't know exactly what version to put. 4? 5?
23:25dholbertkeeler: (make sure >= not ==, too -- presumably this warning will continue to exist going forward)
23:25keelergood call
23:25dholbertkeeler: my clang trunk build reports itself as "5.0"
23:26dholbertkeeler: though I suspect this warning may have been introduced in an older version
23:26keelerhmmm - unfortunately I can't find any documentation on just "Wshadow-field"
23:26dholbertha! looks like it was proposed by ehsan: http://clang-developers.42468.n3.nabble.com/Proposal-Wshadow-field-flag-td4045024.html
23:28keelerI wonder if there's a way to test for if a warning exists in clang? :)
23:40dholbertkeeler: https://groups.google.com/a/skia.org/forum/#!msg/reviews/gInJ6loP840/0beVpycYDQAJ suggests that clang 4.0 supports this warning
23:40dholbert(tangentially -- there's a mention of an upcoming builder upgrade to clang 4.0 in the last post there, after some discussion of fixing this warning in their code)
23:41keelerdholbert: the second to last comment seems to be saying it's new in 5?
23:41dholbertoh, right
23:41dholbertAh! "shadow-all" might be a blanket warning group that covers this, based on looking at clang source...
23:43keelerwell, let's start with "Wshadow-field" for __clang_major__ >= 5 for now, and we can fix it if anyone has any issues with 4
23:43dholbertkeeler: that works, though your first patch with s/shadow/shadow-all/ WFM as well
23:43dholbert(just tested)
23:44keelerok - thanks. I think I'd prefer the more specific approach, though
23:44dholbert(that does disable a few other related compiler warnings in the crossfire of course)
23:44dholbertkeeler: cool! that's wise. I'm a bit jaded about targeting with this stuff. :)
23:45keeleryeah, I can see how being too specific might be a pain in the long run :
23:45keeler:/
23:53dholbert(if you don't get it exactly-right :))
23:53* dholbert out
23:53dholbertthanks again for taking a look at that bug!
23:54keelersure thing!@
15 Mar 2017
No messages
   
Last message: 12 days and 17 hours ago