| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| prevent_intersphinx_network_access.patch | Prevent network access during build | Joe Healy <joehealy@gmail.com> | no | debian | 2018-01-24 | |
| Make-the-Salt-Proxy-environment-aware.patch | Make the Salt Proxy environment aware The Salt proxy minion is looking for proxy minion modules in `salt://_proxy/`. It does so however only in the default `base` environment. On setups which do not use `base` or shall be executed in a different environment this breaks: /etc/salt/master: ``` ... file_roots: noc: - /srv/salt ... ``` ``` $ grep "proxyenabled" /srv/salt/_proxy/junos_manager.py __proxyenabled__ = ['junos_manager'] $ salt-proxy --proxyid=dev1 -l debug ... [DEBUG ] rest_sample proxy __virtual__() called... [INFO ] ssh_sample proxy __virtual__() called... [DEBUG ] Could not LazyLoad junos_manager.grains [DEBUG ] Could not LazyLoad junos_manager.init [ERROR ] Proxymodule junos_manager is missing an init() or a shutdown() or both. Check your proxymodule. Salt-proxy aborted. [WARNING ] Stopping the Salt Proxy Minion [ERROR ] -1 [INFO ] The proxy minion is shutting down.. [INFO ] The Salt ProxyMinion is shut down ``` This is because the loader only looks for _proxy modules in the `base` environment. This commit fixes this (but might possibly break other things, though I did not find side-effects). Initial pull request: https://github.com/saltstack/salt/pull/36704 |
Arno Toell <arno.toell@profitbricks.com> | yes | 2016-09-30 | ||
| remove-privacy-breach.patch | Remove privacy breach in docs | Ondřej Nový <onovy@debian.org> | no | 2018-01-17 | ||
| Make-default-pki-directory-configurable.patch | Make default pki directory configurable The files in /etc/salt/pki are not configuration files in the sense of the FHS ("local file used to control the operation of a program"). Debian wants to change the default location to /var/lib/salt/pki (to properly follow FHS and to allow setting StateDirectory in the salt master systemd configuration). Therefore introduce a STATE_DIR syspaths variable which defaults to CONFIG_DIR, but can be individually customized. fixes #3396 |
Benjamin Drung <benjamin.drung@profitbricks.com> | yes | debian | 2018-02-20 | |
| run-salt-master-as-salt-user.patch | Run salt-master daemon as 'salt' user | Benjamin Drung <benjamin.drung@cloud.ionos.com> | no | 2018-01-25 | ||
| Support-unittest.mock-from-Python-3.6-again.patch | Support unittest.mock from Python >= 3.6 again Python 3.6 contains unittest.mock which provide all needed functions (including MagicMock.assert_called). Therefore reverts commit 9d004f6512d0619df895e0aca56143490a34337c partially to only require mock >= 2.0.0 for Python < 3.6. |
Benjamin Drung <benjamin.drung@profitbricks.com> | yes | upstream | 2018-03-07 | |
| Skip-failing-HgPillarTestCase.test_base.patch | Skip failing HgPillarTestCase.test_base The `HgPillarTestCase.test_base` test case fails: ``` test_base (unit.pillar.test_hg_pillar.HgPillarTestCase) [CPU:9.5%|MEM:51.7%] check hg repo is imported correctly ... Füge top.sls hinzu Füge user.sls hinzu 18:08:29,187 [salt.template :236 ][ERROR ] The renderer "yaml_jinja" is not available 18:08:29,187 [salt.loader :650 ][CRITICAL] The renderer yaml_jinja is unavailable, this error is often because the needed software is unavailable ERROR Exception ignored in: <function Pillar.__del__ at 0x7f35cf6e5710> Traceback (most recent call last): File "salt/pillar/__init__.py", line 1126, in __del__ self.destroy() File "salt/pillar/__init__.py", line 1121, in destroy if self._closing: ====================================================================== [CPU:13.2%|MEM:51.7%] check hg repo is imported correctly |
Benjamin Drung <benjamin.drung@cloud.ionos.com> | no | 2020-01-22 | ||
| doc-fix-logo-link.patch | doc: Fix logo link The link on the brand image was pointing to index.html which does not exist. The index file seems to be contents.html. |
Steffen Kockel <steffen.kockel@profitbricks.com> | no | 2019-04-23 | ||
| Use-jquery.js-from-sphinx.patch | Use jquery.js from sphinx Sphinx uses libjs-jquery >= 1.11.1 which is newer than jquery-1.9.1.js shipped by salt. Therefore jquery.js from sphinx can be used again. |
Benjamin Drung <benjamin.drung@profitbricks.com> | no | 2019-04-24 | ||
| ensure-searchtools.js-gets-included.patch | doc: Ensure searchtools.js gets included Searchtools did not get included with Debian > stretch and Sphinx > 1.6.7. |
Steffen Kockel <steffen.kockel@profitbricks.com> | no | 2019-04-24 | ||
| Fix-various-spelling-mistakes.patch | Fix various spelling mistakes | Benjamin Drung <benjamin.drung@cloud.ionos.com> | yes | 2020-10-09 | ||
| tests-Replace-os.getlogin-by-getpass.getuser.patch | tests: Replace os.getlogin by getpass.getuser The test `test_run_cwd_in_combination_with_runas` fails in some test environments (like Debian autopkgtest): ``` ====================================================================== [CPU:0.0%|MEM:6.5%] cmd.run executes command in the cwd directory |
Benjamin Drung <benjamin.drung@cloud.ionos.com> | no | 2020-07-14 | ||
| Fix-various-spelling-mistakes-in-release-notes.patch | Fix various spelling mistakes in release notes upstream generated the release notes and won't accept fixing spelling mistakes there. |
Benjamin Drung <benjamin.drung@cloud.ionos.com> | no | 2020-01-16 | ||
| alternatives-Do-not-access-var-lib-dpkg-alternatives.patch | alternatives: Do not access /var/lib/dpkg/alternatives directly salt contains modules, which directly access the dpkg internal database, instead of using one of the public interfaces provided by dpkg. This is a problem for several reasons, because even though the layout and format of the dpkg database is administrator friendly, and it is expected that those might need to mess with it, in case of emergency, this “interface” does not extend to other programs besides the dpkg suite of tools. The admindir can also be configured differently at dpkg build or run-time. And finally, the contents and its format, will be changing in the near future. So use something like: ``` update-alternatives --query $name ``` to query information about alternatives in a machine readable format. Also add tests cases for `alternatives.show_links` using real data from the distributions. |
Benjamin Drung <benjamin.drung@cloud.ionos.com> | yes | debian upstream | 2020-10-16 | |
| dpkg_lowpkg-Do-not-access-var-lib-dpkg-info-package-.patch | dpkg_lowpkg: Do not access /var/lib/dpkg/info/<package>.list directly salt contains modules, which directly access the dpkg internal database, instead of using one of the public interfaces provided by dpkg. This is a problem for several reasons, because even though the layout and format of the dpkg database is administrator friendly, and it is expected that those might need to mess with it, in case of emergency, this “interface” does not extend to other programs besides the dpkg suite of tools. The admindir can also be configured differently at dpkg build or run-time. And finally, the contents and its format, will be changing in the near future. So use something like: ``` dpkg-query --showformat '${db-fsys:Last-Modified}\n' --show $pkg ``` to get the mtime from /var/lib/dpkg/info/<package>.list files. |
Benjamin Drung <benjamin.drung@cloud.ionos.com> | yes | debian upstream | 2020-10-15 | |
| dpkg_lowpkg-Drop-reading-var-lib-dpkg-available-dire.patch | dpkg_lowpkg: Drop reading /var/lib/dpkg/available directly salt contains modules, which directly access the dpkg internal database, instead of using one of the public interfaces provided by dpkg. This is a problem for several reasons, because even though the layout and format of the dpkg database is administrator friendly, and it is expected that those might need to mess with it, in case of emergency, this “interface” does not extend to other programs besides the dpkg suite of tools. The admindir can also be configured differently at dpkg build or run-time. And finally, the contents and its format, will be changing in the near future. `/var/lib/dpkg/available` should not be read directly. Instead `dpkg-query --print-avail` should be used. The `/var/lib/dpkg/available` file is only kept up-to-date when using dselect, but nowadays `apt` is used, and therefore this file does not provide much more information than `dpkg-query -W`. Users of APT-based frontends should use `apt show` or in our case the `pkg.show` salt module. `dpkg-query --print-avail` provides following keys (on Ubuntu 20.04): ``` $ dpkg-query --print-avail | sed 's/:.*$//' | sort | uniq Architecture Breaks Bugs Build-Essential Built-Using Cnf-Extra-Commands Cnf-Priority-Bonus Conflicts Depends Description Description-md5 Enhances Essential Filename Homepage Important Installed-Size Maintainer MD5sum Multi-Arch Origin Original-Maintainer Package Pre-Depends Priority Provides Recommends Replaces Section SHA1 SHA256 Size Source Suggests Supported Task Version ``` Following keys cannot be retrieved by `dpkg-query -W`: ``` Build-Essential Built-Using Cnf-Extra-Commands Cnf-Priority-Bonus Important Multi-Arch Original-Maintainer SHA1 SHA256 Supported ``` Please use `pkg.show` for those keys. Following additional keys could be retrieved if needed: ``` Breaks Enhances Essential Filename Pre-Depends Priority Suggests ``` Without calling `_get_pkg_ds_avail`, `info` just calls `_get_pkg_info` and converts it into a dict and add a license field. Since `_get_pkg_ds_avail` is used nowhere else, move it into `info`. Do not query Installed-Size, because it was stripped as "technical" key previously. |
Benjamin Drung <benjamin.drung@cloud.ionos.com> | yes | debian upstream | 2020-10-16 | |
| Fix-test-suite-failing-with-Python-exit-code-120.patch | Fix test suite failing with Python exit code 120 When running the salt test suite in autopkgtest, Python fails with exit code 120 at the end. autopkgtest uses bash's process substitution to redirect stdout and stderr (using tee to store them). These bash and tee processes will show up as children of the called test suite. ``` bash -c 'python3 ./tests/runtests.py' 2> >(tee -a stderr >&2) > >(tee -a stdout) ``` This command will have following process tree: ``` python3 ./tests/runtests.py \_ /bin/bash | \_ tee -a stderr \_ /bin/bash \_ tee -a stdout ``` `SaltTestingParser.finalize` is called at the end of the test suite. It fetches all child process and kills them. This also kills the bash and tee commands. This leads to stdout and stderr to be closed and Python cannot flush the buffered data in the standard streams any more. This leads Python to change the exit code to 120 (see documentation for `sys.exit`). To prevent killing the children that were launched by the test environment, remember all children that exists at the start of the test suite run and do not kill those children. |
Benjamin Drung <benjamin.drung@cloud.ionos.com> | yes | 2020-10-22 | ||
| Fix-test_run_all_output_loglevel_debug.patch | Fix test_run_all_output_loglevel_debug The info level log message produced by `cmdmod.run_all` only contains the first argument. Upstream commit 85e6f045557775425005f70f7c7f85919ae640c5 migrates the test case to pytest. During that change, this bug is fixed. |
Benjamin Drung <benjamin.drung@cloud.ionos.com> | not-needed | 2021-03-02 | ||
| test_module_names-Exclude-unit.auth.test_auth.patch | test_module_names: Exclude unit.auth.test_auth `tests/unit/auth/test_auth.py` tests code in `salt/auth/__init__.py`. Since there is no mapping for `__init__.py`, exclude it from `test_module_name_source_match`. |
Benjamin Drung <benjamin.drung@cloud.ionos.com> | no | 2021-03-02 | ||
| Fix-CVE-2021-31607-in-snapper-module.patch | Fix CVE-2021-31607 in snapper module In SaltStack Salt 2016.9 through 3002.6, a command injection vulnerability exists in the snapper module that allows for local privilege escalation on a minion. The attack requires that a file is created with a pathname that is backed up by snapper, and that the master calls the snapper.diff function (which executes popen unsafely). Cherry-pick the fix from pull request #59648 [1], but also fix the regression introduced by that commit [2]. [1] https://github.com/saltstack/salt/pull/59648 [2] https://github.com/saltstack/salt/issues/60046 |
Benjamin Drung <benjamin.drung@ionos.com> | no | 2021-04-26 | ||
| Fix-onlyif-unless-when-multiple-conditions.patch | Fix onlyif/unless when multiple conditions Backport following upstream commits to fix onlyif/unless when multiple conditions are given: * fa03cfc0de834b095db48e49fd5d45ccfa7963c3 * f51db8dbe513de014f693b516eb0b22944464f00 * 7eefab14409afb11bd86cdf2cf47bc8ffcf9e42e * 3629335bd3db8d4f188531b92179941289e620e5 * 6ab62869c8394d46385e4fdf5deed317822452cf |
Benjamin Drung <benjamin.drung@ionos.com> | not-needed | 2021-05-04 | ||
| loader-Fix-loading-grains-with-annotations.patch | loader: Fix loading grains with annotations If custom grain modules use annotations, salt will fail to load them. Example grain: ``` from typing import Dict def example_grain() -> Dict[str, str]: return {"example": "42"} ``` `salt-call grains.items` will print this exception: ``` Failed to load grains defined in grain file ... in function <...>, error: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/salt/loader.py", line 847, in grains parameters = salt.utils.args.get_function_argspec(funcs[key]).args File "/usr/lib/python3/dist-packages/salt/utils/args.py", line 271, in get_function_argspec aspec = _getargspec(func) File "/usr/lib/python3/dist-packages/salt/utils/args.py", line 40, in _getargspec "Function has keyword-only arguments or annotations" ``` Python recommends to use `inspect.signature` instead of `inspect.getfullargspec` (which is only needs to maintain compatibility with the Python 2 `inspect` module API). Since salt only supports Python 3, drop using the wrapper function `get_function_argspec` and use `inspect.signature` directly. |
Benjamin Drung <benjamin.drung@ionos.com> | yes | 2021-06-01 | ||
| CVE-2021-21996.patch | CVE-2021-21996 | Markus Koschany <apo@debian.org> | no | debian | https://github.com/saltstack/salt/commit/0b75ba190fda9c04cc026ad1aa4a6d572f40349b | 2021-11-18 |