Skip to content

Recognize signed form-resource roles when classifying post-signing changes #3442

Open

Description

@coderabbitai

Summary

Legitimate form filling can be reported as disallowed when existing indirect form resources are rewritten in place after signing. This limitation predates PR #3440 and remains outside that security fix.

An existing indirect /AcroForm /DR dictionary or an indirect /AP dictionary of an ordinary, non-signature widget can be classified as kind::OTHER. The permission rules reject that kind at DocMDP P=2. Appearance streams also need consideration because they use the stream dispatch branch.

This is a conservative false rejection: the reported limitation rejects legitimate form filling rather than permitting prohibited changes.

Required work

  • Define which form-resource and appearance changes form-fill permission allows to rewrite in place.
  • Identify relevant objects from their roles in the signed revision, including indirect /AcroForm /DR resources and ordinary widget /AP objects.
  • Apply the role classification consistently to dictionaries and streams.
  • Classify policy-permitted changes as kind::FORM_FILL.
  • Preserve stricter classification for signed signature fields, signed signature widgets, and page-content resources. Do not let a new reference or relabeling turn a prohibited change into form fill.

Affected areas

  • crates/sign/src/pdf.rs: classify_changes, existing_change_kind, stream dispatch, signed-resource role collection, and permission checks.
  • crates/sign/tests/pdf.rs: post-signing form-fill regression tests.

Acceptance criteria

  • Document the policy for permitted in-place form-resource and appearance rewrites.
  • Add P=2 regression coverage for existing indirect /DR and ordinary widget /AP objects, including appearance streams.
  • Confirm that supported legitimate form fills are permitted.
  • Add negative coverage to ensure shared page-content resources and signed signature appearances cannot bypass prohibited-change detection.

Context

Requested by @LetoCoder26.

Activity

  1. added 7 commits that reference this issue on Oct 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions