Conversation
abaa06d to
aea80fd
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1742 +/- ##
==========================================
- Coverage 30.87% 30.66% -0.21%
==========================================
Files 51 51
Lines 19419 19505 +86
Branches 9348 9425 +77
==========================================
- Hits 5995 5981 -14
- Misses 7790 7955 +165
+ Partials 5634 5569 -65 ☔ View full report in Codecov by Sentry. |
|
I guess you saw : error[E0599]: the method |
aea80fd to
e30d256
Compare
|
@sylvestre Thanks, I have fixed this error. |
|
This PR is currently blocked on RustCrypto/formats#1013 to avoid pkcs8 to be pulled in. |
48bb9e1 to
9e44a5a
Compare
|
That PR has merged, but latest der v0.7.4 also requires rust 1.65.0 Since current msrv for sccache is 1.64.0, I think it's ok to bump it to 1.65.0 |
9e44a5a to
80ca974
Compare
80ca974 to
09bb44b
Compare
pkcs1 in Jwk::to_der_pkcs1 instead of openssl|
Blocked on tomaka/rouille#272 |
09bb44b to
aad03a1
Compare
|
@Xuanwo Can we re-open this? |
|
Thank you @Xuanwo ! |
bdbf677 to
1eeb97e
Compare
88eeb04 to
e0e075b
Compare
|
@sylvestre It seems that disabling default-feature It seems that |
|
The error in "ci/test ubuntu-22.04 rust 1.65.0 dist-server" actually changed to: |
|
Seems like rustls failed due to bad certificate. |
2604815 to
2006932
Compare
| .context("failed to create digest of x509 certificate")? | ||
| .as_ref() | ||
| .to_owned(); | ||
| let mut rng = OsRng; |
There was a problem hiding this comment.
Could you add a feature gated test, that verifies the certificates generated are identical? It appears the issue seen after porting can originate from a variety of name validation issues i.e. https://github.com/briansmith/webpki/issues/20 so I'd recommend to check consistency against the openssl generated cert first, verify such a openssl generated cert with the logic of rustls and then start debugging into the unit test that should start failing.
There was a problem hiding this comment.
If it's not your cup of tea, leave a message here :)
There was a problem hiding this comment.
I can certainly add a new unit test to ensure the two different methods produces identical certificates, but I'm a bit busy recently
There was a problem hiding this comment.
Although I don't think this is caused by https://github.com/briansmith/webpki/issues/20
dist-server CI uses a self-signed CA AFAIK, so it naturally does not have a ca and it matches the error message from rustls:
[2023-05-17T02:11:22Z ERROR rustls::conn] TLS alert received: AlertMessagePayload {
level: Fatal,
description: UnknownCA,
}
In fact the new ca generation code explicitly excludes ca.
There was a problem hiding this comment.
Do we have an integration test to verify 1:1 reproduction of the certificate? We'd need that for the dist case to remain backward compatible with older "clients".
There was a problem hiding this comment.
No, I'm going to write this by running external openssl command.
There was a problem hiding this comment.
You only need to include a previously generated certificate (i.e. from the current master/main branch), and include it as a reference to compare against / ensure compatibility with.
There was a problem hiding this comment.
@drahnr I don't think it's possible, since the original openssl and the new code both uses the current time when creating the certificate.
Otherwise I could just use a statically embedded certificate.
There was a problem hiding this comment.
a. generate with rustls directly
b. openssl -> file fmt -> parse certificate with rustls
Compare all fields of a and b, except for those that are reasonable to expect to deviate.
|
Thanks & no worries, no rush :)
|
2d1dce1 to
923d94a
Compare
|
Side quest @sylvestre - we should consider using |
|
Yes, sounds good :)
|
|
I'm currently trying to upgrade trust-dns to hickory-dns v0.24 by using |
Maybe it's ok to just use libc's dns resovler in blocking API? |
That's a good advice, I've applied it and hope that the CI will succeed. |
3dd8526 to
364a0de
Compare
|
Updated trust-dns-resolver v0.22 to latest v0.24 (renamed to hickory-dns) and also updates webpki-roots to v0.25. Confirmed that rustls v0.21 has been removed, but CI failure persists. I think it's likely something in the certificate generation that caused the error. |
- Bump rouille from 3.5 => 3.6.2 rouille v3.6.2 fixed a bug: `rouille::Server::new_ssl` is now exposed when only `rustls` is enabled. - Disable default features of `reqwest` which pulls in openssl - Rm `openssl` pulled in dev - Bump reqwest from 0.11.17 => 0.11.18 Signed-off-by: Jiahao XU <[email protected]>
Signed-off-by: Jiahao XU <[email protected]>
Hoping that they will fix the CI test failure Signed-off-by: Jiahao XU <[email protected]>
Signed-off-by: Jiahao XU <[email protected]>
Use CRLF on windows and `\n` on Linux. Also fix formatting of `Cargo.toml` Signed-off-by: Jiahao XU <[email protected]>
364a0de to
1e819f3
Compare
Signed-off-by: Jiahao XU <[email protected]>
|
Sorry, needs rebasing |
|
Sorry I was a bit busy recently, will rebase when I got time. And the CI error is really tricky, I wasn't able to get it fixed. |
| } | ||
|
|
||
| #[cfg(any(feature = "dist-server", feature = "dist-client"))] | ||
| mod reqwest_dns_resolver { |
There was a problem hiding this comment.
What about moving it to the dedicated .rs file?
There was a problem hiding this comment.
Try reqwest-hickory-resolver that maintained by me 😄
|
Hi @NobodyXu, Do you have a time for finalizing this PR? |
|
Hello Honestly I don't know how to fix the CI failure. I don't know openssl good enough and don't have much time recently. |
|
please reopen when ready |
|
Unfortunately I don't have any time now to continue working, so someone else can take over it if they have time and is interested in it |
This is split from #1738 , to remove dependency on
opensslinsrc/bin/sccache-dist/token_check.rs.This also disabled default-feature of
reqwestand dev-depthirtyfour_syncwhich pulled inopensslwhich was a mistake in #1737 since I didn't realize thatreqwestpulls inopensslby default.Signed-off-by: Jiahao XU [email protected]