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

proto: move extension-specific linking validation into extensions #6657

Merged
merged 3 commits into from
Apr 23, 2019

Conversation

goaway
Copy link
Contributor

@goaway goaway commented Apr 19, 2019

Signed-off-by: Mike Schore mike.schore@gmail.com

Description: A couple of the proto descriptors validated during startup are specific to extensions that may be compiled out. This change only validates their presence when the extensions are used. This fixes some spurious validation failures in certain minimal build configurations.
Risk Level: Low
Testing: Ran test suite, ran server.
Docs Changes: N/A
Release Notes: N/A

Signed-off-by: Mike Schore <mike.schore@gmail.com>
@goaway
Copy link
Contributor Author

goaway commented Apr 19, 2019

I considered moving ratelimit as well, but we didn't actually run into issues with it. (Not sure if it's actually possible to fully compile out* ratelimit at this point.) Also an open question whether there are any other cases that should be included. Just wanted to mention in case anyone has insight/opinions.

@htuch htuch self-assigned this Apr 19, 2019
Signed-off-by: Mike Schore <mike.schore@gmail.com>
Copy link
Member

@htuch htuch left a comment

Choose a reason for hiding this comment

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

The idea of kicking out the service definitions that are non-standard from the main proto validation seems legit. But, it makes me wonder which other extension services we're missing validators for.

srcs = ["grpc_access_log_proto_descriptors.cc"],
hdrs = ["grpc_access_log_proto_descriptors.h"],
deps = [
"//source/common/config:protobuf_link_hacks",
Copy link
Member

Choose a reason for hiding this comment

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

I don't think the link hacks apply in this situation (see the comment in the respective file).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah yep, makes sense - this is cruft left over from me copying the dependencies.

@htuch htuch added the waiting label Apr 22, 2019
@goaway
Copy link
Contributor Author

goaway commented Apr 22, 2019

Not sure what we might be missing - but one thought I floated by Matt in an earlier conversation is that we could also just do dummy linking for everything instead of validation, until whatever needs to be fixed upstream for this all to work is fixed.

Signed-off-by: Mike Schore <mike.schore@gmail.com>
@htuch
Copy link
Member

htuch commented Apr 23, 2019

@goaway I think the challenge is figuring out what "everything" is here. Do you have any thoughts on how that would be computed?

Copy link
Member

@htuch htuch left a comment

Choose a reason for hiding this comment

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

LGTM, thanks. Let's continue the thread in this PR and open an issue if needed for the long term fix here.

@htuch htuch merged commit 37b4d2d into envoyproxy:master Apr 23, 2019
@goaway
Copy link
Contributor Author

goaway commented Apr 23, 2019

Empirically, we encountered just the above two cases when building with only HttpConnMan and the Router as extensions, with a single public entrypoint.

We could possibly induce further failures by building with only a single dummy filter.

However, this really only captures the current state of the world, and further development/refactors could change things. (As an aside, the current validation setup in proto_descriptors.cc will fail fast, but requires a code change to see what actually failed, since it only returns a boolean. We could assert/panic inside that file - though perhaps the boolean return value is better for testing.)

My thought though was merely to replace the validation of each proto currently checked with a dummy ref to ensure it gets compiled in. This won't capture cases we've missed, but it won't reduce our coverage either.

If we really wanted to go all in; we could add a dummy message to any proto file we build in, and explicitly reference those messages whenever the generated header is included.

@goaway
Copy link
Contributor Author

goaway commented Apr 23, 2019

And also, thanks @htuch !

@htuch
Copy link
Member

htuch commented Apr 23, 2019

@goaway yeah, I guess it would be a bit cleaner, but I'm also wondering if we should just figure out if the suggestion in protocolbuffers/protobuf#4221 makes sense. If we set always_link, does it work?

@goaway
Copy link
Contributor Author

goaway commented Apr 23, 2019

@htuch I was under the possible misapprehension that always_link didn't work in this case for some reason. If it does, I agree that's cleaner than dummy refs in code.

@htuch
Copy link
Member

htuch commented Apr 23, 2019

Well, not sure if it does :) The last state in that Protobuf GH issue is that we needed to try it.

mpuncel added a commit to mpuncel/envoy that referenced this pull request Apr 24, 2019
* master:
  docs: add extension policy (envoyproxy#6678)
  ext_authz: added ability to detect partial request body data (envoyproxy#6583)
  version_history.rst: jwt_authn change missed 1.10.0 (envoyproxy#6684)
  docs: fix link in pull request template (envoyproxy#6679)
  Explicitly convert absl::string_view to std::string. (envoyproxy#6687)
  docs: improving watermark docs/comments (envoyproxy#6683)
  http filter: add CSRF filter (envoyproxy#6470)
  event: reintroduce dispatcher stats (envoyproxy#6659)
  security: postmortem for CVE-2019-990[01] (envoyproxy#6597)
  Improve build rules for (test only) library quic_port_utils. (envoyproxy#6672)
  spell check: skip unsupported extensions when called with a file (envoyproxy#6648)
  Changed TestHooks to ListenerHooks (envoyproxy#6642)
  proto: move extension-specific linking validation into extensions (envoyproxy#6657)
  stats: add/test heterogenous set of StatNameStorage objects. (envoyproxy#6504)
  docs: move xds protocol to rst (envoyproxy#6670)
  fix version history order (envoyproxy#6671)

Signed-off-by: Michael Puncel <mpuncel@squareup.com>
@goaway
Copy link
Contributor Author

goaway commented Apr 24, 2019

I don't mind giving it a try. Can at least see if it works for the case we encountered.

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.

2 participants