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

Provide a method for specifying binary data in STRING and BLOCK default values #261

Closed
ryanatball opened this Issue Mar 4, 2016 · 4 comments

Comments

Projects
None yet
3 participants
@ryanatball
Member

ryanatball commented Mar 4, 2016

No description provided.

@donaldatball

This comment has been minimized.

Show comment
Hide comment
@donaldatball

donaldatball Jun 7, 2017

Collaborator

@ryanatball @jasonatball

Can I get a vote from you guys? I've been digging into this, and I think there are essentially 3 ways it could be implemented:

  1. Add an optional parameter to the item/parameter keyword (only used for STRING/BLOCK) that indicates that the default value is to be read as hex, octal, binary. This is a very safe approach, but it adds yet another complexity to the cmd/tlm defs.
  2. Rely on some sort of indicator at the beginning of the default value string to indicate that the rest of the string is to be read as hex, octal binary (i.e. if the string starts with "0x", read the rest of it as hex). This would eliminate the need for a new cmd/tlm def param, but there is the potential for accidental side-effects.
  3. If we pass the default value through an eval statement, we can make it could naturally handle the normal notation for hex/octal (i.e. "\xff\xff\xff\xff"). Of course, that also allows for arbitrary execution of code too--pretty unsafe. On the other hand, maybe we don't care too much about security at this point, since bad cmd/tlm definitions can wreck the system in a lot of ways?

Do you guys have a preference? Or do you see another way I'm missing?

Collaborator

donaldatball commented Jun 7, 2017

@ryanatball @jasonatball

Can I get a vote from you guys? I've been digging into this, and I think there are essentially 3 ways it could be implemented:

  1. Add an optional parameter to the item/parameter keyword (only used for STRING/BLOCK) that indicates that the default value is to be read as hex, octal, binary. This is a very safe approach, but it adds yet another complexity to the cmd/tlm defs.
  2. Rely on some sort of indicator at the beginning of the default value string to indicate that the rest of the string is to be read as hex, octal binary (i.e. if the string starts with "0x", read the rest of it as hex). This would eliminate the need for a new cmd/tlm def param, but there is the potential for accidental side-effects.
  3. If we pass the default value through an eval statement, we can make it could naturally handle the normal notation for hex/octal (i.e. "\xff\xff\xff\xff"). Of course, that also allows for arbitrary execution of code too--pretty unsafe. On the other hand, maybe we don't care too much about security at this point, since bad cmd/tlm definitions can wreck the system in a lot of ways?

Do you guys have a preference? Or do you see another way I'm missing?

@jasonatball

This comment has been minimized.

Show comment
Hide comment
@jasonatball

jasonatball Jun 8, 2017

Collaborator

The only items with default values are parameters. If a parameter is a BLOCK and the default is "0xABCD" then we translate that into binary. I think that makes the most sense to people. If the parameter is a STRING and the default is "0xABCD" we leave it as a string. Strings and strings and blocks are binary. So I vote 2 but only support BLOCK.

Collaborator

jasonatball commented Jun 8, 2017

The only items with default values are parameters. If a parameter is a BLOCK and the default is "0xABCD" then we translate that into binary. I think that makes the most sense to people. If the parameter is a STRING and the default is "0xABCD" we leave it as a string. Strings and strings and blocks are binary. So I vote 2 but only support BLOCK.

@ryanatball ryanatball removed their assignment Jun 8, 2017

@ryanatball

This comment has been minimized.

Show comment
Hide comment
@ryanatball

ryanatball Jun 8, 2017

Member

There are cases with STRING where you still need to be able specify hex. (CR/NL/TAB) for example. Using, 0x as a detection prefix is fine. It would be nice if the string was quoted "0x00", that it would not convert to binary, but unquoted 0x00 would.

Ryan

Member

ryanatball commented Jun 8, 2017

There are cases with STRING where you still need to be able specify hex. (CR/NL/TAB) for example. Using, 0x as a detection prefix is fine. It would be nice if the string was quoted "0x00", that it would not convert to binary, but unquoted 0x00 would.

Ryan

donaldatball added a commit that referenced this issue Jun 12, 2017

donaldatball added a commit that referenced this issue Jun 19, 2017

re #261 For string params, unquoted strings that start with 0x are tr…
…eated as binary, quotes strings that start with 0x are preserved. Also do some refactoring to remove one of two similar functions that were converting packet information into a command string.

donaldatball added a commit that referenced this issue Jun 21, 2017

Merge pull request #480 from BallAerospace/bin_defaults
re #261 Add mechanism to define a binary string for STRING/BLOCK defa…
@donaldatball

This comment has been minimized.

Show comment
Hide comment
@donaldatball

donaldatball Jun 21, 2017

Collaborator

Closed with f06acc8

Collaborator

donaldatball commented Jun 21, 2017

Closed with f06acc8

@ryanatball ryanatball modified the milestone: v4.0.0 Aug 4, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment