Bug#884922: Support cleartext signed InRelease files with CRLF line endings
Package: apt
Version: 0.8.15.2
Severity: important
Tags: patch
Commit 89c4c588b275 ("fix from David Kalnischkies for the InRelease gpg
verification code (LP: #784473)") amended verification of cleartext
signatures by a check whether the file to be verified actually starts
with "-----BEGIN PGP SIGNATURE-----\n".
However cleartext signed InRelease files have been found in the wild
which use \r\n as line ending for this armor header line, presumably
generated by a Windows PGP client. Such files are incorrectly deemed
unsigned and result in the following (misleading) error:
Clearsigned file isn't valid, got 'NOSPLIT' (does the network require authentication?)
RFC 4880 specifies:
That is to say, there is always a line ending preceding the
starting five dashes, and following the ending five dashes. The
header lines, therefore, MUST start at the beginning of a line, and
MUST NOT have text other than whitespace following them on the same
line.
RFC 4880 does not seem to specify whether LF or CRLF is used as line
ending for armor headers, but CR is generally considered whitespace
(e.g. "man perlrecharclass"), hence using CRLF is legal even under
the assumption that LF must be used.
SplitClearSignedFile() is sidestepping this issue by not including \n
in match strings. Do the same in StartsWithGPGClearTextSignature().
>From 6b1f71bebfd4abd8f450dfad1d4362f079672555 Mon Sep 17 00:00:00 2001
From: Lukas Wunner <lukas@wunner.de>
Date: Thu, 21 Dec 2017 12:57:39 +0100
Subject: [PATCH] Relax recognition of cleartext signatures
Commit 89c4c588b275 ("fix from David Kalnischkies for the InRelease gpg
verification code (LP: #784473)") amended verification of cleartext
signatures by a check whether the file to be verified actually starts
with "-----BEGIN PGP SIGNATURE-----\n".
However cleartext signed InRelease files have been found in the wild
which use \r\n as line ending for this armor header line, presumably
generated by a Windows PGP client. Such files are incorrectly deemed
unsigned and result in the following (misleading) error:
Clearsigned file isn't valid, got 'NOSPLIT' (does the network require authentication?)
RFC 4880 specifies:
That is to say, there is always a line ending preceding the
starting five dashes, and following the ending five dashes. The
header lines, therefore, MUST start at the beginning of a line, and
MUST NOT have text other than whitespace following them on the same
line.
RFC 4880 does not seem to specify whether LF or CRLF is used as line
ending for armor headers, but CR is generally considered whitespace
(e.g. "man perlrecharclass"), hence using CRLF is legal even under
the assumption that LF must be used.
SplitClearSignedFile() is sidestepping this issue by not including \n
in match strings. Do the same in StartsWithGPGClearTextSignature().
Signed-off-by: Lukas Wunner <lukas@wunner.de>
---
apt-pkg/contrib/fileutl.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/apt-pkg/contrib/fileutl.cc b/apt-pkg/contrib/fileutl.cc
index d3764d0..f2328c3 100644
--- a/apt-pkg/contrib/fileutl.cc
+++ b/apt-pkg/contrib/fileutl.cc
@@ -928,7 +928,7 @@ bool ExecWait(pid_t Pid,const char *Name,bool Reap)
// StartsWithGPGClearTextSignature - Check if a file is Pgp/GPG clearsigned /*{{{*/
bool StartsWithGPGClearTextSignature(string const &FileName)
{
- static const char* SIGMSG = "-----BEGIN PGP SIGNED MESSAGE-----\n";
+ static const char* SIGMSG = "-----BEGIN PGP SIGNED MESSAGE-----";
char buffer[strlen(SIGMSG)+1];
FILE* gpg = fopen(FileName.c_str(), "r");
if (gpg == NULL)
--
2.15.1
Reply to: