WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
182972
WebCrypto keys break autoincrementing primary keys of IndexedDB
https://bugs.webkit.org/show_bug.cgi?id=182972
Summary
WebCrypto keys break autoincrementing primary keys of IndexedDB
Stefan Sechelmann
Reported
2018-02-20 07:16:08 PST
When storing an object that contains a WebCrypto CryptoKey to an IDB object store with auto incrementing primary key we get the following error: Error: Unable to inject record key into record value See also
https://gist.github.com/sechel/415c34b9bf80f3adeba52856d2377393
Attachments
Add attachment
proposed patch, testcase, etc.
Jiewen Tan
Comment 1
2018-02-20 11:53:42 PST
I tried the test case in Safari. It doesn't reproduce the bug. A very primitive suggestion here is to see if SerializedCryptoKeyWrap.h has caused some troubles for GTK+.
Jiewen Tan
Comment 2
2018-02-20 12:00:42 PST
I remember I told Zan not to wrap/unwrap Crypto Keys for GTK+, so it shouldn't cause any troubles for you. Wrapping crypto keys when storing them into IndexedDB is a legacy behavior to protect them in order to address early limitations of the spec. However, since we have existing clients that have already stored wrapped keys in IndexedDb, Apple ports couldn't get rid of it at this moment.
Zan Dobersek
Comment 3
2018-02-20 13:07:04 PST
(In reply to Jiewen Tan from
comment #2
)
> I remember I told Zan not to wrap/unwrap Crypto Keys for GTK+, so it > shouldn't cause any troubles for you. > > Wrapping crypto keys when storing them into IndexedDB is a legacy behavior > to protect them in order to address early limitations of the spec. However, > since we have existing clients that have already stored wrapped keys in > IndexedDb, Apple ports couldn't get rid of it at this moment.
Keys are still not wrapped for the GTK+ port, as recommended. At least per this bug report, issue is observed with the Safari Tech Preview. OTOH the test case passes on GTK+/WPE as well, meaning that the issue appears to be present (as otherwise the test case would fail).
Zan Dobersek
Comment 4
2018-02-20 13:33:13 PST
Failure occurs during deserialization because UniqueIDBDatabase provides an ExecState from which a usable ScriptExecutionContext cannot be retrieved. That's currently necessary in order to pipe the serialization and deserialization operations all the way up to the WebChromeClient in UIProcess.
https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/bindings/js/SerializedScriptValue.cpp#L477
https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/bindings/js/ScriptState.cpp#L65
Stefan Sechelmann
Comment 5
2018-02-20 14:02:57 PST
> OTOH the test case passes on GTK+/WPE as well, meaning that the issue appears to be present (as otherwise the test case would fail).
Thats right, sorry for causing confusion. The test case is written canary style meaning it will fail if the issue has been resolved. BTW, this bug seems to be related as it also involves creating indices with WebCrypto keys present:
https://bugs.webkit.org/show_bug.cgi?id=177350
Stefan Sechelmann
Comment 6
2018-09-14 05:24:28 PDT
Anything new in the meantime? I will now perform another attempt to port out web application to Safari. Its pretty frustrating that I need so many Workarounds just due to WebCrypto.
Stefan Sechelmann
Comment 7
2019-10-25 03:20:35 PDT
This has been fixed in Safari 13.x.x.
Radar WebKit Bug Importer
Comment 8
2019-10-25 03:21:16 PDT
<
rdar://problem/56613473
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug