Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better objects validation #6

Open
Kagami opened this issue Jan 29, 2015 · 3 comments
Open

Better objects validation #6

Kagami opened this issue Jan 29, 2015 · 3 comments
Assignees

Comments

@Kagami
Copy link
Member

Kagami commented Jan 29, 2015

Decoded objects should be validated as much as possible. Existing validation in PyBitmessage may help. Examples:

  • Messages must be decrypted using identity with the same ripe as in the destination_ripe field [↱]
  • Broadcasts must be decrypted using identity with the same ripe as the one constructed from the keys fields [↱]
  • Better checks for version ranges, streams; also sender's version should justify used object's version (msg, broadcast) [↱]
@Kagami Kagami self-assigned this Jan 29, 2015
@Kagami
Copy link
Member Author

Kagami commented Feb 17, 2015

We also may want to provide options to skip some kind of validation (e.g. strict version ranges).

@brandonrobertz
Copy link

If all we need to do is check a javascript object, there's json schema validation. I think that could cover it in most cases. I could do a PR for this if you give me an idea of where you think validation should be performed. (Assuming you're down with the schema route.)

@Kagami
Copy link
Member Author

Kagami commented Feb 18, 2015

I think json schema would be overkill for this task. Currently assert-style validation used throughout the library and works pretty well.

About validation: there are several places in the library where it can be improved:

  • We check whether the destination_ripe field equals to the ripe of the address used to decrypt the msg but we don't calculate the ripe from the keys in the message and don't compare it as well
  • The same for broadcast: we need to calculate ripe from the keys and check it with subscription ripe used to decrypt it (PyBitmessage does this check as stated in first message)
  • Sender's version of broadcast should justify used broadcast version; though this checking is already implemented, there might be some more; e.g. we might check whether the version address used to decrypt the pubkey/msg/broadcast justify the object's version
  • Plenty of other tricky cases that I can't think up right now

Thanks for your interest!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants