-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
scripts: hid_configurator: Support pure ED25519 signature #19238
scripts: hid_configurator: Support pure ED25519 signature #19238
Conversation
CI InformationTo view the history of this post, clich the 'edited' button above Inputs:Sources:sdk-nrf: PR head: 275c003822ce9d5d9a9930f3cef0807f41a1f26b more detailssdk-nrf:
Github labels
List of changed files detected by CI (2)
Outputs:ToolchainVersion: b77d8c1312 Test Spec & Results: ✅ Success; ❌ Failure; 🟠 Queued; 🟡 Progress; ◻️ Skipped;
|
You can find the documentation preview for this PR at this link. It will be updated about 10 minutes after the documentation build succeeds. Note: This comment is automatically posted by the Documentation Publish GitHub Action. |
.. parsed-literal:: | ||
:class: highlight | ||
|
||
py -3 -m pip install -r requirements.txt | ||
py -3 -m pip install . |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not that I know about python but why can't it do as the build system does and use the in-tree version until a proper updated version is released? See https://github.com/nrfconnect/sdk-nrf/blob/main/cmake/sysbuild/image_signing.cmake#L52
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This step actually installs the in-tree version of imgtool
instead of version from PyPI. Python script by itself has no knowledge where sdk-mcuboot
repository sources are on host computer - that's why I decided to install proper imgtool
through pip. HID configurator scripts could be moved, so using a relative path might be problematic too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The user should already have the correct version if they follow the NCS installation guide correctly. We could minimize this note and notify the user to double-check if they have the correct version of imgtool.
We can also add a reference to the NCS install documentation that covers how to install this tool:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Which people should not be doing, the toolchain comes with a specific version of the tool, sure it's not the version that includes this but this will then pollute the version used by the toolchain going forward? Have asked some others if there is a better way of doing this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The nRF54L MCuboot's pure ED25519 signature requires custom imgtool version (not from PyPI; needs to be installed from source using sdk-mcuboot
repo). Unless I missed something, the custom imgtool version is not installed together with our official toolchain. I am not sure if there is better way of using the custom imgtool in this context than manually installing from source (as currently suggested). Please propose alternative solutions if anything better comes to your mind.
I hope that this is only a temporary workaround and could be removed when mcu-tools/mcuboot#2063 is introduced to imgtool from PyPI. @de-nordic and @nvlsianpu, do you think there is a better way of doing it for now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See how it is done e.g.
doc/internal/conf.py:sys.path.insert(0, str(NRF_BASE / "doc" / "_utils"))
doc/internal/conf.py:sys.path.insert(0, str(ZEPHYR_BASE / "doc" / "_extensions"))
doc/internal/conf.py:sys.path.insert(0, str(NRF_BASE / "doc" / "_extensions"))
doc/kconfig/conf.py:sys.path.insert(0, str(NRF_BASE / "doc" / "_utils"))
doc/kconfig/conf.py:sys.path.insert(0, str(ZEPHYR_BASE / "doc" / "_extensions"))
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then we need to know NRF_BASE
/ZEPHYR_BASE
in scope of the script (it might become problematic e.g. if someone would like to use script outside of the nRF Connect SDK as a standalone tool). Also, the sdk-mcuboot's imgtool
's scripts would need to be located in a known place.
Please keep in mind that we use use image
class exposed by the imgtool package (we do not call imgtool through CLI). Because of that, IMHO relying on packages might be cleaner approach - we build a SUIT-related package from source and install it manually already too.
Also please keep in mind that targets other than nRF54L do not use pure ED25519 signature, so they may still rely on the default imgtool version (extra step from the note could be basically skipped). Maybe we could explicitly comment on that and stick with using package built from source as a temporary workaround (we will use imgtool from PyPI as soon as it starts supporting the pure signature)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MarekPieta , I don't see @nordicjm blocking the change. I value input from various reviewers but this area is not his responsibility. Please keep that in mind.
I personally think that provided toolchain should cover all things needed. If it does not we should request it from team responsible for toolchain - check if we or pluto have a ticket. In the end this tool is not only our problem.
Since the timing is short I expect having the workaround is valid. It will require user interaction and is part of nrf_desktop tools doc only.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MarekPieta, @nordicjm, command pip install .
just installs Python's package from a source code, if that is what you want it is fine for me. I would only add a link to the repository where is imgtool (I don't see it in the readme file, and user may not know how to find it).
Also you can install directly from a git repository like so:
pip install git+ssh://[email protected]/myuser/foo.git@branch_or_tag#subdirectory=stackoverflow
Which could be more convenient for users.
Another thing, command like this could be more precise:
python -m pip install path/to/SomeProject
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I provided source directory path starting from nRF Connect SDK root directory (should be straightforward to find it for an NCS user). I do not provide a complete path in command here as I cannot provide absolute path and relative path might change in case user moves HID configurator scripts locally. Would this approach be ok?
cba5d47
to
f8b2a38
Compare
doc/nrf/releases_and_maturity/releases/release-notes-changelog.rst
Outdated
Show resolved
Hide resolved
.. parsed-literal:: | ||
:class: highlight | ||
|
||
py -3 -m pip install -r requirements.txt | ||
py -3 -m pip install . |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The user should already have the correct version if they follow the NCS installation guide correctly. We could minimize this note and notify the user to double-check if they have the correct version of imgtool.
We can also add a reference to the NCS install documentation that covers how to install this tool:
.. parsed-literal:: | ||
:class: highlight | ||
|
||
py -3 -m pip install -r requirements.txt | ||
py -3 -m pip install . |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MarekPieta , I don't see @nordicjm blocking the change. I value input from various reviewers but this area is not his responsibility. Please keep that in mind.
I personally think that provided toolchain should cover all things needed. If it does not we should request it from team responsible for toolchain - check if we or pluto have a ticket. In the end this tool is not only our problem.
Since the timing is short I expect having the workaround is valid. It will require user interaction and is part of nrf_desktop tools doc only.
f8b2a38
to
c7f1b9a
Compare
1c1876a
to
5cc3f5c
Compare
Change adds support for pure ED25519 signature (used by nRF54L-based devices that enable MCUboot hardware cryptography). imgtool from MCUboot upstream repository does not support this configuration, a dedicated imgtool version from sdk-mcuboot repository must be used. Jira: NCSDK-30745 Signed-off-by: Marek Pieta <[email protected]> Signed-off-by: Pekka Niskanen <[email protected]> Signed-off-by: Divya Pillai <[email protected]>
979b951
to
275c003
Compare
Change adds support for pure ED25519 signature (used by nRF54L based devices that enable MCUboot hardware cryptography). imgtool from MCUboot upstream repository does not support this configuration, a dedicated imgtool version from sdk-mcuboot repository must be used.
Jira: NCSDK-30745