This repository has been archived by the owner on Jul 21, 2023. It is now read-only.
WebCrypto is locked up in non secure pages (not loaded from HTTPS) #105
Labels
need/community-input
Needs input from the wider community
status/deferred
Conscious decision to pause or backlog
Comments
This was referenced Aug 28, 2017
|
wow webcrypto gets worse with every thing I learn about it. This is incredible.. |
|
I have some ideas on alternatives, will update here after some experiments |
|
In the short term we should adding a warning in any case as the current releases all have this issue |
|
I am making good progress with my experiments of using asmcrypto.js. Speedwise it looks pretty good and I believe it has everything we need. |
|
@dignifiedquire - have you looked at Libsodium ? We've been using that in JS. |
|
@mitra42 I haven't given it a thorough try yet as we need more than it provides, but I will recheck again what we can use from it, thanks for the reminder |
|
libsodium is great but it exists in its own universe of crypto, the djb universe. We need to support what go-ipfs does and that means that libsodium isn't enough. |
|
Yes, libsodium is an implementation of what NaCl established in this space so it won't be sufficient. |
daviddias
added
status/ready
hapsody
added a commit
to hapsody/js-ipfs
that referenced
this issue
Jul 2, 2019
This example doesn't work except the case in localhost ( related to ipfs#2153) This is known because of a restriction with WebCrypto (libp2p/js-libp2p-crypto#105) I add a explanation of a example's restriction to run
alanshaw
pushed a commit
that referenced
this issue
Jul 4, 2019
This PR adds `crypto-browserify` to the dependencies and replaces `crypto` with `crypto-browserify` when bundled in the browser. In files that require webcrypto we check to see if it's available. If it is not we require the Node.js implementation (which has `crypto` replaced with `crypto-browserify`) and if it is available then we use the webcrypto version (so we get fast crypto). Shipping `crypto-browserify` adds to the bundle size: Current gzipped size: 142,824 bytes New gzipped size: 214,499 bytes Difference: **+71,675 bytes** It's not an insignificant addition so we need to decide whether this is worth it. If not accepted, we need to add checks when libp2p-crypto methods are called and callback with an appropriate error message. JS IPFS will continue to have issues opened with confusion around this otherwise! See ipfs/js-ipfs#963 ipfs/js-ipfs#964 ipfs/js-ipfs#2153 resolves #105 License: MIT Signed-off-by: Alan Shaw <[email protected]>
alanshaw
pushed a commit
to ipfs/js-ipfs
that referenced
this issue
Jul 4, 2019
This example doesn't work except the case in localhost ( related to #2153) This is known because of a restriction with WebCrypto (libp2p/js-libp2p-crypto#105) I add a explanation of a example's restriction to run
alanshaw
pushed a commit
that referenced
this issue
Jul 9, 2019
Changes `webcrypto.js` to check for native web crypto availability and falls back to using `window.__crypto` if not available. If the user wants to bring their own Web Crypto API compatible implementation then they simply need to assign it to `window.__crypto` before they start using IPFS. Checks are done in the functions that require web crypto to give the user the flexibility to assign to `window.__crypto` before OR after they import `libp2p-crypto`. It also means that users have the ability to use other exported functions that do not require web crypto without having to worry about sorting their own implementation. We use `window.__crypto` because `window.crypto` is a readonly property in secure context and always readonly in workers. If `window.crypto` and `window.__cypto` are unavailable then an appropriate error message is reported to the user with a `ERR_MISSING_WEB_CRYPTO` code. I've also added documentation to the README. This is a backwards compatible change. closes #149 resolves #105 resolves ipfs/js-ipfs#2017 resolves ipfs/js-ipfs#2153 License: MIT Signed-off-by: Alan Shaw <[email protected]>
alanshaw
added a commit
that referenced
this issue
Jul 17, 2019
This PR simply detects missing web crypto and throws an error with an appropriate message. This is a stepping stone that will help users understand the problem until we have time to do a refactor of this module and of all the modules that use it to enable optionally passing your own crypto implementation. refs #149 refs #150 refs #105 refs ipfs/js-ipfs#2153 refs ipfs/js-ipfs#2017 License: MIT Signed-off-by: Alan Shaw <[email protected]>
jacobheun
pushed a commit
that referenced
this issue
Jul 22, 2019
This PR simply detects missing web crypto and throws an error with an appropriate message. This is a stepping stone that will help users understand the problem until we have time to do a refactor of this module and of all the modules that use it to enable optionally passing your own crypto implementation. refs #149 refs #150 refs #105 refs ipfs/js-ipfs#2153 refs ipfs/js-ipfs#2017 License: MIT Signed-off-by: Alan Shaw <[email protected]>
Mikerah
pushed a commit
to ChainSafe/js-libp2p-crypto
that referenced
this issue
Aug 29, 2019
This PR simply detects missing web crypto and throws an error with an appropriate message. This is a stepping stone that will help users understand the problem until we have time to do a refactor of this module and of all the modules that use it to enable optionally passing your own crypto implementation. refs libp2p#149 refs libp2p#150 refs libp2p#105 refs ipfs/js-ipfs#2153 refs ipfs/js-ipfs#2017 License: MIT Signed-off-by: Alan Shaw <[email protected]>
oliveriosousa
pushed a commit
to ipfs-examples/js-ipfs-examples
that referenced
this issue
Jul 26, 2021
This example doesn't work except the case in localhost ( related to ipfs/js-ipfs#2153) This is known because of a restriction with WebCrypto (libp2p/js-libp2p-crypto#105) I add a explanation of a example's restriction to run
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
After seeing reports on js-ipfs:
I went to investigate to find this https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/DtOFo51WFMo
It seems that WebCrypto does require a secure context to run and that is not granted in non HTTPS loaded pages. It has an exception for localhost though.
We have a couple of options here:
I prefer option 2, although it will bloat the size of the bundle (again)..
The text was updated successfully, but these errors were encountered: