Coming from the recent forum post on a refreshed Random package I actually found it’s time to look into more packages with cryptographic context and (who would have guessed) the Accounts packages are definitely part of this as they rely on the SHA256 implementation a lot.
However, this is not an easy thing and we should discuss how to approach this. Here is my input:
Why we need true async accounts packages
The builtin sha256 is still not a full compliant implementation! I documented this in detail in a reproducible GitHub repo.
Replacing the old implementation with native standards is somewhat challenging: while on the server the node:crypto package can work in sync mode, the web crypto API provides only an async digest method. Moving to this native implementation would require an entire rewrite of accounts-password and partially of accounts-base.
However, this challenge is also an opportunity!
- callback hell is still real on the Accounts packages
- moving to async and promises removes lots of code that is only there to harmonize callback behavior
- easier to comprehend code can potentially lead to more community contributions
- people who are new to Meteor might be turned off by callbacks as ancient code style
- sha256 is just rarely used in these packages
From this perspective it seems like a great idea to refactor accounts but here is the second challenge:
- moving accounts to full async would be another hard-breaking move
- not everybody would be happy, especially those who just struggled a lot with moving to Meteor 3
- current implementation is just working
I personally would have no problems with breaking changes in this area but I think this is something that concerns the entire community as a whole so we should discuss this a bit more.