write_header2 in build-packet.c

[NIIBE Yutaka]

Hello,

I write some information to this list for the issue 2374.

     https://bugs.gnupg.org/gnupg/issue2374


I committed this change.

     commit db1ecc8212defdd183abbb6b1407fcc8d2dc9552
     Author: NIIBE Yutaka <gniibe at fsij.org>
     Date:   Wed Jun 1 20:59:09 2016 +0900

         g10: Allow User ID length >= 256.

         * build-packet.c (do_user_id): Call write_header2 with HDRLEN 
not set.

Once, I thought this should be backported to 1.4 and 2.0.  Examining
code in detail, I concluded it's not needed and not worth to apply
this to 1.4 and 2.0.

Actually, we had similar change in master for do_key as well.

     commit 02cf1357dd5ee34a57371f55b9d312b8b9e3a7e8
     Author: Justus Winter <justus at g10code.com>
     Date:   Thu Apr 7 13:55:42 2016 +0200

         g10: Fix exporting secret keys of certain sizes.

         * g10/build-packet.c (do_key): Do not use the header length 
specified
         by the public key packet from the keyring, but let 'write_header2'
         compute the required length.
         --
         Specifically exporting RSA keys of length 1024 failed, as the 
encoded
         public key packet requires 141 bytes a length that fits into 
one byte,
         but the secret key is significantly larger, making the export fail.

         GnuPG-bug-id: 2307
         Signed-off-by: Justus Winter <justus at g10code.com>


Those two changes are needed for master but not for 1.4 and 2.0.
That's because we have this in master.

     commit 960f5e26f2cda3ac6e6b30548fa808a690c39ffc
     Author: Neal H. Walfield <neal at g10code.com>
     Date:   Thu Feb 25 21:20:32 2016 +0100

         gpg: More carefully encode a packet's length.

         * g10/build-packet.c (write_header2): Make sure the length bits are
         cleared.  Fail if HDRLEN is set and the specified length can't be
         encoded in the available space.

         --
         Signed-off-by: Neal H. Walfield <neal at g10code.com>

I think that the intention of this modification is good.  At first, I
failed to recognize the change of the semantics introduced by this
modification.

In 1.4 and 2.0, HDRLEN is used as just a hint for the length of
packet.  For example, when HDRLEN=2 and LENGTH=294, CTB will be |= 2,
and then, the packet with 5-byte header will be built with no failure.
It can be represented with 3-byte header actually, but it still works.

Modification by 960f5e2 changes the HDRLEN as a packet length
specification, thus, we needed to change the callers side by 02cf135
and db1ecc8.

Now, all calls of write_header2 are with HDRLEN=0, so, we could clean
up things more.
--