Skip to content

Fix compilation error in JWT using const_cast.#18475

Merged
soheilhy merged 1 commit intogrpc:masterfrom
soheilhy:fix-jwt
Mar 26, 2019
Merged

Fix compilation error in JWT using const_cast.#18475
soheilhy merged 1 commit intogrpc:masterfrom
soheilhy:fix-jwt

Conversation

@soheilhy
Copy link
Copy Markdown
Contributor

I got this error on an unrelated patch, and I believe the Distribution Test is broken:

    /var/local/git/grpc/src/core/lib/security/credentials/jwt/jwt_verifier.cc:628:57: error: invalid conversion from 'const uint8_t* {aka const unsigned char*}' to 'unsigned char*' [-fpermissive]
                                 GRPC_SLICE_LENGTH(signature)) != 1) {
                                                             ^
    In file included from /usr/include/openssl/pem.h:69:0,
                     from /var/local/git/grpc/src/core/lib/security/credentials/jwt/jwt_verifier.cc:35:
    /usr/include/openssl/evp.h:642:5: note: initializing argument 2 of 'int EVP_DigestVerifyFinal(EVP_MD_CTX*, unsigned char*, size_t)'
     int EVP_DigestVerifyFinal(EVP_MD_CTX *ctx, unsigned char *sig, size_t siglen);

@soheilhy soheilhy requested a review from nicolasnoble March 22, 2019 10:57
@soheilhy soheilhy added the release notes: no Indicates if PR should not be in release notes label Mar 22, 2019
I got this error on an unrelated patch, and I believe the Distribution
Test is broken:

/var/local/git/grpc/src/core/lib/security/credentials/jwt/jwt_verifier.cc:628:57: error: invalid conversion from 'const uint8_t* {aka const unsigned char*}' to 'unsigned char*' [-fpermissive]
                             GRPC_SLICE_LENGTH(signature)) != 1) {
                                                         ^
In file included from /usr/include/openssl/pem.h:69:0,
                 from /var/local/git/grpc/src/core/lib/security/credentials/jwt/jwt_verifier.cc:35:
/usr/include/openssl/evp.h:642:5: note: initializing argument 2 of 'int EVP_DigestVerifyFinal(EVP_MD_CTX*, unsigned char*, size_t)'
 int EVP_DigestVerifyFinal(EVP_MD_CTX *ctx, unsigned char *sig, size_t siglen);
@soheilhy
Copy link
Copy Markdown
Contributor Author

@vjpai vjpai requested a review from yihuazhang March 23, 2019 23:52
Copy link
Copy Markdown
Contributor

@vjpai vjpai left a comment

Choose a reason for hiding this comment

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

LGTM for code quality but please get an approval from @yihuazhang or @jiangtaoli2016

@vjpai
Copy link
Copy Markdown
Contributor

vjpai commented Mar 26, 2019

It looks like there are still distrib test failures that are also SSL related....

@soheilhy
Copy link
Copy Markdown
Contributor Author

soheilhy commented Mar 26, 2019 via email

@yihuazhang
Copy link
Copy Markdown
Contributor

Sorry for the delay. I am looking at the issue now.

@soheilhy
Copy link
Copy Markdown
Contributor Author

soheilhy commented Mar 26, 2019 via email

@yihuazhang
Copy link
Copy Markdown
Contributor

From the log of distribtests, I found the test is linking openssl 1.0.1t which is out of support and that's probably the reason for SSL-related failures. I think the changes in this PR may not be necessary if linking to the up-to-date version of openssl.

@nicolasnoble
Copy link
Copy Markdown
Contributor

Well, the issue is that Debian Jessie is still within LTS, and they do their own vendoring of OpenSSL 1.0.1 patches, so...

And last time we broke Debian Jessie, we caused an official Google outage.

@nicolasnoble
Copy link
Copy Markdown
Contributor

So, I have verified the manual pages and the code of OpenSSL in Debian Jessie. The behavior of EVP_DigestVerifyFinal didn't change, they just correctly added the const keyword there. Therefore, the usage of const_cast is valid in this case.

Still, I'm confused as to how this is only a problem now. What did we change?

@soheilhy
Copy link
Copy Markdown
Contributor Author

Thank you @nicolasnoble ! Yes, this patch is valid, but there will other errors if/when I submit this:
https://source.cloud.google.com/results/invocations/150afc8a-de46-4b66-93b9-0486a2687ad7/targets/grpc%2Fcore%2Fpull_request%2Flinux%2Fgrpc_distribtests_standalone/log

I guess there are undefined macros and such, but haven't taken a closer look.

@nicolasnoble
Copy link
Copy Markdown
Contributor

I see. There's a recent PR then that broke OpenSSL 1.0.1. Let's dig this up.

@jiangtaoli2016
Copy link
Copy Markdown

it is due to #17868
When did we add distribution linux test?

@soheilhy
Copy link
Copy Markdown
Contributor Author

Thank you. So I will merge this PR, but would you be able to handle the rest of breakage?

@jiangtaoli2016
Copy link
Copy Markdown

We security team always wanted a more comprehensive gRPC test coverage against boringSSL and various versions of OpenSSL. I made such request 1+ years ago. Not sure what is the progress.

At least Distribution Tests Linux checks compilation error again old OpenSSL.

Fix on the way. @soheilhy I will take care of it.

@soheilhy
Copy link
Copy Markdown
Contributor Author

Awesome! Thank you @jiangtaoli2016 !

@soheilhy soheilhy merged commit 65ec942 into grpc:master Mar 26, 2019
@nicolasnoble
Copy link
Copy Markdown
Contributor

Yes, this is really fishy. We had the OpenSSL 1.0.1 test in there for a long time, since it's literally our distribution test for Debian Jessie that's been here since almost forever. I can confirm this is caused by #17868, but I have no idea why it didn't break then: https://source.cloud.google.com/results/invocations/e6f81e28-5d34-4003-8889-14948c13f18e/log

The same exact test ran then and went back green.

@jtattermusch that's really odd.

@nicolasnoble
Copy link
Copy Markdown
Contributor

Ugh, I know exactly what's going on actually. Debian Jessie started shuffling things around in preparation of the LTS ending in June. The jessie-backports repository changed, and therefore, we've started picking up a DIFFERENT version of the Jessie libssl package. @murgatroid99 may have a better fix overall coming up by applying the solution from https://unix.stackexchange.com/questions/508724/failed-to-fetch-jessie-backports-repository

@jiangtaoli2016 please hold off making further changes to TSI until we try this first.

@jiangtaoli2016
Copy link
Copy Markdown

SG. @nicolasnoble Let me know if I need to make the change in SSL TSI.

@nicolasnoble
Copy link
Copy Markdown
Contributor

nicolasnoble commented Mar 29, 2019

Alright, #18530 is properly fixing this. I'm not going to issue a revert of this one, but I'm glad to see that the problem was an external factor, and not our code.

@soheilhy
Copy link
Copy Markdown
Contributor Author

Awesome! @nicolasnoble FWIW, I wouldn't mind if you prefer reverting the hack here.

@lock lock bot locked as resolved and limited conversation to collaborators Jun 27, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

priority/P0/RELEASE BLOCKER release notes: no Indicates if PR should not be in release notes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants