From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.4 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 0D0561F4B4 for ; Thu, 10 Dec 2020 20:21:51 +0000 (UTC) Received: by mail-qv1-xf36.google.com with SMTP id l14so3088165qvh.2 for ; Thu, 10 Dec 2020 12:21:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=google; h=date:from:to:subject:message-id:mail-followup-to:mime-version :content-disposition:content-transfer-encoding; bh=ynzr5udKuUF31j+dByByTvHQ8e7NLUVEWg56TyNhar8=; b=Ln9YOacUjlbgli0a3pobgqu/3Ke04gXr2i5+IR4vIz/Vrv0vCQyGi0oj7Ukn3YWk8v 9p9v4zzrACMGxX0q58ty/tItG8QF54Ui0SDySGdVXZStzOUFJlkoqN5gbO9T3XxbSbF5 iWEiF4OCoGTMvjyTCx6x6moVRdTZTJjhSaOdY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :mime-version:content-disposition:content-transfer-encoding; bh=ynzr5udKuUF31j+dByByTvHQ8e7NLUVEWg56TyNhar8=; b=NmWyqES2hhFV/WMUShTRT47M6mVW5PZ7rAK8RTnxQkXzhb2Fp5MC8LM6aD3MT/hqOi BlksDE6CIW0tkSyWumZqHm/kMF7s+fushVP+cB37x6AxeJ45juTma/3FTLHJL9vhDSe8 wIezWZUfsd32vopc3kjUim0nCnQfdGXYgcq8ujms2GLcAOUK4T2HE2LzasKI7rpgtr4D TwPceTo83DWpA6iAHBplEozF44wHehRpZ2F4D4chhiL3o8rtVL5penxgV/U5ezlIJJ/1 yEnULdXvzwti2uEi9DV8dFduA5AQNuhjjyTUmxEdMMs+afGHO9fS37kI199n4gM1xuB9 ZGPA== X-Gm-Message-State: AOAM5332kWHHk20gbsxijXFydbRfbQFbmV2HnVBPioaU2NA1wXbbeC9D Xo2XmrXcdp+XpyEqp6ZsCE/BYjk9X8uMyxcK X-Google-Smtp-Source: ABdhPJyxbjEAK+3n5dflEYoPvbZqck+sXcffE2meWZTR57g6PYNESLsMaPEB9iRtVtGxbfPP/VQq3A== X-Received: by 2002:a0c:f54c:: with SMTP id p12mr6115195qvm.35.1607631708341; Thu, 10 Dec 2020 12:21:48 -0800 (PST) Received: from chatter.i7.local ([89.36.78.230]) by smtp.gmail.com with ESMTPSA id n2sm4638464qkf.37.2020.12.10.12.21.46 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Dec 2020 12:21:47 -0800 (PST) Date: Thu, 10 Dec 2020 15:21:45 -0500 From: Konstantin Ryabitsev To: meta@public-inbox.org Subject: Extra newline when retrieving messages Message-ID: <20201210202145.7agtcmrtl5jec42d@chatter.i7.local> Mail-Followup-To: meta@public-inbox.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit List-Id: Hello: While investigating why some of the messages retrieved via lore.kernel.org were failing DKIM checks, I realized that public-inbox-httpd appends an extra newline to message bodies. This newline isn't present in git backends, just in messages retrieved via (at least) public-inbox-httpd. E.g.: $ git clone --mirror https://lore.kernel.org/linux-modules/git/0.git $ cd 0.git $ git show 8c61c2a9ec6c4737d2da7258a0ff565d87d83d0b:m > /tmp/1 $ curl -s https://lore.kernel.org/linux-modules/20201129164737.135866-1-yauheni.kaliuta@redhat.com/raw > /tmp/2 $ diff -u /tmp/1 /tmp/2 --- /tmp/1 2020-12-10 15:06:15.815341700 -0500 +++ /tmp/2 2020-12-10 15:06:20.647345538 -0500 @@ -1,3 +1,4 @@ +From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org @@ -56,6 +57,9 @@ X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Precedence: bulk List-ID: +Archived-At: +List-Archive: +List-Post: The function allocates array but on building it if get_string() fails it returns the error leaving the array allocated. The caller @@ -83,3 +87,4 @@ -- 2.29.2 + ^^^ This extra newline seems to be present whether a message is retrieved via /raw or via /t.mbox.gz. It's benign in almost all cases except when the message is signed using DKIM's "simple" mode, in which case it causes DKIM signature to no longer verify (as "simple" doesn't do any whitespace normalization before hashing body contents). This appears to be present in the public-inbox version running on https://public-inbox.org as well. Best regards, -K