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

Check userids for validity. #1337

Merged
merged 7 commits into from
Nov 20, 2020
Merged

Check userids for validity. #1337

merged 7 commits into from
Nov 20, 2020

Conversation

ni4
Copy link
Contributor

@ni4 ni4 commented Oct 31, 2020

This PR adds userid validity checks.
Userid is now considered as valid when:

  • it has valid, non-expired self-signature
  • this self-signature doesn't expire the key itself
  • there is no revocation for this userid.

This changes behavior to the following:

  • key cannot be searched by non-valid userid
  • primary key selection respects only valid userids
  • however, non valid userids still are enumerated, and should be checked for validity via rnp_uid_is_valid().

Also it adds few more functions which allows to retrieve uid-related data via uid handle.

Fixes #1022
Fixes #1126

@ni4 ni4 force-pushed the ni4-1022-userid-validity-checks branch 3 times, most recently from e140acf to 83e6b24 Compare October 31, 2020 15:05
@ni4 ni4 marked this pull request as ready for review October 31, 2020 15:44
@ni4
Copy link
Contributor Author

ni4 commented Oct 31, 2020

Single test is failing for ruby-rnp, it should be addressed via or together with rnpgp/ruby-rnp#69

Copy link
Contributor

@rrrooommmaaa rrrooommmaaa left a comment

Choose a reason for hiding this comment

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

LGTM, but I suggest to use std::set in places where we need to keep unique keys

@@ -82,23 +83,22 @@ TEST_F(rnp_tests, test_key_store_search)
for (size_t i = 0; i < ARRAY_SIZE(testdata); i++) {
pgp_key_id_t keyid = {};
assert_true(rnp_hex_decode(testdata[i].keyid, keyid.data(), keyid.size()));
list seen_keys = NULL;
std::vector<pgp_key_t *> seen_keys;
Copy link
Contributor

Choose a reason for hiding this comment

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

I think it's more convenient to use std::set here

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@rrrooommmaaa That would require to satisfy https://en.cppreference.com/w/cpp/named_req/Compare, and if I understand correctly, pgp_key_t will not. Given that it's just for tests I don't see the reason to spend time on implement that. And, actually, now it works the same way as it worked before. What do you think?

Copy link
Contributor

Choose a reason for hiding this comment

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

@ni4 Aren't we comparing pointers?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@rrrooommmaaa Oh, my fault, somehow mislooked (how?) pointerness, sorry. Fixed and force-pushed.

}
// keyid search (by_name)
for (size_t i = 0; i < ARRAY_SIZE(testdata); i++) {
list seen_keys = NULL;
pgp_key_t *key = NULL;
std::vector<pgp_key_t *> seen_keys;
Copy link
Contributor

Choose a reason for hiding this comment

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

I think it's more convenient to use std::set here

pgp_key_t * key = NULL;
const char *userid = testdata[i].userids[uidn];
key = rnp_tests_key_search(store, userid);
std::vector<pgp_key_t *> seen_keys;
Copy link
Contributor

Choose a reason for hiding this comment

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

I think it's more convenient to use std::set here

@ni4 ni4 force-pushed the ni4-1022-userid-validity-checks branch from 83e6b24 to b916ada Compare November 7, 2020 19:09
Copy link
Contributor

@rrrooommmaaa rrrooommmaaa left a comment

Choose a reason for hiding this comment

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

LGTM!

@ronaldtse
Copy link
Contributor

Seems that there are some failures with ruby-rnp. @dewyatt is there a way we can solve them once and for all?

@dewyatt
Copy link
Contributor

dewyatt commented Nov 11, 2020

It looks like this changes the behavior of rnp_locate_key so that searching via a userid without a valid cert would no longer return results where it may have before. Am I understanding that correctly?
Should we be doing that kind of filtering or should we let the API client decide what to do?

@ni4
Copy link
Contributor Author

ni4 commented Nov 11, 2020

It looks like this changes the behavior of rnp_locate_key so that searching via a userid without a valid cert would no longer return results where it may have before. Am I understanding that correctly?

Yes. Also userid will not be marked as primary if it is considered as invalid.

Should we be doing that kind of filtering or should we let the API client decide what to do?

Usage of non-signed userid (or one with invalid signature) should be considered as a security issue, so I think we should not allow it to be used by default. However, API user still able to list all userids and check their validities.

@dewyatt
Copy link
Contributor

dewyatt commented Nov 17, 2020

It looks like this changes the behavior of rnp_locate_key so that searching via a userid without a valid cert would no longer return results where it may have before. Am I understanding that correctly?

Yes. Also userid will not be marked as primary if it is considered as invalid.

Should we be doing that kind of filtering or should we let the API client decide what to do?

Usage of non-signed userid (or one with invalid signature) should be considered as a security issue, so I think we should not allow it to be used by default. However, API user still able to list all userids and check their validities.

Shouldn't we at least throw some documentation updates in here?

@ronaldtse
Copy link
Contributor

Shouldn't we at least throw some documentation updates in here?

Agree

@ni4 ni4 force-pushed the ni4-1022-userid-validity-checks branch from b916ada to 0145ad8 Compare November 20, 2020 10:56
@ni4
Copy link
Contributor Author

ni4 commented Nov 20, 2020

Shouldn't we at least throw some documentation updates in here?

Agree

Agree as well, just got lost with those CI issues. Update documentation and force-pushed.

@ni4 ni4 force-pushed the ni4-1022-userid-validity-checks branch from 958ddb9 to 5be4730 Compare November 20, 2020 13:27
@ni4
Copy link
Contributor Author

ni4 commented Nov 20, 2020

@dewyatt Should we merge this now? As I checked, only the single ruby-rnp test is failed. And CIFuzz shots it's leg on the container building steps.

@dewyatt
Copy link
Contributor

dewyatt commented Nov 20, 2020

@dewyatt Should we merge this now? As I checked, only the single ruby-rnp test is failed. And CIFuzz shots it's leg on the container building steps.

May as well yes

@dewyatt dewyatt merged commit b72b1b7 into master Nov 20, 2020
@dewyatt dewyatt deleted the ni4-1022-userid-validity-checks branch November 20, 2020 16:22
@ni4 ni4 added this to the v0.14.0 milestone Jan 4, 2021
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.

Do not use non-self-certified userids. Implement userid validity checks.
5 participants