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

Warn about the presence of surprising 3rd party GraalVM substitutions #21069

Open
Sanne opened this issue Oct 28, 2021 · 5 comments
Open

Warn about the presence of surprising 3rd party GraalVM substitutions #21069

Sanne opened this issue Oct 28, 2021 · 5 comments
Labels

Comments

@Sanne
Copy link
Member

Sanne commented Oct 28, 2021

Description

Some 3rd party libraries have started to include GraalVM substitutions, and managed to include harmful ones.

Generally code can be refactored to not require a Substitution; at least so far we have always been able to do so - when able to contribute patches. At worst, libraries could ship Substitutions in a separate artifact to allow some more flexibility - for example to not couple a library release to a specific GraalVM version and the particular subsitutions this might require.

We should at least start by logging a warning for any substitution which is identified (when not provided by the Quarkus extension); then if such warnings turn out to be too noisy we can refine this.

Implementation ideas

Jandex ...

@geoand
Copy link
Contributor

geoand commented Nov 25, 2021

I like the idea. Would you expect we log a warning for every substitution we find?

@Sanne
Copy link
Member Author

Sanne commented Nov 25, 2021

TBH I haven't thought it all through in detail about what action to take. First priority for us is to be aware of whatever is being included.

I suppose logging a warning would be a good starting point.

Ideally we'll want to have also a build item so to "authorize" expected substitutions - but this will be tedious to setup initially as we need it to be fine-grained so to catch new substitutions that might appear in the future when upgrading libraries.

Let's just start with a warning and see what's out there?

@geoand
Copy link
Contributor

geoand commented Nov 26, 2021

Thinking about this a little more, it might actually slow down build time quite a bit, since currently we don't index all dependencies and a feature like this would force us to do so.

@Sanne
Copy link
Member Author

Sanne commented Dec 3, 2021

@geoand sorry - back from the dead now.

What about indexing the extension's dependencies at build time? (build time of the extension)

I guess we could model it as an integration test.

@geoand
Copy link
Contributor

geoand commented Dec 3, 2021

I think that's a good idea

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants