Skip to content

Commit

Permalink
qutebrowser: fix CVE-2018-10895
Browse files Browse the repository at this point in the history
  • Loading branch information
Robert Schütz committed Jul 11, 2018
1 parent aec2178 commit af1313e
Showing 1 changed file with 8 additions and 1 deletion.
9 changes: 8 additions & 1 deletion pkgs/applications/networking/browsers/qutebrowser/default.nix
View file
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
{ stdenv, lib, fetchurl, fetchzip, python3Packages
{ stdenv, lib, fetchurl, fetchzip, fetchpatch, python3Packages
, makeWrapper, wrapGAppsHook, qtbase, glib-networking
, asciidoc, docbook_xml_dtd_45, docbook_xsl, libxml2
, libxslt, gst_all_1 ? null
Expand Down Expand Up @@ -38,6 +38,13 @@ in python3Packages.buildPythonApplication rec {
sha256 = "01lrbkddm4wagx4hq6cz5qwvb8q8nlz0xa35k317gvr3pmnvgjk8";
};

patches = fetchpatch {
name = "CVE-2018-10895.patch";
url = https://github.com/qutebrowser/qutebrowser/commit/c2ff32d92ba9bf40ff53498ee04a4124d4993c85.patch;
excludes = [ "tests/*" ];
sha256 = "0mdqa9w1p6cmli6976v4wi0sw9r4p5prkj7lzfd1877wk11c9c73";
};

# Needs tox
doCheck = false;

Expand Down

5 comments on commit af1313e

@dotlambda
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But the patch fetched in that commit actually ends up to be empty. That has happened to me more often than I'd like and I recognize the hash by now 😁

@timokau You're sure that patch is empty? That would be fatal because it should fix a security vulnerability. I checked the hash and it seems to be correct.

@timokau
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, to be sure I built this myself and checked the file /nix/store/0y4pbvbislv5rg4z4j4p40zq44qal4vs-CVE-2018-10895.patch. It was empty.

@timokau
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably the glob * gets expanded to multiple arguments, causing filterdiff to fail.

@dotlambda
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a pity. Fixed in f981bad.
Maybe an ofborg check for that hash would be nice. cc @grahamc

@timokau
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See #43538 for a fix without needing ofBorg.

By the way in case you're interested in why this failed: The command expands to filterdiff <options> -x tests/some-file-in-folder other-file-in-folder <actual patch>

filterdiff will than apply to other-file-in-folder (since it is the first argument that doesn't belong to a flag) which is probably not a patch and will be normalized to nothing.

Please sign in to comment.