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

Add apidsl file for toxencryptsave. #310

Merged
merged 1 commit into from
Dec 13, 2016
Merged

Conversation

iphydf
Copy link
Member

@iphydf iphydf commented Dec 10, 2016

This change is Reviewable

@iphydf iphydf added this to the v0.2.0 milestone Dec 10, 2016
@GrayHatter GrayHatter self-assigned this Dec 11, 2016
@GrayHatter
Copy link

GrayHatter commented Dec 11, 2016

:lgtm:

@GrayHatter
Copy link

Reviewed 1 of 1 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved, some commit checks failed.


Comments from Reviewable

/**
* Some input data, or maybe the output pointer, was null.
* One of the arguments to the function was NULL when it was not expected.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When is NULL expected? Is it expected at all? Isn't this comment misleading?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sometimes NULL is accepted. is_data_encrypted just returns false, because NULL is not encrypted. This comment is generated by apidsl. Feel free to file a bug or make a PR with different wording there: https://github.com/TokTok/apidsl/issues.

@@ -190,59 +222,66 @@ typedef struct {
*
* returns true on success
*/
bool tox_derive_key_from_pass(const uint8_t *passphrase, size_t pplength, TOX_PASS_KEY *out_key,
TOX_ERR_KEY_DERIVATION *error);
bool tox_pass_key_derive_from_pass(struct Tox_Pass_Key *_key, const uint8_t *passphrase, size_t pplength,
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tox_pass_key_derive_from_pass()

Redundant department of redundant redundancy is calling. This function doesn't make much sense as far as the name goes.

* The salt must be TOX_PASS_SALT_LENGTH bytes in length.
*/
bool tox_derive_key_with_salt(const uint8_t *passphrase, size_t pplength, const uint8_t *salt, TOX_PASS_KEY *out_key,
TOX_ERR_KEY_DERIVATION *error);
bool tox_pass_key_derive_with_salt(struct Tox_Pass_Key *_key, const uint8_t *passphrase, size_t pplength,
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

*passphrase

This is plain wrong.


void tox_pass_key_free(struct Tox_Pass_Key *_key);

void tox_pass_key_get_key(const struct Tox_Pass_Key *_key, uint8_t *key);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No errors are possible? Should this actually read TOX_PASS_KEY_LENGTH bytes from given place in memory?
Why there are no docs on how to use it?
If it's something that shouldn't be used, why there's an API for it?

Same goes for other functions.

@iphydf iphydf changed the title Add apidsl file for toxencryptsave. [WIP] Add apidsl file for toxencryptsave. Dec 13, 2016
@iphydf iphydf force-pushed the toxes-api branch 3 times, most recently from 2729b4d to cad3eea Compare December 13, 2016 03:03
@iphydf iphydf changed the title [WIP] Add apidsl file for toxencryptsave. Add apidsl file for toxencryptsave. Dec 13, 2016
@iphydf iphydf modified the milestones: v0.1.0, v0.2.0 Dec 13, 2016
@iphydf
Copy link
Member Author

iphydf commented Dec 13, 2016

Added to v0.1.0. I'll push it to v0.2.0 if we can't get it reviewed on time.

@iphydf iphydf force-pushed the toxes-api branch 3 times, most recently from 8c8d655 to 6c1a5ab Compare December 13, 2016 03:34
@zetok
Copy link

zetok commented Dec 13, 2016

Review status: 0 of 6 files reviewed at latest revision, 1 unresolved discussion.


toxencryptsave/toxencryptsave.h, line 205 at r2 (raw file):

 */
bool tox_pass_encrypt(const uint8_t *plain, size_t plain_len, const uint8_t *passphrase, size_t passphrase_len,
                      uint8_t *cipher, TOX_ERR_ENCRYPTION *error);

cipher as a name for output data is confusing, perhaps it should be renamed to e.g. ciphertext?
While at renaming, plain isn't that good either. Not sure if it could be renamed, given that plaintext isn't much more friendly (perhaps a bit).

Same goes for naming in other functions.


Comments from Reviewable

@iphydf
Copy link
Member Author

iphydf commented Dec 13, 2016

Review status: 0 of 6 files reviewed at latest revision, 1 unresolved discussion.


toxencryptsave/toxencryptsave.h, line 205 at r2 (raw file):

Previously, zetok wrote…

cipher as a name for output data is confusing, perhaps it should be renamed to e.g. ciphertext?
While at renaming, plain isn't that good either. Not sure if it could be renamed, given that plaintext isn't much more friendly (perhaps a bit).

Same goes for naming in other functions.

Done.


Comments from Reviewable

@robinlinden
Copy link
Member

:lgtm_strong:


Reviewed 2 of 6 files at r2, 4 of 4 files at r3.
Review status: all files reviewed at latest revision, 2 unresolved discussions.


auto_tests/encryptsave_test.c, line 107 at r3 (raw file):

    Tox_Pass_Key *key = tox_pass_key_new();
    ck_assert_msg(key != NULL, "pass key allocation failure");
    memcpy((uint8_t *)key, test_salt, 32);

key->salt and key->key may be clearer. If you disagree, then maybe at least use TOX_PASS_SALT_LENGTH instead of 32 when comparing and using offsets.


Comments from Reviewable

This breaks the toxencryptsave API. It hides the Tox_Pass_Key struct
definition.
@robinlinden
Copy link
Member

Reviewed 1 of 1 files at r4.
Review status: all files reviewed at latest revision, 1 unresolved discussion.


Comments from Reviewable

@iphydf
Copy link
Member Author

iphydf commented Dec 13, 2016

Review status: all files reviewed at latest revision, 2 unresolved discussions.


auto_tests/encryptsave_test.c, line 107 at r3 (raw file):

Previously, robinlinden (Robin Lindén) wrote…

key->salt and key->key may be clearer. If you disagree, then maybe at least use TOX_PASS_SALT_LENGTH instead of 32 when comparing and using offsets.

Done.


Comments from Reviewable

@zetok
Copy link

zetok commented Dec 13, 2016

Public API looks ok. :lgtm_strong:


Review status: all files reviewed at latest revision, all discussions resolved.


Comments from Reviewable

zetok added a commit to zetok/tox that referenced this pull request Dec 13, 2016
Equivalent to the change in TokTok/c-toxcore#310 where pass-key
internals are no longer exposed publicly, since there is no need to
expose them.
@iphydf
Copy link
Member Author

iphydf commented Dec 13, 2016

@nurupo we can make modifications or undo this change if you have reasons for that later. The 0.1.0 release is still gated on your LGTM. I will merge the toxencryptsave API soon.

@nurupo
Copy link
Member

nurupo commented Dec 13, 2016

Ok. I will have some reviewing time in 6 hours.

@iphydf iphydf merged commit 4cf6999 into TokTok:master Dec 13, 2016
@nurupo
Copy link
Member

nurupo commented Dec 14, 2016

Reviewed 1 of 6 files at r2, 3 of 4 files at r3, 1 of 1 files at r4.
Review status: all files reviewed at latest revision, 2 unresolved discussions, all commit checks successful.


toxencryptsave/toxencryptsave.h, line 51 at r4 (raw file):

<unresolved>


toxencryptsave/toxencryptsave.h, line 263 at r4 (raw file):

 */
void tox_pass_key_free(struct Tox_Pass_Key *_key);

Why _key?


Comments from Reviewable

@nurupo nurupo mentioned this pull request Dec 14, 2016
@GrayHatter
Copy link

Reviewed 2 of 6 files at r2, 3 of 4 files at r3, 1 of 1 files at r4.
Review status: all files reviewed at latest revision, 3 unresolved discussions, all commit checks successful.


toxencryptsave/toxencryptsave.api.h, line 54 at r4 (raw file):

 * ${pass_Key.derive}, then use the derived key to encrypt the data.
 *
 * The encrypted data is prepended with a magic number, to aid validity

Is the term here not cookie?

A magic number is something that makes things work, where why could easily unknown.


Comments from Reviewable

@nurupo
Copy link
Member

nurupo commented Dec 15, 2016

toxencryptsave/toxencryptsave.api.h, line 54 at r4 (raw file):

Previously, GrayHatter (Gregory Mullen) wrote…

Is the term here not cookie?

A magic number is something that makes things work, where why could easily unknown.

Magic number is the correct term here https://en.wikipedia.org/wiki/Magic_number_(programming).


Comments from Reviewable

@iphydf iphydf deleted the toxes-api branch December 23, 2016 02:30
This pull request was closed.
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

Successfully merging this pull request may close these issues.

5 participants