According to Neomutt's autocrypt manual
<https://neomutt.org/guide/autocryptdoc.html>, autocrypt needs to be
enabled in the `configureFlags` and `sqlite` is a new dependency.
Since Oct 14, 2017 we warned users still executing `neomutt`
through the `mutt` binary, so we can assume everybody read the notice,
updated his config, and can drop the wrapper.
Whenever we create scripts that are installed to $out, we must use runtimeShell
in order to get the shell that can be executed on the machine we create the
package for. This is relevant for cross-compiling. The only use case for
stdenv.shell are scripts that are executed as part of the build system.
Usages in checkPhase are borderline however to decrease the likelyhood
of people copying the wrong examples, I decided to use runtimeShell as well.
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
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/neomutt/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/ww06xw1m1b0r4fy308kwa6vvj4cyy1yk-neomutt-20180512/bin/neomutt -h’ got 0 exit code
- ran ‘/nix/store/ww06xw1m1b0r4fy308kwa6vvj4cyy1yk-neomutt-20180512/bin/neomutt --help’ got 0 exit code
- ran ‘/nix/store/ww06xw1m1b0r4fy308kwa6vvj4cyy1yk-neomutt-20180512/bin/.neomutt-wrapped -h’ got 0 exit code
- ran ‘/nix/store/ww06xw1m1b0r4fy308kwa6vvj4cyy1yk-neomutt-20180512/bin/.neomutt-wrapped --help’ got 0 exit code
- found 20180512 with grep in /nix/store/ww06xw1m1b0r4fy308kwa6vvj4cyy1yk-neomutt-20180512
- directory tree listing: https://gist.github.com/8d13b2cd77148163ee7c664ce4cdba07
- du listing: https://gist.github.com/9755eddec256452bf53913477fd2bebb
The mime.types file shipped with neomutt is pretty basic so we use the one put
together by Gentoo from a dedicated mime-types derivation as it vastly improves
the handling of attachments.
Neomutt will by default look for /etc/mime.types which isn't present in order to
map file extensions to mime types.
If this file isn't found, and a message has a png attached with
application/octet-stream mime type, neomutt will not know what to do with it.
- neomutt has changed the binary name so we enable "mutt" via a wrapper script
with a warning
- we don't have to manually run the prepare.sh script as autoreconfHook handles
everything for us
- doc generation was previously trying to fetch DTDs from the net
