Cannot destructure property 'subtle' of 'crypto' as it is undefined.

[cumbriasingers]

The build script I have used successfully to date on Render:

bundle exec jekyll build && npx staticrypt _site/members.html this-is-my-password --salt <*****> -o _site/members.html -f "_includes/extensions/password_template.html"

now (30/03/23) fails with

Apr 1 10:48:48 AM npx: installed 19 in 1.814s Apr 1 10:48:48 AM Cannot destructure property 'subtle' of 'crypto' as it is undefined. Apr 1 10:48:48 AM ==> Build failed 😞

[robinmoisson]

Hey @cumbriasingers, thanks for reporting. What's your node version and your staticrypt version ?

[cumbriasingers]

Hi Robin By default, Render uses Node version 14.17.0; I'm not sure how I find the staticrypt version :-(

[robinmoisson]

Ok depending on your version, I think I found the issue. You can find staticrypt version by running npm list staticrypt or npx staticrypt --version.

If you're on version 3.x: staticrypt uses semantic versioning and we just released 3.0 (:partying_face:) which means there are breaking changes from 2.x. The new version brings a number of improvements and uses the WebCrypto engine by default, which is more secure. If you're using that version you need to follow the MIGRATING.md guide.

If you're on version 2.x: in version 2.6.0 we added the WebCrypto engine as an option, so it could be used with no migration if you don't use a custom template. Using it requires a node version >= 16 - I didn't realize this and it bumped the required node version to 16+ even if you're not using WebCrypto.

I just pushed a fix as 2.6.1 for people still on 2.x, now using this version with default engine CryptoJS is still compatible with lower node versions, and people get a nice warning if they try to use WebCrypto on a version that doesn't support it.

Let me know if that helps!

[cumbriasingers]

Regret to say, no it doesn't solve the problem.

I haven't found a way to find the staticrypt version on Render - I don't seem to be able to run any console commands to find out such things

[robinmoisson]

Then I need more info on your setup. How do you deploy on render, do you have a git repo you upload there? What does it look like, do you upload a package.json file, which is where npm will set packages version constraints? How did you install staticrypt?

If you didn't install staticrypt anywhere and just run npx staticrypt it will install and use staticrypt on the fly, taking the latest version by default so 3.x. If that's the case you can either follow the migration steps to upgrade to 3.x, or pin the version to 2.x by running npx staticrypt@2 instead.

[cumbriasingers]

Brilliant! npx staticrypt@2 does the job. Thank you so much. The git repo is uploaded without any package.json file and you're right, I didn't install staticrypt anywhere, so it looks like Render is picking up the 3.x version - hence the breakage. I'll probably re-write the site over the Summer at which point I'll look at migrating to 3.x, but, in the meantime, this is adequate to keep it all going. Thanks for your swift and helpful response again.

[cumbriasingers]

(Premature closing of the issue) ...although the script now runs to completion, including the warning:

SECURITY WARNING [StatiCrypt]: You are using an old version of the password template, which has been found to be less secure. Please update your custom password_template logic to match the latest version

the password for the encrypted page is not recognised .

[robinmoisson]

Yes, maybe I could reword this warning. Your file has been encrypted as before and your template has been used correctly.

A few weeks ago we noticed a setting was used on StatiCrypt that made the password less strong than it could be against brute-forcing, so I changed that setting but to do that I needed to make some changes to the password_template that are not compatible with the older password_templates. If you're using a custom template and you created it a long time ago we can't apply that new setting, so StatiCrypt detects this, encrypts your file in the old way and displays this warning.

In terms of security, the difference between the two settings is equivalent to removing around 1.7 alphanumeric characters to the password. If you used a strong, long password (we recommend 16+ alphanum random characters), it should still be ok.

So if you want optimal protection you can:

• either use a long random password, like 16 random alphanum characters (or more to be comfortable), and ignore this warning
• upgrade your password template and/or StatiCrypt version

You can read a really detailed discussion on that topic, what it means and the trade-offs involved on #160.

---

EDIT: ah, re-reading your message if your password isn't working on the encrypted page then that's an error. I'll look into it, it should display a warning but still work.

[cumbriasingers]

Mmm, thanks. The protection is, I'm sure, more than adequate for our simple purposes ie just to keep casually prying eyes from some resources which we wanted to share among a group. We used a (20+ character) passphrase.
I'll have a look at the details you suggest, but yes, now the password isn't working on the encrypted page, so I guess it is an error. Thanks for looking into it.

[robinmoisson]

So there was indeed a bug when detecting the old version of the password template and trying to encrypt in the file in the old way. I've just fixed it and pushed 2.6.2 on npm, can you let me know if that fixes it for you?

[cumbriasingers]

That's looking good now, thanks