#!/bin/sh
# Regression tests pertaining to the armoring.
# Copyright 2006, 2007 Free Software Foundation, Inc.
# This file is free software; as a special exception the author gives
# unlimited permission to copy and/or distribute it, with or without
# modifications, as long as this notice is preserved.  This file is
# distributed in the hope that it will be useful, but WITHOUT ANY
# WARRANTY, to the extent permitted by law; without even the implied
# warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

. $srcdir/defs.inc || exit 3

armored_key_8192='-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: SKS 1.0.9

[encoded data, 11023 characters]
7OqcRycJhHu/qu5vl3TPDACg6xD1M0NiZWWdbV9/2u3VhxMf0uI=
=oXxa
-----END PGP PUBLIC KEY BLOCK-----
'

# Bug solved 2005-04-07:
# Try importing the attached key file.  As the key is exactly 8192
# bytes long, radix64_read is called twice - the first time to read
# the 8192 bytes, and then once again, to handle the pad '=' on the
# last four character radix64 block '0uI='.  gpg bails out with
#  gpg: [don't know]: invalid packet (ctb=2d)
# On a read for only the = sign, radix64_read returns -1 for EOF.
# This causes the iobuf code to pop the armor filter and thus the next
# byte read is the '-' from the END header line, causing an error.
i=armored_key_8192
info "checking: $i"
eval "(IFS=; echo \"\$$i\")" >x
$GPG --import x || error "the $i bug is back in town"



nopad_armored_msg='-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.11-svn5139 (GNU/Linux)

[encoded data, 33280 characters]
=3akT
-----END PGP MESSAGE-----

'

alpha_seckey='-----BEGIN PGP PRIVATE KEY BLOCK-----
Version: GnuPG v1.4.8 (GNU/Linux)

lQHhBDbjjp4RBAC2ZbFDX0wmJI8yLDYQdIiZeAuHLmfyHsqXaLGUMZtWiAvn/hNp
ctwahmzKm5oXinHUvUkLOQ0s8rOlu15nhw4azc30rTP1LsIkn5zORNnFdgYC6RKy
hOeim/63+/yGtdnTm49lVfaCqwsEmBCEkXaeWDGq+ie1b89J89T6n/JquwCgoQkj
VeVGG+B/SzJ6+yifdHWQVkcD/RXDyLXX4+WHGP2aet51XlKojWGwsZmc9LPPYhwU
/RcUO7ce1QQb0XFlUVFBhY0JQpM/ty/kNi+aGWFzigbQ+HAWZkUvA8+VIAVneN+p
+SHhGIyLTXKpAYTq46AwvllZ5Cpvf02Cp/+W1aVyA0qnBWMyeIxXmR9HOi6lxxn5
cjajA/9VZufOXWqCXkBvz4Oy3Q5FbjQQ0/+ty8rDn8OTaiPi41FyUnEi6LO+qyBS
09FjnZj++PkcRcXW99SNxmEJRY7MuNHt5wIvEH2jNEOJ9lszzZFBDbuwsjXHK35+
lPbGEy69xCP26iEafysKKbRXJhE1C+tk8SnK+Gm62sivmK/5av4CAwKcF1Qep+Pf
ssOqtJhr+klruUBf55onBJi4vkk0gK3m32p/05YB2bbMURGz8R4JxUZfUxjdDk73
LaNYRbQpQWxwaGEgVGVzdCAoZGVtbyBrZXkpIDxhbHBoYUBleGFtcGxlLm5ldD6I
VQQTEQIAFQUCNuOOngMLCgMDFQMCAxYCAQIXgAAKCRAtcnzHaGl3NDl4AJ4rouHB
+LpCkNi5C59jHEa1kbANzACgmddtrNSj1yPyTCwUwRghPUomECS0EEFsaWNlIChk
ZW1vIGtleSmIVQQTEQIAFQUCNuO2qwMLCgMDFQMCAxYCAQIXgAAKCRAtcnzHaGl3
NCeMAJ9MeUVrago5Jc6PdwdeN5OMwby37QCghW65cZTQlD1bBlIq/QM8bz9AN4G0
J0FsZmEgVGVzdCAoZGVtbyBrZXkpIDxhbGZhQGV4YW1wbGUubmV0PohVBBMRAgAV
BQI247hYAwsKAwMVAwIDFgIBAheAAAoJEC1yfMdoaXc0t8IAoJPwa6j+Vm5Vi3Nv
uo8JZri4PJ/DAJ9dqbmaJdB8FdJnHfGh1rXK3y/Jcp0BuAQ2448PEAQAnI3XH1f0
uyN9fZnw72zsHMw706g7EW29nD4UDQG4OzRZViSrUa5n39eI7QrfTO+1meVvs0y8
F/PvFst5jH68rPLnGSrXz4sTl1T4cop1FBkquvCAKwPLy0lE7jjtCyItOSwIOo8x
oTfY4JEEXmcqsbm+KHv9yYSF/YK4Cf7bIzcAAwcD/Rnl5jKxoucDA96pD2829TKs
LFQSau+Xiy8bvOSSDdlyABsOkNBSaeKO3eAQEKgDM7dzjVNTnAlpQ0EQ8Y9Z8pxO
WYEQYlaMrnRBC4DZ2IadzEhLlIOz5BVp/jfhrr8oVVBwKZXsrz9PZLz+e4Yn+siU
Uvlei9boD9L2ZgSOHakP/gIDApwXVB6n49+yw6e5k2VJBGTFDkQbxpgi4oslePpT
7Tc2qjAke4zO8JHkgKSokEgnMpMz412q9otFX/3qC5MpPG5P8f4r00Kfy9Am/thk
ri01WTIUqF8L/VZXJxLKVoRAabSXudG0eavfah14fN5/+Bw5i8vSHhc/xmQEKTya
2X8Nt1F5zMrE1LAGVVCL9i/DUygnJYOZzAd1Ct0RJ4kFj7lOBICF2IWWiEYEGBEC
AAYFAjbjjw8ACgkQLXJ8x2hpdzQgqQCgn81AaW8W/lyVwMh/UBeMuVMUb24An2uz
wg7Md81a5RI3F2FG8747t9gX
=VM1e
-----END PGP PRIVATE KEY BLOCK-----
'

# Bug 1179 solved 2010-05-12:
# It occurred for messages of a multiple of the iobuf block size where
# the last line had no pad character.  Due to premature poppng of thea
# rmor filter gpg swalled the CRC line and passed the '-----END...'
# line on to the decryption layer.

i=alpha_seckey
info "importing: $i"
eval "(IFS=; echo \"\$$i\")" >x
$GPG --import x || true

i=nopad_armored_msg
info "checking: $i"
eval "(IFS=; echo \"\$$i\")" >x
if $GPG -o - x > /dev/null ; then
   :
else
   error "bug#1179 is back in town"
fi

