MaixPy should be a submodule

[Giszmo]

Copying code in makes code review hard as now the reviewer also has check where that copied code came from and if it was modified. #39 sounds like this issue might be resolved by removal of the code but anyway, for a Bitcoin wallet code auditability is key.

[ghost]

The changes made to MaixPy are extensive enough (and specific to Krux, such as memory wiping and QR code generation) that in order to do a proper audit, you do need to review the firmware code regardless.

I think making it a submodule eventually would be worthwhile (if/when Krux is more platform-agnostic), but for now since the firmware code is Krux-specific there isn't much reason to break it out yet. I'll leave this issue open though since it makes sense to do that in the future.

(By the way, if you're planning to audit the code, you may want to either start in the tests branch or wait until that makes its way into main in the next few weeks since it includes a fair amount of code changes as well. That, or wait until I put out the first official release soon after.)

[Giszmo]

As a regular code auditor in general it's impossible to individually review every line of an extensive project, so one takes short cuts. One of those is to trust dependencies that are deemed to probably not target private keys and only look at the diff from there. Therefore it would be really helpful to have MaixPy as a submodule with its original history preserved and the necessary changes on top. For an auditor, "breaking it out" into a submodule without its historic commits is not helpful.

[ghost]

Okay, I see. I can certainly try to do that to make auditing easier 👍

[ghost]

@Giszmo Hey, I just wanted to give you notice that I'm planning to put out the first official release (v1.0.0) of Krux this week!

[ghost]

@Giszmo Here it is!
https://github.com/selfcustody/krux/releases/tag/v22.03.0