Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
cert validation: use Android cert validation APIs #2525
cert validation: use Android cert validation APIs #2525
Changes from 18 commits
f0a846a
464f365
7edc2ef
d8e9c6d
c9894a1
b1f9a04
79443ee
b40b230
93ab2ed
1e4f295
e13b72e
c8fdf91
ffa0c1b
0a8a474
9012dbb
c6cea9d
27129eb
8384259
3de8d89
658a340
403eca1
3a02268
2154876
2f1e156
e5a6bcc
47ea600
0e3d5ef
76bd20e
26b754f
c680e44
5fc2770
d9c4c0f
d485003
853667f
b76a1ad
09433c4
a481c44
406c24f
00ecfa4
66580a3
1a2cc8b
cebcea3
82f87c4
ed215f0
c4b6198
7fd388b
61ab5c8
3e9418e
34526b3
e815550
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Remove newline?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let's rename this property so that it matches the new name of the public method (to avoid confusion, make code easier to follow)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
platform_cert_validator
is updated to the new one in any other place that still use the old naming (if there are any like that)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The main config (
config_header
+config_template
) concatenated is 100% valid YAML and a valid default configuration for Envoy Mobile. Adding this breaks that convention, since {{'s syntactical meaning in YAML. This is why the few places where interpolation via token still occurs in the main config, the token uses a style that's interpreted by YAML as a comment (#{}
) and the config is valid when it's empty.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, if I change it to use
#{custom_cert_validation_context}
but without replacement withplatform_cert_validation_context_template
ordefault_cert_validation_context_template
defined above, the YAML will have an emptyvalidation_context:
, which is a valid YAML, but not a good TLS config for Envoy.I see that
{{
s are used in template inserts, i.e. http filters, which can be optional, but I don't think validation context should be optional, and the engine has to config it one way or the other. So the question here is whether it still meaningful to make the config_template a valid default configuration, given the engine will do the replacement all the time?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that there is a value in keeping the config to be a valid YAML at all times (even if we do not replace some substrings that are intended to be replaces). I think that we should not resign from the current status quo without having strong reasons to do so since I am quite positive that the current set up makes it easier to work with multiple separate builder (Swift, Kotlin and c++). If we learn that it's not possible to do so we can change our approach in here.
With that being said, would it be possible to have
and make builders (Kotlin, c++) to conditionally add the following line(s):
I think that for this to work you would need to move
validation_context
to config_header (https://github.com/envoyproxy/envoy-mobile/pull/2525/files#diff-1af53ae37f8c227f37b80bcb6e2335f55b2f830aa658ac77e099f2549f157712L85).Does it make sense? Could it work for what you a re trying to accomplish?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you explain a bit more about this? Are you suggesting to have 2
&validation_context
definitions and somehow the added one can take effect? And why they have to be in the config_header? AFAIK, config_header string is not manipulated by the engine builder at all.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, let me try to explain my understanding of our YAML setup.
So when you have more than one 'definition' (YAML anchor) such as
&validation_context
the last processed one takes effect when we evaluate*validation_context
(YAML alias). An example from some YAML playground that I use to play with it in the past (link):Now about the
config_header
. Its main purpose is to act as a place for all of the default values for various YAML variables (variable is not the right YAML term, the right term is YAML anchor) so what we could use it for is to provide a default value forvalidation_context
.It is fine that that engine builder does not modify the
config_header
. The engine builder does prepend content to theconfig_template
part of the config so the final Envoy config looks something as follows:So looking at ^ you can provide a default value in 1):
override it in 2) as needed (conditionally) - by either adding or not adding the following string:
and this is what will be visible to YAML in 3).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the suggestion! It basically worked. One small wrinkle here is that I had to also append
when we don't config platform cert validator, even though it's duplicated with config_header. This is because &trust_chain_verification gets overridden.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see - so it's a little bit more tricky here. Nice catch 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After a little bit more of thinking. Should we just move
validation_context_config_trust_chain
anchor fromconfig_header
to the beginning of theconfig_template
instead and keep thevalidation_context
where it is now? That should work I think (and the resulting YAML would still be a valid config)?(That would allow you to avoid having the prepend
validation_context_config_trust_chain
)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I deprecated
validation_context
and usedvalidation_context_config_trust_chain
for all protocols. The templates are consolidated to 2 right now, default validation v.s. platform-based validation. PTAL.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we replace
{{custom_cert_validation_context}}
with*validation_context
in here? (so that we limit the number of string manipulation operations that we significantly reduced when we started using yaml & and *)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Basically, I wonder whether we can remove the number of places where we reference
{{custom_cert_validation_context}}
from 2 to 1.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice clean up 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: comments, please
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comments on all the structs/functions, please
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
when would we expect this to be false? Asking mostly so that I understand why it's needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually don't know, but I saw this has been used in all c_types.h to wrap the C interface.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's necessary because the public headers are both valid C++ and pure C headers.
extern "C"
is needed when compiling for C++ to prevent the compiler from munging the function names in publicly-exposed interface.When called publicly (e.g. from the built-in iOS and Android platform layers), they're bound as C functions. When the core layer is compiled though, everything is C++.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @goaway 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the platform verifier work on non-Android platforms? If so, perhaps we should make this check "if not android"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Though we don't have non-Android platform supporting this, the current cronet tests do mock up the API calls so at least those cronet tests worked on non-Android platform. So I'm not going to enforce platform checking here.
Non-cronet enginer builders don't provide the interface to choose platform based cert validator after all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Considering
envoy-mobile/library/common/api/external.cc
Line 25 in 5e8d877
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would be the bad config case. Would it make sense to throw or PANIC as this is still during start up?
TBH I couldn't think of how this could happen given the config is generated based on the boolean usePlatformCertValidator in production. It could happen during development if someone mess up the engine builder. In that case, an ENVOY_BUG will be helpful to debug.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: since this member is actually the validator, I'd be inclined to name the member
validator_
, but your call.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done