Mbed-cli: Mbed CLI with cache on can leak private source files

[andrewc-arm]

Hi,

I see that Mbed CLI with cache on, it will store .git files in /tmp/mbed-repo-cache for Linux.
This is problematic for situation where the user may simply assume that it has deleted the private source code from where he/she downloaded but in fact the copy code is in /tmp.

We should mention how to wipe out Mbed CLI cache file and explicitly mention that it is user's responsibility to wipe out the private repo files. Also, there should be ways to set up the cache folder location, so that user may put his cache under ~/tmp/ so that it will not easily be compromised as /tmp.

For example, the user may share the VirtualBox image with others not knowing that it contains the private code.

Thanks,

[theotherjimmy]

Hi @andrewc-arm,

Good catch! I think that moving the cache to a user specific location on all OSs would be beneficial.

Problems with /tmp/mbed-repo-cache on Linux:

• correct permissions are required to hide private repos from other users of the same machine.
• persistence through a reboot is not guaranteed, and possibly non-persistence is guaranteed.

I'm not a fan of ~/tmp/mbed-repo-cache, so instead I recomend ~/.local/share/mbed-repo-cache. Any changes to the cache location should include code to migrate from the old cache location to the new one.

[theotherjimmy]

In general,

For example, the user may share the VirtualBox image with others not knowing that it contains the private code.

Is not part of our threat model; we don't plan on plugging the "analog hole". In other words, if you goof up and give someone access to your private data, there's not much we can do about that. We should make it difficult to do though.

[andrewc-arm]

Thanks for the positive feedback.

Is not part of our threat model.

Then we should explicitly mention to the user that

• It is their responsibility to be aware of the code copy existing from the cache directory they provided. (or if default location is chosen, we should print it out where it is)
• We have provided the instructions to wipe it out here and there and how to verify that you have done it correctly (such as taking very long time to import mbed-os)

By the way, it is only /tmp/mbed-repo-cache right? If I wipe that folder, then there is no other place the code copy is made, right?

[theotherjimmy]

@andrewc-arm

Sharing a VM or a user account is not part of our threat model.

We have provided the instructions to wipe it out here and there and how to verify that you have done it correctly (such as taking very long time to import mbed-os)

Yep, that seems reasonable.

By the way, it is only /tmp/mbed-repo-cache right?

Correct

If I wipe that folder, then there is no other place the code copy is made, right?

All locations that you mbed import into may be affected as well, depending on what you imported. You probably knew that, I just want to be extra clear.

[theotherjimmy]

To be clear:

This issue is complete when:

• The cache is stored in a persistent, user-specific location such as a sub-directory of ~/.local/share on linux
• It's possible to remove the cache from an mbed subcommand
• It's possible to verify that the cache has been removed
• The location, removal method and verification method are documented.

[bridadan]

@theotherjimmy think you nailed all of the requirements!

[screamerbg]

Currently, mbed CLI calls tempfile.gettempdir() (https://docs.python.org/2/library/tempfile.html), e.g. repo.cache = loc or os.path.join(tempfile.gettempdir(), 'mbed-repo-cache'). Let's make sure that we add to these requirements:

• Must be unified cross-platform solution. E.g. need to solve this not just for Linux, but any OS.

[theotherjimmy]

Yes, that's nice to state explicitly. I gave an example for Linux to show just how incorrect using a temp dir can be.

[screamerbg]

From a related post:

• mbed cache [default|on|off|none|/path] - turns on or off cache, or sets location
• mbed cache list - shows cached repositories
• mbed cache size - calculates and shows the size of the cache
• mbed cache purge|clean - cleans the cache

[screamerbg]

Since Mbed CLI 1.5.0 and the introduction of the mbed cache feature, the default cache storage location is under the user home directory and essentially guarded by the default permission of the user home dir. I believe this satisfies the requirement.