From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 30 10:33:01 2019 Received: (at submit) by debbugs.gnu.org; 30 Oct 2019 14:33:01 +0000 Received: from localhost ([127.0.0.1]:51156 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iPp1x-00075f-DC for submit@debbugs.gnu.org; Wed, 30 Oct 2019 10:33:01 -0400 Received: from lists.gnu.org ([209.51.188.17]:38566) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iPoxX-0004yf-4o for submit@debbugs.gnu.org; Wed, 30 Oct 2019 10:28:27 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59799) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iPoxV-0007YK-Gk for bug-coreutils@gnu.org; Wed, 30 Oct 2019 10:28:26 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.9 required=5.0 tests=BAYES_50,FREEMAIL_FROM, HTML_MESSAGE,HTTPS_HTTP_MISMATCH,URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iPoxU-00014N-7F for bug-coreutils@gnu.org; Wed, 30 Oct 2019 10:28:25 -0400 Received: from mail-wm1-x32a.google.com ([2a00:1450:4864:20::32a]:40148) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iPoxU-00012z-0B for bug-coreutils@gnu.org; Wed, 30 Oct 2019 10:28:24 -0400 Received: by mail-wm1-x32a.google.com with SMTP id w9so2408645wmm.5 for ; Wed, 30 Oct 2019 07:28:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=OipTU/Dw/WqP8tHI1jqlONpDX4lyS8x+7bM01OPIVn0=; b=e5WUT26m5fSFKdl463GpCG4TZMgB0Bvh1+0XWtzMqefLAUTmhM84Ba5/0uQa0Sl1p9 dChQUm6VOk+ynXNz/OMg9dFbBNov3mtmDDOJx29+MfLMgfAqvfwHhX+NxGBb61lTx79G 8MnD8FlxgGn6zYAeXqJzvEj1qDKYgeYR+/cSsVBHSSTntqQzVZ7qGOeuvFaHZUWWum6G UHMSVvZZX99jhQYPXv0h+TFtWS4a9pvWQL/FW3qDQmLn4BnWTGdjkmn4HPnorOIeQvVT +aedbyp4bby6960x/NJbgcXJ3XMuvIyjn33nVn7XH355fH/Ct5jiF2uDXLiWErTTTO+Q u5cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=OipTU/Dw/WqP8tHI1jqlONpDX4lyS8x+7bM01OPIVn0=; b=Rz2rw75NOurs0hl7CDCXDRm4DamRAeH/w1mlp/xlYhbVY5y3cnIwQuD8Cie4zKKj0c kOvcQAkqyQQcvOx4gfzR3ffeymluY8WawXTsqkpgBssaW0CrDtgT5XUdMmeDQhOjMB3u l0u/a9CCv2L7gDD64FkWPIx/LrOnn8vgbneucLVkBhoh77VMYOFDSuATUWgFvLg0xfO7 g59A8+GcnTG6GxEfD2esYr+hZgP5Xb50GNbAdd5zAj34q9kd6rwHXvSUUtWSNePvlRls HM1Yk2/hIyaRN2f98kJVzOGLLqfzp108UqE7twyHVBQAtW/xhak9y05zopK5uTFagX7R f25w== X-Gm-Message-State: APjAAAWgvPUQ1Dz5CxtxNpqXgMwyDTvzf1+dzMk2navHkfq29kb/ZR7J oTGwHLlYEqWrwWtSwaGq/B1LPWNEay5b7zV+z0iL5vo+ X-Google-Smtp-Source: APXvYqxJhWs4jGRpTjhUoHwiZgg2v3VnBE6oY442+Xm2zJaO5nraNSakij4yDy6uoq88AZ8K0FBhd8lGb4IkSAghT+0= X-Received: by 2002:a1c:f60d:: with SMTP id w13mr9967149wmc.150.1572445702180; Wed, 30 Oct 2019 07:28:22 -0700 (PDT) MIME-Version: 1.0 From: Steven Hilton Date: Wed, 30 Oct 2019 15:25:16 +0100 Message-ID: Subject: Base64 decode should ignore CRLF To: bug-coreutils@gnu.org Content-Type: multipart/alternative; boundary="00000000000081d24c0596218b31" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::32a X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Wed, 30 Oct 2019 10:32:59 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.2 (--) --00000000000081d24c0596218b31 Content-Type: text/plain; charset="UTF-8" I believe that the base64 implementation in coreutils should ignore carriage return and line feed line endings (CR, LF, CRLF). Currently, it only ignores LF line endings. The -i/--ignore-garbage flag is effective, but should not fail on common line endings. $ echo -ne "R05VIEJhc2U2NCBkZWNvZGUgc2hvdWxkIGlnbm9yZSBib3RoIENSIGFuZC9vciBMRg0K\r\nR05VIEJhc2U2NCBkZWNvZGUgc2hvdWxkIGlnbm9yZSBib3RoIENSIGFuZC9vciBMRg0K" | base64 -d Current Output: GNU Base64 decode should ignore both CR and/or LF base64: invalid input Expected Output: GNU Base64 decode should ignore both CR and/or LF GNU Base64 decode should ignore both CR and/or LF Per the Base64 RFC, section 3.3, Note that this means that any adjacent carriage return/line feed (CRLF) characters constitute "non-alphabet characters" and are ignored. https://tools.ietf.org/html/rfc4648#section-3.3 My interpretation of this section is that the base64 decoding should either fail on any non-Alphabet character, or should ignore any line ending combination. --00000000000081d24c0596218b31 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I believe=C2=A0that the base64 implementation in = coreutils should ignore carriage return and line feed line endings (CR, LF,= CRLF). Currently, it only ignores LF line endings.
The -i/--ignore-garbage flag is effective, but = should not fail on common line endings.=C2=A0

$ echo -ne "= ;R05VIEJhc2U2NCBkZWNvZGUgc2hvdWxkIGlnbm9yZSBib3RoIENSIGFuZC9vciBMRg0K\r\nR0= 5VIEJhc2U2NCBkZWNvZGUgc2hvdWxkIGlnbm9yZSBib3RoIENSIGFuZC9vciBMRg0K" | = base64 -d
Current Output= :
GNU Base64 decode should ignore both C= R and/or LF
base64: invalid input

Expected Output:
GNU Ba= se64 decode should ignore both CR and/or LF
GNU Base64 decode should ign= ore both CR and/or LF

Per the Base64 RFC= , section 3.3,=C2=A0
Note that this =
means that any adjacent carriage return/line feed (CRLF) characters constit=
ute "non-alphabet characters" and are ignored.

My interpretation of this sectio= n is that the base64 decoding should either fail on any non-Alphabet charac= ter, or should ignore any line ending combination.
--00000000000081d24c0596218b31--