## Summary [//]: # (Summarize the bug encountered concisely) It came to light while discussing potential new features for the new remote plugin in !581, that we might be relying on the user's `umask` to determine what permissions `local` sources will have when staged. ## Steps to reproduce [//]: # (How one can reproduce the issue - this is very important) ## What is the current bug behavior? [//]: # (What actually happens) The result of staging local sources can depend on how the BuildStream project was stored or obtained (was it in a tarball ? was it cloned in a git repository ?), or local host configuration (what is the user's `umask` ?). ## What is the expected correct behavior? [//]: # (What you should see instead) The result of staging local sources should always be deterministic ## Relevant logs and/or screenshots [//]: # (Paste any relevant logs - please use code blocks ``` to format console output, logs, and code as it's hard to read otherwise. You can also add a Snippet and link it here. Check the markdown giude on Gitlab for further tips) ## Possible fixes [//]: # (If you can, link to the line of code that might be responsible for the problem) Not sure what the solution for this will be, perhaps we need: * A sane default: * Fully deterministic mode bits set at stage time, accounting only for whether the `local` file is executable or not * This approach makes a reasonable assumption that whatever way you obtained your project, the local files inside the project directory at least retained the information of whether the file was executable or not. * This would by default, e.g. use always `0755` for executable files, and `0644` for non-executable files * Some way to control the permission bits for individual files, only for the case where the user asks for that ## Other relevant information [//]: # (Add the BuildStream version. Substitute below the "x" by "1", "2" or the right version. Add more than one version if necessary) * BuildStream version affected: /milestone %BuildStream_v1.4 ----