Skip to content

Add input validation to simple metadata api #1140

Description

@lukpueh

Coordinate with validation guidelines #1130

Description of issue or feature request:
Some suggestions:

  • Avoid schema, see Revise schema and formats facility secure-systems-lab/securesystemslib#183 (just don't use it)
  • Make use of type hints for simple type validation
  • Perform additional non-metadata parameter validation at user boundary
  • Provide methods to validate JSON representation at user boundary, i.e. fail on bad json metadata in from_json_file/to_json_file method, but with option to
    disable check as there might be a justified reason to read or write WIP
    metadata to json.
  • Be lenient on bad/invalid metadata objects in memory, they might be
    work in progress. E.g. it might be convenient to create empty metadata
    and assign attributes later on.
  • Consider using in-toto style ValidationMixin (see the mixin and it's usage for details).

Current behavior:
No input validation

Expected behavior:
Add input validation

Activity

  1. added this to the Foundations milestone on Sep 10, 2020
  2. added a commit that references this issue on Sep 10, 2020
  3. added a commit that references this issue on Sep 17, 2020
  4. joshuagl commented on Dec 1, 2020

    @joshuagl
    Member
    • Consider using in-toto style ValidationMixin (see the mixin and it's usage for details).

    This looks like a nice pattern. Each class defines appropriate validation methods, which are called by the Mixin's validate() method at the end of the object's construction.

    Any thoughts on whether a decorator might be a more idiomatic approach than a Mixin? We could wrap classes with a decorator which performs validation after init, before returning the instantiated object.

  5. trishankatdatadog commented on Dec 1, 2020

    @trishankatdatadog
    Contributor

    Another idea is to copy validation techniques Django/Rails use...

  6. joshuagl commented on Dec 1, 2020

    @joshuagl
    Member

    Nice idea. I took a brief look those look to be quite complicated and not equivalent to what we're trying to do here Django Model validation.

  7. lukpueh commented on Dec 3, 2020

    @lukpueh
    MemberAuthor

    Good thinking, @trishankatdatadog. But I agree with @joshuagl that we might not need something as powerful (Django's validation is really tailored towards web forms and/or ORM, similar is true for WTForms, which I also briefly considered).

    I think the in-toto approach is not so bad. It's also featured in this quite interesting blog post about different instance attribute validation techniques, at least the "individual validation functions" aspect (not the neat self-inspecting mixin part).

    The blog also mentions two promising validation libraries, marshmallow and pydantic, which both are actually de/serialization libraries with validation features. Given that we want to minimize dependencies (see #1165), I'm leaning towards rolling our own validation, which doesn't even have to be that generic (see secure-systems-lab/securesystemslib#183).

    The blog also mentions a Python built-in feature, i.e. Descriptors, that as per official docs seems well-suited for attribute validators. Although it looks interesting, I'm unsure if it gives us the flexibility of e.g. initializing empty objects, assigning values, and only then calling validate, which might be a desirable usage pattern (see snippet 2 in #1223 (comment)). Same reservation goes for decorators, which the blog also mentions in conjunction with descriptors. But I can check if there is a solution that involves decorators and/or descriptors that allows for said flexibility.

    What I like about both the decorator and descriptor approach(es) is that they make the constraints on the attributes more visible (in the head of the class definition) than vanilla validation methods.

  8. joshuagl commented on Dec 3, 2020

    @joshuagl
    Member

    The blog also mentions a Python built-in feature, i.e. Descriptors, that as per official docs seems well-suited for attribute validators. Although it looks interesting, I'm unsure if it gives us the flexibility of e.g. initializing empty objects, assigning values, and only then calling validate, which might be a desirable usage pattern (see snippet 2 in #1223 (comment)).

    Descriptors look nice, and I'm all for avoid additional dependencies. I believe the pattern of: initialising empty objects, assigning values, and then validating should still work – so long as our empty objects have sane defaults. Based on 5mins experimentation in the Python interpreter:

    >>> class MetadataType:
    ...     def __get__(self, obj, objtype=None):
    ...         return self.value
    ...     def __set__(self, obj, value):
    ...         if value not in ['root', 'timestamp', 'snapshot', 'targets']:
    ...             raise ValueError('Invalid _type field')
    ...         self.value = value
    ...
    >>> class Metadata:
    ...     type = MetadataType()
    ...     def __init__(self, type):
    ...         self.type = type
    ...
    >>> class Targets(Metadata):
    ...     def __init__(self):
    ...       super().__init__('targets')
    ...
    >>> md = Metadata('badger')
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "<stdin>", line 4, in __init__
      File "<stdin>", line 6, in __set__
    ValueError: Invalid _type field
    >>> md = Metadata('root')
    >>> md.type = 'badger'
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "<stdin>", line 6, in __set__
    ValueError: Invalid _type field
    >>> t = Targets()
    >>> t.type
    'targets'
    
  9. joshuagl commented on Dec 7, 2020

    @joshuagl
    Member

    The __slots__ mechanism, described in the Descriptor HowTo, could be something worth including in our new classes also. hat-tip @sechkova

  10. lukpueh commented on Dec 7, 2020

    @lukpueh
    MemberAuthor

    I wonder if sane defaults will always be possible, e.g. when thinking of the newly added MetadataInfo or TargetInfo in #1223.

    But maybe the usage pattern that requires initialization of empty objects is suboptimal. I must say that it would be quite nice to always have certainty about the validity of tuf objects.

  11. joshuagl commented on Jan 25, 2021

    @joshuagl
    Member

    In 7cfd100#r541018751 we discussed whether JsonDict is the right name for our generic Dict[str, Any] type, and agreed to handle that type's name with this issue instead.

  12. MVrachev commented on Apr 26, 2021

    @MVrachev
    Collaborator

    In a discussion with @jku, we noticed that our tests for the metadata classes don't test instantiating metadata objects without their required fields.
    We should add tests for that.

  13. MVrachev commented on Nov 17, 2021

    @MVrachev
    Collaborator
  14. MVrachev commented on Nov 17, 2021

    @MVrachev
    Collaborator

    @lukpueh and/or @joshuagl do you agree with me?

  15. joshuagl commented on Nov 18, 2021

    @joshuagl
    Member

    Agreed, thanks Martin. Closing because we have implemented validation on a case-by-case basis.

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

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions