[PATCH] gnu: libssh: Update to 0.7.6 [fixes CVE-2018-10933].

  • Done
  • quality assurance status badge
Details
2 participants
  • Leo Famulari
  • Ludovic Courtès
Owner
unassigned
Submitted by
Leo Famulari
Severity
normal
L
L
Leo Famulari wrote on 16 Oct 2018 20:22
(address . guix-patches@gnu.org)(address . ludo@gnu.org)
5180914feebeadac877e9f9f540f0a6c5aab3baf.1539713945.git.leo@famulari.name
This update should be tested with users of guile-ssh.

Also, Ludo, the bug report of the patch removed here is no longer online
(they have a new bug tracker at https://bugs.libssh.org/). The patch
doesn't apply, but since I can't read the bug report, I don't know if
the problem is fixed upstream, or if we should adapt our patch.

* gnu/packages/ssh.scm (libssh): Update to 0.7.6.
[source]: Remove 'libssh-hostname-parser-bug.patch'.
* gnu/packages/patches/libssh-hostname-parser-bug.patch: Delete file.
* gnu/local.mk (dist_patch_DATA): Remove it.
---
gnu/local.mk | 1 -
.../patches/libssh-hostname-parser-bug.patch | 31 ---------
gnu/packages/ssh.scm | 63 +++++++++----------
3 files changed, 29 insertions(+), 66 deletions(-)
delete mode 100644 gnu/packages/patches/libssh-hostname-parser-bug.patch

Toggle diff (125 lines)
diff --git a/gnu/local.mk b/gnu/local.mk
index b8248e8da..8171fb2db 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -901,7 +901,6 @@ dist_patch_DATA = \
%D%/packages/patches/libsndfile-CVE-2017-8361-8363-8365.patch \
%D%/packages/patches/libsndfile-CVE-2017-8362.patch \
%D%/packages/patches/libsndfile-CVE-2017-12562.patch \
- %D%/packages/patches/libssh-hostname-parser-bug.patch \
%D%/packages/patches/libssh2-fix-build-failure-with-gcrypt.patch \
%D%/packages/patches/libtar-CVE-2013-4420.patch \
%D%/packages/patches/libtheora-config-guess.patch \
diff --git a/gnu/packages/patches/libssh-hostname-parser-bug.patch b/gnu/packages/patches/libssh-hostname-parser-bug.patch
deleted file mode 100644
index 69f46cbdd..000000000
--- a/gnu/packages/patches/libssh-hostname-parser-bug.patch
+++ /dev/null
@@ -1,31 +0,0 @@
-Fix "Hostname" parsing in OpenSSH config files, as reported
-at <https://red.libssh.org/issues/260>.
-
-From: Niels Ole Salscheider <niels_ole@salscheider-online.de>
-Date: Mon, 8 May 2017 17:36:13 +0200
-Subject: [PATCH] Fix reading of the first parameter
-
-This is a fixup for 7b8b5eb4eac314a3a29be812bef0264c6611f6e7.
-Previously, it would return as long as the parameter was _not_ seen
-before. It also did not handle the case for the unsupported opcode (-1)
-which would cause a segfault when accessing the "seen" array.
----
- src/config.c | 5 +++--
- 1 file changed, 3 insertions(+), 2 deletions(-)
-
-diff --git a/src/config.c b/src/config.c
-index 7c03b27..238a655 100644
---- a/src/config.c
-+++ b/src/config.c
-@@ -218,8 +218,9 @@ static int ssh_config_parse_line(ssh_session session, const char *line,
- }
-
- opcode = ssh_config_get_opcode(keyword);
-- if (*parsing == 1 && opcode != SOC_HOST) {
-- if (seen[opcode] == 0) {
-+ if (*parsing == 1 && opcode != SOC_HOST &&
-+ opcode > SOC_UNSUPPORTED && opcode < SOC_END) {
-+ if (seen[opcode] == 1) {
- return 0;
- }
- seen[opcode] = 1;
diff --git a/gnu/packages/ssh.scm b/gnu/packages/ssh.scm
index 362d427a2..6ade3e55b 100644
--- a/gnu/packages/ssh.scm
+++ b/gnu/packages/ssh.scm
@@ -65,40 +65,35 @@
#:use-module (srfi srfi-1))
(define-public libssh
- ;; This commit from the 'v0-7' branch contains 7 memory-management-related
- ;; bug fixes that we'd rather have.
- (let ((commit "239d0f75b5f909174c2ef7fb08d23bcfa6b20ba0")
- (revision "0"))
- (package
- (name "libssh")
- (version (git-version "0.7.5" revision commit))
- (source (origin
- (method git-fetch)
- (uri (git-reference
- (url "https://git.libssh.org/projects/libssh.git")
- (commit commit)))
- (sha256
- (base32
- "01w72w1jsgs9ilj3n1gp6qkmdxr9n74i5h2nipi3x1vzm7bv8na1"))
- (patches (search-patches "libssh-hostname-parser-bug.patch"))
- (file-name (git-file-name name version))))
- (build-system cmake-build-system)
- (outputs '("out" "debug"))
- (arguments
- '(#:configure-flags '("-DWITH_GCRYPT=ON")
-
- ;; TODO: Add 'CMockery' and '-DWITH_TESTING=ON' for the test suite.
- #:tests? #f))
- (inputs `(("zlib" ,zlib)
- ("libgcrypt" ,libgcrypt)))
- (synopsis "SSH client library")
- (description
- "libssh is a C library implementing the SSHv2 and SSHv1 protocol for
-client and server implementations. With libssh, you can remotely execute
-programs, transfer files, and use a secure and transparent tunnel for your
-remote applications.")
- (home-page "https://www.libssh.org")
- (license license:lgpl2.1+))))
+ (package
+ (name "libssh")
+ (version "0.7.6")
+ (source (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "https://git.libssh.org/projects/libssh.git")
+ (commit (string-append "libssh-" version))))
+ (sha256
+ (base32
+ "0slwqa36mhyb6brdv2jvb9fxp7rvsv3ziv67kaxx615jxn52l5pa"))
+ (file-name (git-file-name name version))))
+ (build-system cmake-build-system)
+ (outputs '("out" "debug"))
+ (arguments
+ '(#:configure-flags '("-DWITH_GCRYPT=ON")
+
+ ;; TODO: Add 'CMockery' and '-DWITH_TESTING=ON' for the test suite.
+ #:tests? #f))
+ (inputs `(("zlib" ,zlib)
+ ("libgcrypt" ,libgcrypt)))
+ (synopsis "SSH client library")
+ (description
+ "libssh is a C library implementing the SSHv2 and SSHv1 protocol for client
+and server implementations. With libssh, you can remotely execute programs,
+transfer files, and use a secure and transparent tunnel for your remote
+applications.")
+ (home-page "https://www.libssh.org")
+ (license license:lgpl2.1+)))
(define-public libssh2
(package
--
2.19.1
L
L
Leo Famulari wrote on 18 Oct 2018 00:50
(address . 33067-done@debbugs.gnu.org)
20181017225030.GA30415@jasmine.lan
Pushed as a42648d858155930c078f7720c42a47765b2d0ee
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAlvHvLYACgkQJkb6MLrK
fwh3eg//SbQzCSCCj1VFnAQex844MhdCnmC/7eqKwzfZv8QODuN+nMrvoIPUo/2m
CMMY2V3avE/jrvcNEDRabiYNzpk3+CGiHn4zl5hLX/xhaJX2eOauy3USLPmhgfFS
ylKAYqqv3AzlwH264kZbfPCT61fzDqmFBlGTfpENe4mOFbbx25nkTKSFtwkOiW2F
V5MhS3n4T/4jFya0ksslLlo8lJ+HSyACiK8L6/zPTgii49hIVt6dpCq67LwJou6x
SK1Nt7nWxUWzWbErvKYsniJZ97eeWuBdBj8EFLM8/sZVAGUAvwnW+oFsRq83ANAu
tZsybM2JQw2j8lh1wiyVHqsYjUQtsJpYsNoMS2ZS8NZ6hmL+hQoyDirCaGeQi/Ek
/+SOcjcRM46JbaVOU+yau4A7PPgdnE1csIAfE3LloormwycM0zTSWyzsZCblMnmD
X/mRrcoAacJA/2GK4GIYXGZh8OZqw80zDJ5wsPQkBlz/Rjdusx/ygWK2htWiirJU
IhmJnk+S5vj1aKcPyEQJWL31+KkKV0dFObtBex3qqTIhcPmqexkD3Ig5zfzzyf5i
40oVaHQQgllGcQvYxxUQc3tDz0Htu1+PQs6rZaJlVZPeuDETwCtjJmLuf7WvXIVS
818nI3pZAUNA2hTJ67dG5xS5kNVjWUbZPq2IXC/GWoq3Y5cII3w=
=ktP/
-----END PGP SIGNATURE-----


Closed
L
L
Ludovic Courtès wrote on 18 Oct 2018 01:11
(name . Leo Famulari)(address . leo@famulari.name)(address . guix-patches@gnu.org)
87ftx49njj.fsf@gnu.org
Hi Leo,

Leo Famulari <leo@famulari.name> skribis:

Toggle quote (7 lines)
> This update should be tested with users of guile-ssh.
>
> Also, Ludo, the bug report of the patch removed here is no longer online
> (they have a new bug tracker at <https://bugs.libssh.org/>). The patch
> doesn't apply, but since I can't read the bug report, I don't know if
> the problem is fixed upstream, or if we should adapt our patch.

The patch changes just one ‘if’ condition. Could you check in 0.7.6 if
that condition matches what the patch changed?

I haven’t yet been able to test the change with Guile-SSH and Guix.

Thanks!

Ludo’.
L
L
Ludovic Courtès wrote on 19 Oct 2018 10:29
(name . Leo Famulari)(address . leo@famulari.name)(address . 33067@debbugs.gnu.org)
87pnw6ibkb.fsf@gnu.org
Hello!

Leo Famulari <leo@famulari.name> skribis:

Toggle quote (23 lines)
> Previously I reported the patch pushed and closed the bug. However, the
> push must have failed without me noticing. Now that I saw your message,
> I had more time to look at the patch and update it. Now pushed as
> eed00f93e8999712191e39c59c15e23461520f43
>
> On Thu, Oct 18, 2018 at 01:11:12AM +0200, Ludovic Courtès wrote:
>> The patch changes just one ‘if’ condition. Could you check in 0.7.6 if
>> that condition matches what the patch changed?
>
> The only upstream change was to fix the bug which would make it ignore
> valid configuration data when parsing the config file.
>
> Our patch also tightened the conditional that led to that point, so that
> the previously faulty check would not be passed some "dummy" constants.
>
> Not being able to read the original bug report, I can't tell if these
> extra changes were made in response to a bug that was actually
> experienced, or if we were just being cautious.
>
> Since nothing else changed upstream, it seems like the tightening can't
> hurt, at least the one regarding the SOC_END constant, which I think
> could still be used erroneously. But we should send it upstream.

Sounds good, thanks for checking!

Ludo’.
?