| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| 0004-SHELL-Disable-sh-c-command-sh-c-exec-command-optimiza.diff | shell: Disable sh -c "command" -> sh -c "exec command" optimization Bugs #642706 (bin-prot FTBFS) and #642835 (sexplib310 FTBFS) can be fixed by reverting the patch submitted at [1]. I don't understand why. [1] http://thread.gmane.org/gmane.comp.shells.dash/556 While investigating #642706, in the failing case, I observed that a cpp process called with "sh -c" gets SIGPIPE while writing to stderr. In the succeeding case, the write is successful, and is read by the ocamlbuild process that started "sh -c cpp ...". |
Stphane Glondu <glondu@debian.org> | no | 2011-09-25 | ||
| 0007-Don-t-execute-binary-files-if-execve-returned-ENOEXE.diff | Don't execute binary files if execve() returned ENOEXEC Both "dash -c foo" and "./foo" are supposed to be able to run hashbang-less scripts, but attempts to execute common binary files tend to be nasty: especially both ELF and PE tend to make dash create a bunch of files with unprintable names, that in turn confuse some tools up to causing data loss. Thus, let's read the first line and see if it looks like text. This is a variant of the approach used by bash and zsh; mksh instead checks for signatures of a bunch of common file types. POSIX says: "If the executable file is not a text file, the shell may bypass this command execution.". |
Adam Borowski <kilobyte@angband.pl> | no | 2017-01-24 | ||
| 0008-Support-e-in-echo-and-printf-builtins.diff | Support \e in "echo" and "printf" builtins | Adam Borowski <kilobyte@angband.pl> | no | 2014-06-28 | ||
| 0009-dash-Fix-stack-overflow-from-infinite-recursion-in-s.patch | dash: Fix stack overflow from infinite recursion in script | Chris Lamb <lamby@debian.org> | no | debian | 2018-02-15 | |
| 0010-exec-Check-executable-bit-when-searching-path.patch | exec: Check executable bit when searching path This is inherited from NetBSD. There is even a commented-out block of code that tried to fix this. Anyway, we now have faccessat so we can simply use it. |
Herbert Xu <herbert@gondor.apana.org.au> | no | debian | 2021-11-10 | |
| 0012-enable-large-file-support-when-available.patch | enable large file support when available | You-Sheng Yang <vicamo@gmail.com> | no | 2018-12-12 | ||
| 0013-enable-hardening-for-helpers.patch | Add $(CPPFLAGS), $(CFLAGS) and $(LDFLAGS) to $(COMPILE_FOR_BUILD) so that helpers are built with hardening | Andrej Shadura <andrewsh@debian.org> | no | 2019-07-18 | ||
| 0017-histedit-Fix-infinite-loop-when-using-fc--s.patch | histedit: Fix infinite loop when using 'fc -s' When compiling with libedit, he.num may somehow overrun last, causing an infinite loop when using fc -s. This mild change to the check plugs it. |
<usawashi16@yahoo.co.jp> | no | debian | 2019-04-27 | |
| 0018-builtin-Don-t-early-exit-when-first-hash-r-is-found.patch | builtin: Don't early-exit when first hash -r is found This fixes incorrectly-accepted "hash -rv" being equivalent to hash -r (well, hash -r[literally anything] being equivalent to hash -r) Also remove -v from the manual, it doesn't appear to have ever existed |
<nabijaczleweli@nabijaczleweli.xyz> | no | debian | 2022-12-14 | |
| 0019-builtin-Actually-accept-ulimit-r.patch | builtin: Actually accept ulimit -r The original commit that added it supposes this works, but it only adds it to the ulimit -a listing and the manual, but doesn't allow it as an option. |
Vincent Lefevre <vincent@vinc17.net> | no | debian | 2022-12-16 | |
| 0020-Update-manpages.patch | Update manpages The explicit arguments were missing, also exchange expr subst for arithmetic and fix the spacing around Bell Labs The manual now contains all built-ins The current wording says that given printf a b c d a is the format, c and d are processed as noted, but b is unspecified Multiple issues: * the encoding is not always ASCII * what ASCII code is assigned to * dash isn't internationalised (this is nonconformant but out of scope), and uses the next /byte/; in a UTF-8 locale: $ printf %d\\n \' 196 $ printf %d\\n \' 196 this is in contrast to POSIX (and bash), which says: > If the leading character is a single-quote or double-quote, > the value shall be the numeric value in the underlying codeset > of the character following the single-quote or double-quote. (i.e. mbrtowc(&val, argv[n], ...)) Only true was documented, add false just below it (out of order, but so is true, and the grouping makes much more sense). |
<nabijaczleweli@nabijaczleweli.xyz> | no | debian | 2022-12-14 | |
| 9001-Add-privmode-Part-1.diff | Implement privmode, part 1 | Tavis Ormandy <taviso@google.com> | no | http://article.gmane.org/gmane.comp.security.oss.general/10969 | 2013-08-22 | |
| 9002-Add-privmode-Part-2.diff | Implement privmode, part 2 | Harald van Dijk <harald@gigawatt.nl> | no | http://article.gmane.org/gmane.comp.security.oss.general/10972 | 2013-08-22 |