1. 09 Jun, 2021 2 commits
  2. 21 May, 2021 1 commit
  3. 20 May, 2021 2 commits
  4. 23 Apr, 2021 2 commits
  5. 16 Apr, 2021 5 commits
  6. 11 Feb, 2021 5 commits
  7. 08 Feb, 2021 1 commit
  8. 05 Feb, 2021 3 commits
  9. 28 Jan, 2021 2 commits
  10. 22 Jan, 2021 2 commits
  11. 20 Jan, 2021 2 commits
  12. 19 Jan, 2021 1 commit
  13. 14 Jan, 2021 1 commit
  14. 22 Dec, 2020 2 commits
  15. 18 Dec, 2020 3 commits
  16. 17 Dec, 2020 4 commits
    • martyone's avatar
      Merge branch 'jb52287' into 'master' · d93761c9
      martyone authored
      Fix host-gcc use
      See merge request !41
    • Martin Kampas's avatar
      Drop unused create_argvmods_usr_bin_rules.lua · 44824ec6
      Martin Kampas authored
      It has been obsoleted since commit
      1b7fb2f6 (Create /usr/bin "autorules"
      via init.lua) and commit c85c5397
      (Top-level Makefile: Install rule_constants.lua) stopped installing it.
    • Martin Kampas's avatar
      [sb2] Fix generating argv/envp processing rules for host-gcc. JB#52287 · 1dead59e
      Martin Kampas authored
      This fixes commit dbcf9d60 (support
      different gcc search patchs)
    • Martin Kampas's avatar
      [sb2] prepare_exec: Do not discard changes to environment. JB#52287 · be954f53
      Martin Kampas authored
      Initially, my_envp equals to *new_envp, then it is modified. Those
      modifications are lost when *new_envp is used after that.
      The (possibly) discarted modifications to env. variables affect
      Regarding SBOX_DISABLE_MAPPING, consider a host executable being
      executed by sb2 and trying to execute another host executable. With
      mapping not disabled, the other executable may be mapped to a different
      executable under target/tools root instead. In most cases this is likely
      to happen unnoticed. It breaks when there is an incompatibility between
      those, e.g., when the host executable is a GCC compiler trying to
      execute some of its internal tools - an i486 host compiler may end up
      executing an arm assembler this way.
      Trying to explain why *new_envp was used here, I don't believe it was a
      typo. At the same time I don't believe it was intentional to change the
      logic this way. I can't think of a reason to discard changes to the
      afforementioned env. vars. To me it seems inevitable to keep them set.
      Also, change was introduced with commit
      3f042f36 (Execs: Postprocess native
      dynamic binaries with C code) whose only objective seems to be
      reimplementation of some Lua code in C.  Maybe it was done to deal with
      some compiler bug and no one noticed it breaks things, as this only
      breaks in rather special cases like the one mentioned above.
  17. 09 Dec, 2020 2 commits