[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [PATCH] Handle non-critical SIG_SUBPACKET per RFC4880



	This is to replace my earlier SIG_SUBPACKET patch sent in 11/23/09.
This should sufficiently ignore signature subpackets that are not
flagged critical and thus 'recognizes' them but doesn't actually
implement them as DAK doesn't use them in accordance with RFC4880
section 5.2.3.1 as pointed out by Torsten earlier. As this doesn't add
SIG_SUBPACKET to known_keywords but adds the SIG_SUBPACKET to keywords
if it is flagged critical it will still generate an error as it does
currently.

	From /usr/share/doc/gnupg/DETAILS.gz under the --status-fd output
section you find that the output format process_gpgv_output() receives is:

    SIG_SUBPACKET <type> <flags> <len> <data>
        This indicates that a signature subpacket was seen.  The
        format is the same as the "spk" record above.

	And further information on "spk" records listed just before that
section states:

The "spk" signature subpacket records have the fields:

 2: Subpacket number as per RFC-2440 and later.
 3: Flags in hex.  Currently the only two bits assigned are 1, to
    indicate that the subpacket came from the hashed part of the
    signature, and 2, to indicate the subpacket was marked critical.
 4: Length of the subpacket.  Note that this is the length of the
    subpacket, and not the length of field 5 below.  Due to the need
    for %-encoding, the length of field 5 may be up to 3x this value.
 5: The subpacket data.  Printable ASCII is shown as ASCII, but other
    values are rendered as %XX where XX is the hex value for the byte.

	This flag value is received in args[1] and as stated currently only has
two values with '2' indicating the subpacket is marked critical.

	Regards,
	Jeremy

Jeremy T. Bouse wrote:
> Section 5.2.3.1 states that there can be 0 or more signature subpackets.
> The RFC states that any implementation SHOULD ignore any subpacket it
> doesn't recognize; however those marked as critical on Bit 7 should be
> treated as an error rather than ignored. It further states that an
> evaluator may 'recognize' but not implement a subpacket type. As DAK
> doesn't actually implement and only needs to recognize this patch only
> adds critical SIG_SUBPACKET keywords that will generate an error as
> SIG_SUBPACKET is not listed in known_keywords when ran through the
> check_signature() function.
> ---
>  daklib/utils.py |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/daklib/utils.py b/daklib/utils.py
> index 0896d57..fb6b8b0 100755
> --- a/daklib/utils.py
> +++ b/daklib/utils.py
> @@ -1205,6 +1205,8 @@ def process_gpgv_output(status):
>          if keywords.has_key(keyword) and keyword not in [ "NODATA", "SIGEXPIRED", "KEYEXPIRED" ]:
>              internal_error += "found duplicate status token ('%s').\n" % (keyword)
>              continue
> +        if keyword in [ "SIG_SUBPACKET" ] and args[1] != 2:
> +            continue
>          else:
>              keywords[keyword] = args
>  


Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: