From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) by sourceware.org (Postfix) with ESMTPS id 01FC93858CD1 for ; Mon, 1 Apr 2024 03:31:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 01FC93858CD1 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 01FC93858CD1 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::d32 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711942299; cv=none; b=IhM3V+uLevXFboPyXLZr+FzJapurxrRnbtkxGF/v5UU5hK2MLJgk+AiM98eCxlq3hgvd07uBLB3HuXYX6nNwbtG8zgjob1QP0iER+roj9AZPUOYVjAPhT8opIZ0yqKifXUQmzWXuAAMB0EGg9fU/rJeenSVJeLzE4MtVdgdsy7k= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711942299; c=relaxed/simple; bh=DrvwbAKzMoo/E+HtEQUoIptuxov/9A66EB3bPKJ+824=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=Fr1VDxDjQ2u+OpEwn3zGCDqIpt8Tbj18CHe+3Mi7UOGLEaY5gUe+2ejdAG5FzWS1LDxRm4fX2dKq/rSAgCUfCZJ3+SjuMWDgj9MnxjP40JpBwYPQ2bNaQpCOv5cqU0K+jNd3MqQk8NqVFjYAR0DF8E4H5CrrfMN17YHlXQ2yLRw= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-io1-xd32.google.com with SMTP id ca18e2360f4ac-7cc864215caso160529139f.3 for ; Sun, 31 Mar 2024 20:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711942296; x=1712547096; darn=sourceware.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=DrvwbAKzMoo/E+HtEQUoIptuxov/9A66EB3bPKJ+824=; b=j/DbD2p9d5BslUn4B5AujMZgd2IpFVRR3tIWDF695/eRBdxZIuf1X6zXcb67uINLan f74vEEkJhWhQzyF8KOsjpqHi+hIspxBUWNdiHyt39uitMs2e2c90f0nsnXadVW3f1Pov I8RlzbQ9c0tVJFAa1pb2RwmduSj7qv6kG6LQrCbVhz2NSo9ADJFSnv0S5/x8CUXOLWAR L0QWAyvRLiQuH4LufnFjOcEhyZnJyFA6OGnhP0c3IuF0uTL4A22Lj1FsUMtZ5AMuhIks Q/U+ZzoyoqQi8gAWac3uWKcXVeyYBcOobsXCIHh9ROh+oGh7dVr0ZlCc2lHaUcsAlf82 VO1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711942296; x=1712547096; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=DrvwbAKzMoo/E+HtEQUoIptuxov/9A66EB3bPKJ+824=; b=cAVlKENovz+TcZE30iB+Mv2ofENUapG6cvOPsbPYemC93j6b6DiZqkbcLLBrd3qK2V 7RCInipRWmoeLrdL+ByE+mErw9XtEpFhSwZthXdi93iBzGpn4Z0M1qJod9GsdMxGPSXW xvWKOcxRvleUzCZpGE/sQTBBQbCsQ0ORJqWiyozSdI37mBm+M9VVscDvC2Gn9qADdwCt X2AYOv78G4jECNRb4L8eLgS8HSoTpMCNNUKrn8BRM8Ko+ug3TwbBrNjByO2scS7JaMZn EjouO2H8chuO8AT2D5Trov6QN+bUempmFJkqFbNZKvkrtc7iBNNGliSr2ku1+jqkGHQJ tTCw== X-Gm-Message-State: AOJu0Yzu4iyuOmhPjV2iF3Cwa98+b/7QxzzUkRpI/ZlQNoRLhG2qiWD5 uiE6/lYAW3XJ+ggsbPtuRWMBvfK7MztPbfS2zxxUTyb+k5YigxEwsa98skR0Igb9laLxp/ystMB pPURjtCIbR+KkYzODGnpS/GmAVu72S7/bBS7k2w== X-Google-Smtp-Source: AGHT+IF8KETZBII/ZoqXqGBhO9fAhPPTgavcVuYdmxJvS/513AyFGvxMhoCtJDXs3f4RbDHk/A5Bx2sfp6yFFPZKN3E= X-Received: by 2002:a05:6e02:1a4c:b0:368:9ae2:dc87 with SMTP id u12-20020a056e021a4c00b003689ae2dc87mr10774127ilv.24.1711942295883; Sun, 31 Mar 2024 20:31:35 -0700 (PDT) MIME-Version: 1.0 From: Rui Ueyama Date: Mon, 1 Apr 2024 12:31:25 +0900 Message-ID: Subject: Remove dependency on libjansson To: Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi, The recent xz incident demonstrated that supply chain attacks are a real threat, and dependence on third-party libraries can have significant consequences. In the wake of the incident, I propose we remove the dependency on libjansson from GNU ld. First of all, why does GNU ld depend on libjansson which is a JSON parsing library? GNU ld gained the `--package-metadata` option in May 2022 to embed a JSON string into a .note section for package management for Fedora and other Linux distributions. At the same time, the dependency on libjansson, a library for parsing JSON-format strings, was introduced to validate an argument for that option. If an argument is not a valid JSON string, ld reports an error. If the library is unavailable, or if `--disable-jansson` was passed to the configure script, the library will not be linked and the error check will be disabled. By default, the library will be linked if it exists. I opposed adding an extra dependency to GNU ld just for string verification purposes because it didn't seem worth adding extra dependency to the linker. LLVM lld and the mold linker also support the option, but they do not verify if the argument is a valid JSON string -- they simply treat it as an opaque string. If libjansson is unavailable, even GNU ld doesn't verify arguments. Therefore, the verification is not trustworthy, and the reader must be prepared for a malformed JSON string when reading a .note section. Moreover, verifying a string is straightforward without the feature; you can simply `echo` the string to pipe it to `jq` for verification before passing it to GNU ld. I just checked /usr/bin/ld on Ubuntu 24.04, which is set to be released this month, and the dependency on libjansson was indeed present. How much risk does it pose? Probably not much, as long as the library is maintained properly. However, the stakes are high; if someone takes control of the library and introduces malicious code, they could execute a Ken Thompson-style supply chain attack. Since GNU ld is used to build essentially everything, the attacker could in theory gain the power to not just contaminate a specific program such as openssh, but every executable in an official Linux distribution image. I think the risk is not worth taking. I believe we just should remove the string verification code and the dependency on the library from GNU ld. Rui Ueyama