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
Updates to the latest version of the desktop client available. Tested
the config migration from `nextcloud-client` 2.3.3 with a Nextcloud
14.0.3 instance (hosted using `services.nextcloud`).
Additionally the derivation required the following changes:
* Dropped `Qt5Sql` patch: this has been fixed upstream and isn't needed
anymore (furthermore their CMake structure has changed and the patch
wouldn't apply anymore on 2.5.0).
* Moved to a new upstream repository (nextcloud/desktop), kept
`fetchgit` to properly fetch submodules.
* Added OpenSSL 1.1 integration: `libsync` (the syncing provided by this
package) requires 1.1, furthermore the linking flags had to be fixed
manually by passing `NIX_LDFLAGS` to the derivation.
Furthermore I moved the support for a Gnome3 keyring into its own
wrapper to avoid a full rebuild of the package whenever you alter
`withGnomeKeyring` in an override expressions.
It's still possible to enable keyring (now without recompile) like this:
```
nextcloud-client.override { withGnomeKeyring = true; }
```
To override the derivation itself you now have to use
`nextcloud-client-unwrapped`:
```
nextcloud-client-unwrapped.overrideAttrs (old: {
src = yoursrc;
})
```
Helm uses its version to determine what version of Tiller (the server
component) to install. Without this patch it thinks it is `v2.11+unreleased` and
tries to download `gcr.io/kubernetes-helm/tiller:v2.11`. After the patch it
correctly downloads `gcr.io/kubernetes-helm/tiller:v2.11.0`. Fixes#49120.
providers are already compiled independently so we don't need Hydra to
follow terraform_MAJ_MIN_full to have them all compiled.
Instead of having to create two aliases per release, add a "full"
passthru for that common use-case.
Eg:
terraform_0_11_full -> terraform_0_11.full
rust-cbindgen did apply some breaking changes which requires the added
patch in order to compile until a firefox version with the fix gets
released. Firefox 63.0.3 is supposed to carry the required patches. This
should only be required for a short term.
TODO: We're still using the old API ID (like the Arch package) which
should be used for testing only.
I've tried to contact the Telegram team multiple times via different
channels but didn't get a response so far. See [0],[1] for more details.
[0]: https://github.com/telegramdesktop/tdesktop/issues/4717
[1]: 65b2db2160
This update bumps the package to the latest stable version containing a
few security fixes:
- CVE-2018-12392: Crash with nested event loops
When manipulating user events in nested loops while opening a document
through script, it is possible to trigger a potentially exploitable
crash due to poor event handling.
- CVE-2018-12393: Integer overflow during Unicode conversion while loading JavaScript
A potential vulnerability was found in 32-bit builds where an integer
overflow during the conversion of scripts to an internal UTF-16
representation could result in allocating a buffer too small for the
conversion. This leads to a possible out-of-bounds write.
Note: 64-bit builds are not vulnerable to this issue.
- CVE-2018-12395: WebExtension bypass of domain restrictions through header rewriting
By rewriting the Host request headers using the webRequest API, a
WebExtension can bypass domain restrictions through domain fronting.
This would allow access to domains that share a host that are
otherwise restricted.
- CVE-2018-12396: WebExtension content scripts can execute in disallowed contexts
A vulnerability where a WebExtension can run content scripts in
disallowed contexts following navigation or other events. This allows
for potential privilege escalation by the WebExtension on sites where
content scripts should not be run.
- CVE-2018-12397: Missing warning prompt when WebExtension requests local file access
A WebExtension can request access to local files without the warning
prompt stating that the extension will "Access your data for all
websites" being displayed to the user. This allows extensions to run
content scripts in local pages without permission warnings when a
local file is opened.
- CVE-2018-12389: Memory safety bugs fixed in Firefox ESR 60.3
Mozilla developers and community members Daniel Veditz and Philipp
reported memory safety bugs present in Firefox ESR 60.2. Some of these
bugs showed evidence of memory corruption and we presume that with
enough effort that some of these could be exploited to run arbitrary
code.
- CVE-2018-12390: Memory safety bugs fixed in Firefox 63 and Firefox ESR 60.3
Mozilla developers and community members Christian Holler, Bob Owen,
Boris Zbarsky, Calixte Denizet, Jason Kratzer, Jed Davis, Taegeon Lee,
Philipp, Ronald Crane, Raul Gurzau, Gary Kwong, Tyson Smith, Raymond
Forbes, and Bogdan Tara reported memory safety bugs present in Firefox
62 and Firefox ESR 60.2. Some of these bugs showed evidence of memory
corruption and we presume that with enough effort that some of these
could be exploited to run arbitrary code.
Source: https://www.mozilla.org/en-US/security/advisories/mfsa2018-27/
Merging staging into staging-next even though we haven't merged staging-next into master yet.
The motivation for this merge is that it's been a while since we merged into master causing
the 3 branches to diverge too much.