[Webkit-unassigned] [Bug 70617] Optional "keytype" attribute for the <keygen> tag is handled incorrectly in appendFormData().

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Oct 21 22:26:07 PDT 2011


https://bugs.webkit.org/show_bug.cgi?id=70617


Ryan Sleevi <rsleevi at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rsleevi at chromium.org




--- Comment #7 from Ryan Sleevi <rsleevi at chromium.org>  2011-10-21 22:26:06 PST ---
(In reply to comment #3)
> (From update of attachment 111981 [details])
> Normally we require regression tests with all bug fixes. Is there a reason you can’t write a regression test for this?

As someone who has worked with the <keygen> implementation on the Chromium side, and studied the various ports on the WebKit side, I think one of the big challenges to this is that it requires an actual form submission in order to repro.

<keygen>, however, is not idempotent with respect to system state, and the act of submitting a <form> element with a <keygen> tag can result in creating a new private key within whatever keystore the port uses (which, in most implementations, is the OS-provided keystore/cryptographic APIs)

Unlike other APIs which may modify system state (such as those that may create/modify files), this is not presently something WebKit supports mocking/stubbing. The current <keygen> tests just focus on the immutable aspects - parsing and rendering - and ignore submission.

Since the <keygen> element isn't processed on the C++ side until form submission, this is not something where you could poke with JavaScript as a LayoutTest to grab the resultant value in an onsubmit() handler.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the webkit-unassigned mailing list