Re: [webkit-dev] Implementing Universal Second Factor (U2F)

As I understand, there's active development going on in both chromium and Edge for Web Authentication right now. I'm sure those folks would love to collaborate with someone working in WebKit (and I'm happy to make introductions). On Wed, Feb 22, 2017 at 6:08 PM, Sam Weinig wrote: > > On Feb 22,

Re: [webkit-dev] Implementing Universal Second Factor (U2F)

> On Feb 22, 2017, at 1:22 PM, Ryosuke Niwa wrote: > > On Wed, Feb 22, 2017 at 12:56 PM, Rick Byers > wrote: > Chrome ships with a built-in extension that exposes the high-level API (which > I think we all agree is a hack). We recently had this discussion >

Re: [webkit-dev] ReadMe.md on Github

Posted a patch on https://bugs.webkit.org/show_bug.cgi?id=168745 to add instructions to build GTK+ port. - R. Niwa On Wed, Feb 22, 2017 at 2:26 PM, Ryosuke Niwa wrote: > On Wed, Feb 22, 2017 at 6:55 AM, Michael Catanzaro > wrote: >> On Tue, 2017-02-21 at 22:53 -0800, Ryosuke Niwa wrote: >>> I f

Re: [webkit-dev] ReadMe.md on Github

On Wed, Feb 22, 2017 at 6:55 AM, Michael Catanzaro wrote: > On Tue, 2017-02-21 at 22:53 -0800, Ryosuke Niwa wrote: >> I feel like GTK+ port's instruction can be consolidated enough to fit >> there but we might want to write some script that someone can run to >> do everything you need like Tools/S

Re: [webkit-dev] Why does RELEASE_ASSERT not have an error message?

On Wed, Feb 22, 2017 at 12:41 PM, Mark Lam wrote: > > I would like to point out that we might be able to get the best of both > worlds. Here’s how we can do it: > > define RELEASE_ASSERT(assertion) do { \ > if (UNLIKELY(!(assertion))) { \ > preserveRegisterState(); \ > WTFRep

Re: [webkit-dev] Implementing Universal Second Factor (U2F)

On Wed, Feb 22, 2017 at 12:56 PM, Rick Byers wrote: > Chrome ships with a built-in extension that exposes the high-level API > (which I think we all agree is a hack). We recently had this discussion > > about the

Re: [webkit-dev] Implementing Universal Second Factor (U2F)

Chrome ships with a built-in extension that exposes the high-level API (which I think we all agree is a hack). We recently had this discussion about the right path forward here, and agreed that we should instead fo

Re: [webkit-dev] Why does RELEASE_ASSERT not have an error message?

> On Feb 22, 2017, at 12:46 PM, Filip Pizlo wrote: > >> >> On Feb 22, 2017, at 12:41 PM, Mark Lam > > wrote: >> >>> >>> On Feb 22, 2017, at 12:35 PM, Filip Pizlo >> > wrote: >>> On Feb 22, 2017, at 12:33 PM, Mark Lam >>>

Re: [webkit-dev] Why does RELEASE_ASSERT not have an error message?

> On Feb 22, 2017, at 12:41 PM, Mark Lam wrote: > >> >> On Feb 22, 2017, at 12:35 PM, Filip Pizlo > > wrote: >> >>> >>> On Feb 22, 2017, at 12:33 PM, Mark Lam >> > wrote: >>> >>> On Feb 22, 2017, at 12:16 PM, Filip Pizlo >>>

Re: [webkit-dev] Implementing Universal Second Factor (U2F)

> On Feb 22, 2017, at 5:52 AM, Jacob Greenfield wrote: > > I’m working on adding support to WebKit for FIDO U2F (JS API: > https://fidoalliance.org/specs/fido-u2f-v1.1-id-20160915/fido-u2f-javascript-api-v1.1-id-20160915.html > Architecture overview: > https://fidoalliance.org/specs/fido-u2f-

Re: [webkit-dev] Why does RELEASE_ASSERT not have an error message?

Mark, I know that you keep saying this. I remember you told me this even when I was sitting on a RELEASE_ASSERT that had gotten rage-coalesced. Your reasoning sounds great, but this just isn't what happens in clang. __builtin_trap gets coalesced, as does inline asm. -Filip > On Feb 22, 201

Re: [webkit-dev] Why does RELEASE_ASSERT not have an error message?

> On Feb 22, 2017, at 12:35 PM, Filip Pizlo wrote: > >> >> On Feb 22, 2017, at 12:33 PM, Mark Lam > > wrote: >> >> >>> On Feb 22, 2017, at 12:16 PM, Filip Pizlo >> > wrote: >>> >>> On Feb 22, 2017, at 11:58 AM, Geoffrey Garen >>>

Re: [webkit-dev] Why does RELEASE_ASSERT not have an error message?

For some context, we used to see aggregation of the CRASH() for RELEASE_ASSERT() in the old days before we switched to using the int3 trap. Back then we called a crash() function that never returns. As a result, the C++ compiler was able to coalesce all the calls. With the int3 trap emitted b

Re: [webkit-dev] Why does RELEASE_ASSERT not have an error message?

> On Feb 22, 2017, at 12:33 PM, Mark Lam wrote: > > >> On Feb 22, 2017, at 12:16 PM, Filip Pizlo > > wrote: >> >> >>> On Feb 22, 2017, at 11:58 AM, Geoffrey Garen >> > wrote: >>> >>> I’ve lost countless hours to investigating CrashTracers tha

Re: [webkit-dev] Why does RELEASE_ASSERT not have an error message?

> On Feb 22, 2017, at 12:16 PM, Filip Pizlo wrote: > > >> On Feb 22, 2017, at 11:58 AM, Geoffrey Garen wrote: >> >> I’ve lost countless hours to investigating CrashTracers that would have been >> easy to solve if I had access to register state. > > The current RELEASE_ASSERT means that ever

Re: [webkit-dev] Why does RELEASE_ASSERT not have an error message?

> On Feb 22, 2017, at 12:16 PM, Filip Pizlo wrote: > > >> On Feb 22, 2017, at 11:58 AM, Geoffrey Garen wrote: >> >> I’ve lost countless hours to investigating CrashTracers that would have been >> easy to solve if I had access to register state. > > The current RELEASE_ASSERT means that ever

Re: [webkit-dev] Why does RELEASE_ASSERT not have an error message?

> On Feb 22, 2017, at 12:23 PM, Saam barati wrote: > >> >> On Feb 22, 2017, at 12:16 PM, Filip Pizlo > > wrote: >> >> >>> On Feb 22, 2017, at 11:58 AM, Geoffrey Garen >> > wrote: >>> >>> I’ve lost countless hours to investigating CrashTracers

Re: [webkit-dev] Why does RELEASE_ASSERT not have an error message?

> On Feb 22, 2017, at 11:58 AM, Geoffrey Garen wrote: > > I’ve lost countless hours to investigating CrashTracers that would have been > easy to solve if I had access to register state. The current RELEASE_ASSERT means that every assertion in what the compiler thinks is a function (i.e. some

Re: [webkit-dev] Why does RELEASE_ASSERT not have an error message?

On Wed, 2017-02-22 at 11:58 -0800, Geoffrey Garen wrote: > (2) Change RELEASE_ASSERT to do the normal debug ASSERT thing in > Debug builds. (There’s not much need to preserve register state in > debug builds.) This seems like a more desirable approach. Michael

Re: [webkit-dev] Why does RELEASE_ASSERT not have an error message?

I like this idea. I think even doing what JF suggested could be really nice for suspected crashes. That way the register state would just tell us the reason. If we do log, I think we should use WTFLogAlways instead of dataLog, because I think that does show up in some crash logs (but I could be w

Re: [webkit-dev] Why does RELEASE_ASSERT not have an error message?

I’ve lost countless hours to investigating CrashTracers that would have been easy to solve if I had access to register state. I also want the freedom to add RELEASE_ASSERT without ruining performance due to bad register allocation or making the code too large to inline. For example, hot paths i

Re: [webkit-dev] Why does RELEASE_ASSERT not have an error message?

Do we get the dataLog output in a crash report? It seems useful to have at a minimum some "reason" enum which ends up in a register, so the crash report is somewhat helpful, like we do with JIT code. At that point the release assert might as well capture __LINE__ and other things in a register, so

Re: [webkit-dev] Why does RELEASE_ASSERT not have an error message?

I disagree actually. I've lost countless hours to converting this: RELEASE_ASSERT(blah) into this: if (!blah) { dataLog("Reason why I crashed"); RELEASE_ASSERT_NOT_REACHED(); } Look in the code - you'll find lots of stuff like this. I don't think analyzing register state at crashes is m

Re: [webkit-dev] Implementing Universal Second Factor (U2F)

On Wed, 2017-02-22 at 12:20 -0500, Jacob Greenfield wrote: > Michael, > > Thanks for the info. After looking into things a bit more - let me > know if this does not make sense - it looks like it may be better to > reimplement for WebKit. OK, your explanation sounds reasonable to me. Michael

Re: [webkit-dev] Implementing Universal Second Factor (U2F)

Michael, Thanks for the info. After looking into things a bit more - let me know if this does not make sense - it looks like it may be better to reimplement for WebKit. Specifically, it looks like hidapi does some opaque stuff with threading that may leave idle threads around, to expose a consi

Re: [webkit-dev] Webkit port to ppc64le.

You have to port the llint either way since even the JIT relies on some llint code. -Filip > On Feb 22, 2017, at 07:22, Atul Sowani wrote: > > Sure, thanks @Konstantin. So I will first attempt having working JIT on > ppc64le. Your comments definitely helped in deciding the direction for > p

Re: [webkit-dev] Webkit port to ppc64le.

Sure, thanks @Konstantin. So I will first attempt having working JIT on ppc64le. Your comments definitely helped in deciding the direction for porting. Thanks! :) On Wed, Feb 22, 2017 at 8:28 PM, Konstantin Tokarev wrote: > > > 22.02.2017, 17:41, "Atul Sowani" : > > So, essentially, some tweakin

Re: [webkit-dev] Implementing Universal Second Factor (U2F)

On Wed, 2017-02-22 at 08:52 -0500, Jacob Greenfield wrote: > The (USB) protocol itself works by sending USB HID reports (packets) > to the key and getting USB HID reports back. There is a reference > implementation by one of the members of the specification group - > libu2f-host (by Yubico); howeve

Re: [webkit-dev] ReadMe.md on Github

On Tue, 2017-02-21 at 22:53 -0800, Ryosuke Niwa wrote: > I feel like GTK+ port's instruction can be consolidated enough to fit > there but we might want to write some script that someone can run to > do everything you need like Tools/Scripts/configure-xcode-for-ios- > development for iOS first. Cu

Re: [webkit-dev] Webkit port to ppc64le.

22.02.2017, 17:41, "Atul Sowani" : > So, essentially, some tweaking in the code of LLInt/interpreter _is_ required > when porting it to the new platform. Is my understanding correct? Yes. In order to port LLInt you should implement offlineasm backend. See for example arm.rb, arm64.rb, mips.rb

Re: [webkit-dev] Webkit port to ppc64le.

So, essentially, some tweaking in the code of LLInt/interpreter _is_ required when porting it to the new platform. Is my understanding correct? On Wed, Feb 22, 2017 at 4:11 PM, Konstantin Tokarev wrote: > > > 22.02.2017, 13:15, "Atul Sowani" : > > Hi, > > > > This is not specific to any particul

[webkit-dev] Implementing Universal Second Factor (U2F)

I’m working on adding support to WebKit for FIDO U2F (JS API: https://fidoalliance.org/specs/fido-u2f-v1.1-id-20160915/fido-u2f-javascript-api-v1.1-id-20160915.html Architecture overview: https://fidoalliance.org/specs/fido-u2f-v1.1-id-20160915/fido-u2f-overview-v1.1-id-20160915.html ). The FID

Re: [webkit-dev] Webkit port to ppc64le.

22.02.2017, 13:15, "Atul Sowani" : > Hi, > > This is not specific to any particular branch/version of WebKit. I was > browsing the code with ppc64le porting in mind. By default JIT is not > available on ppc64le, so the CLoop code is used instead. > > I see there is low level interpreter code in

[webkit-dev] Webkit port to ppc64le.

Hi, This is not specific to any particular branch/version of WebKit. I was browsing the code with ppc64le porting in mind. By default JIT is not available on ppc64le, so the CLoop code is used instead. I see there is low level interpreter code in qtwebkit/Source/JavaScriptCore/llint directory and