Deleted Comment
Deleted Comment
The response might've been different if the author had already given a patch, in somewhat backward-compatible way. This doesn't even have to be a functional patch, could be a simple `@warning: usage of default IV will cause insecure storage` similar annotations on the affected functions.
Another thing to remark (and which might've been off-putting for the authors of these libraries) that the author had used term mistakes in various places. Of course in an ideal world, ego should not or would not matter, but these libraries both seem to be quite stale and possibly the authors are having other $DAYJOB responsibilities. Making it difficult to fix things that they just receive complaints about. (I am also guessing these are quite many...)
Again in relation to the points above, it might've been better to say: Cryptography evolves over time, last years' best-practices get outdated, vulnerabilities being found, replaced with newer best-practices of this year. Same will happen next year too. It's not a deliberate mistake or any type of incompetency issue, this is a matter of ever-evolving field that we know and understand better...
For a security related issue? Not sure that is a wise decision.
Dead Comment
Our VS Code extension is trivial to install (https://learn.microsoft.com/en-us/azure/quantum/install-over...) or just try it entirely in the browser with Visual Studio Code online (https://vscode.dev/quantum/playground/)
To support that last scenario, where the language service, debugger, simulator, even package references, can run entirely in the browser, we built the whole thing using Rust compiled to WebAssembly, and our VS Code extension runs as pure JavaScript and Wasm. If interested you can dig into the implementation at https://github.com/microsoft/qsharp .
Happy to answer any questions!
Deleted Comment