`west update` does not validate the origin of a SHA

There is a potential flaw in how west handles SHAs that can potentially lead to unexpected behavior.

If a user updates the manifest file: https://github.com/zephyrproject-rtos/zephyr/blob/f2cc6249158be67c77c8b1fd8ad4eb5d6d051b01/west.yml#L29, with a local SHA

projects:
    - name: hal_atmel
      revision: <Local only SHA>
      path: modules/hal/atmel

then west update will still work. User at some point might commit and push this change remote, and for other users fetching this changed manifest, west update will fail, as the SHA is not remotely available.

Another side effect, could be when working with multiple upstream, as example working with both zephyr and NCS, I could add this to my manifest:

remotes:
      # nRF Connect SDK base URL.
    - name: ncs
      url-base: https://github.com/NordicPlayground
...
projects:
...
 - name: mcuboot
      repo-path: fw-nrfconnect-mcuboot
      revision: 135f716bfb9e2ffe926e3fed65bf825bf1d953da # SHA in Zephyr fork, NOT in NCS
      remote: ncs
...

and west update will work if I have that SHA already due to Zephyr manifest west update https://github.com/zephyrproject-rtos/mcuboot/commit/135f716bfb9e2ffe926e3fed65bf825bf1d953da but as that SHA is not available in NCS mcuboot fork, one might argue that west update should have failed with an error.

Now, having the possibility to change a SHA to something locally available is useful for local testing, but I think we should discuss if this is correct behavior. Currently I see a couple of possibilities:

1. Document this behavior, and state this is intended
2. Ensure the SHA is present in the remote given, before checkout (will make testing will local SHA less convinient) 2b) Same as 2), but allow the keyword remote: local to keep the behavior in 1)

So one could write:

 - name: mcuboot
      repo-path: fw-nrfconnect-mcuboot
      revision: 135f716bfb9e2ffe926e3fed65bf825bf1d953da # SHA in Zephyr fork, NOT in NCS
      remote: local

Note: triggered by this: https://github.com/zephyrproject-rtos/west/pull/331#discussion_r345621585

[mbolivar]

User at some point might commit and push this change remote, and for other users fetching this changed manifest, west update will fail, as the SHA is not remotely available.

I think that is a user error, personally. West doesn’t push – it only pulls. If we start to push, we have to increase the complexity of west in a way I don’t see a clear benefit for in this case.

1. Document this behavior, and state this is intended
2\. Ensure the SHA is present in the remote given, before checkout (will make testing will local SHA less convinient)
    2b) Same as 2), but allow the keyword `remote: local` to keep the behavior in 1)

I think it is important that west should work locally as much as possible. People get work done on airplanes, etc. Especially open source developers that go to a lot of conferences 😃.

I read through the west update documentation (https://docs.zephyrproject.org/latest/guides/west/repo-tool.html#main-commands) and the main thing I can see is that this step would need to be changed:

Fetches any project revisions in the manifest file which are not already pulled from the remote

Would you agree?

[marc-hb]

User at some point might commit and push this change remote, and for other users fetching this changed manifest, west update will fail, as the SHA is not remotely available.

Isn’t such a mistake instantly caught by even the most basic Continuous Integration?

It’s basically a variant of forgetting to add a new file.