summaryrefslogtreecommitdiff
path: root/pkgs/development/python-modules/GitPython/hardcode-git-path.patch
diff options
context:
space:
mode:
authorMaximilian Bosch <maximilian@mbosch.me>2018-11-22 21:29:14 +0100
committerMaximilian Bosch <maximilian@mbosch.me>2018-11-26 01:51:41 +0100
commit991d4bf68c7242dfb94f6d276c23749afc8c956d (patch)
tree99f7e7dbe634d2af993625094dc441891c0be617 /pkgs/development/python-modules/GitPython/hardcode-git-path.patch
parent21773f1d431a6181e6bbd94abaeba7d36bdb204a (diff)
mutt/neomutt: work around S/MIME issues with `application/pgp-encrypted`
The original issue can be reproduced when sending with an unpatched `mutt` or `neomutt` an email with an attachement which as han `.asc` extension. This will be interpreted as `application/pgp-encrypted` which experiences special logic, in the end the attachement will contain "Version: 1"[1][2][3] Right now, there are the following issues in the {,neo}mutt packages: * `mutt.override { smimeSupport = true }` fails to build since the Debian patch results in a 404. Debian moved their packages to `salsa.debian.org`. However we can't use a versioned URL for this as Debian only tracks the Mutt versions that are available in their releases. The patch doesn't touch Mutt's core and is therefore simple to rebase, so sticking to the 1.10.2 patch for now should be sufficient. * The original issue was never fixed in NeoMutt, currently we use the S/MIME database from `pkgs.mime-types` which contains the issue with `application/pgp-encrypted` as well. After some discussion[4] it seems to be the best decision to use the `mailcap` database distributed by Fedora[5] which fixes the issue rather than `mime-types` v9 from 2012. [1] https://bugs.archlinux.org/task/43319 [2] https://bugs.gentoo.org/534658 [3] https://github.com/neomutt/neomutt/blob/neomutt-20180716/sendlib.c#L490-L496 [4] https://github.com/NixOS/nixpkgs/pull/50927#issuecomment-441383260 [5] https://pagure.io/mailcap
Diffstat (limited to 'pkgs/development/python-modules/GitPython/hardcode-git-path.patch')
0 files changed, 0 insertions, 0 deletions