Thanks for this! Will give it a proper review soon, but just some initial thoughts:

• I had not considered creating a subcommand for this initially, sorry for not communicating this clearly! With that said, I don't think it's a bad thing to have (esptool.py has one like this), however maybe this overlaps a bit with the existing board-info command, and they should be folded into a single get-security-info command or something? @SergioGasquez what are your thoughts on this?
• Any subcommands added for espflash should also be added for cargo-espflash please, sorry again for not clearly communicating this beforehand 😅

Anyway, thanks again and I will try to review this ASAP!

I was also thinking of this to be an extra subcommand, but now that you mention it, I agree on the overlap. Maybe we could have a --security-info flag on board-info or just dump the security info in board-info by default (not sure if all users will find the flag for it). If we merge the two subcommands, I think board-info has a more intuitive name for it than get-security-info.

Now my question is if we should have two commands or merge them into one… I don't have hard opinion, but maybe I'd lean towards merging it with board-info and printing the current information and security info by default.

Whatever we end up doing, we should add a check for it on HIL

• Any subcommands added for espflash should also be added for cargo-espflash please, sorry again for not clearly communicating this beforehand

I completely forgot about cargo-espflash 😅

And regarding the first point - I'm not sure, I don't see any big problem with having it as a separate command. I would like to be as consistent as possible with esptool. I think it's quite common for people to try and compare espflash and esptool when something does not work correctly and I personally find having such inconsistencies a bit annoying (but it could be only me-issue :D )

And regarding the first point - I'm not sure, I don't see any big problem with having it as a separate command. I would like to be as consistent as possible with esptool. I think it's quite common for people to try and compare espflash and esptool when something does not work correctly and I personally find having such inconsistencies a bit annoying (but it could be only me-issue :D )

Well, we already deviate quite a bit from esptool.py, there is no board-info subcommand at all there for example, and this goes for some of our other subcommands as well. I don't think we need to try and model our subcommands after theirs, there is no real relationship between these tools.

I guess if we decide we want to try and mirror their CLI then we have some refactoring to do

I dont think we should imitate esptool command names, also I dont think this command will be used that often by end-users, the main functionality is to detect new chips. What do you guys think about merging it into board-info?

I dont think we should imitate esptool command names, also I dont think this command will be used that often by end-users, the main functionality is to detect new chips. What do you guys think about merging it into board-info?

I'm okay with it.

I need to update HIL test as well.