SwiftNIO SSL is broken on Termux

[lyricalsoul]

All requests are failing with a BoringSSL handshake error. Already tried it with several websites and I get the same error everytime.

handshakeFailed(NIOSSL.BoringSSLError.sslError([Error: 268435581 error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED]))

Swift version:

Swift version 5.5.2 (swift-5.5.2-RELEASE)
Target: armv7-unknown-linux-androideabi24

Any ideas?

[finagolfin]

Hmm, it's possible there's some Android incompatibility we missed. Does your code work fine on linux x86_64? What about linux armv7, tried it on there?

I haven't run the NIO SSL tests on 32-bit armv7 in a while, it's possible a regression crept in or maybe something we always missed. What happens when you run swift test on NIO SSL in your armv7 Termux app? On AArch64, all the tests pass.

[lyricalsoul]

Skipped it and it worked. notValidAfter was the only test having issues. Everything passed just fine.

Executed 229 tests, with 0 failures (0 unexpected) in 18.02 (18.02) seconds

[lyricalsoul]

Did some messing around with the test and this happens when calling time_t:

Swift/IntegerTypes.swift:13751: Fatal error: Double value cannot be converted to Int because the result would be greater than Int.max

        let expectedDate = self.dateFromComponents(year: 2047, month: 10, day: 9, hour: 21, minute: 01, second: 02)
        let expectedSeconds = time_t(expectedDate.timeIntervalSince1970)

But the random segfault stopped after commenting the following line:

let notValidBeforeSeconds = cert.notValidAfter

[finagolfin]

I finally cross-compiled this Swift package for armv7 on my Android AArch64 phone and ran the tests, got the same results as you. I forget if I ran these tests for armv7 last year- I think I did- and if I got the same results then. I'll look into this segfault now.

[finagolfin]

This failing test is an overflow because time_t is a signed 32-bit integer on Android armv7 and it can't hold the number of seconds from the epoch, ie 1970, if the certificate is valid after 2033 or so, as it is in that test.

Unless you're dealing with such long-lived certificates and calling this function yourself, this bug is unlikely to be related to your original error, as this library never calls that notValidAfter function anywhere other than the test.

Can you share what Swift code gave you the initial verification error? This failing test is unlikely to be related to it, I'll file an issue for the test.

[lyricalsoul]

Can you share what Swift code gave you the initial verification error? This failing test is unlikely to be related to it, I'll file an issue for the test.

  private func go<T : Codable>(_ type: T.Type, method: String, parameters: [String: Any]? = nil) async -> (T?) {
    let url = "\(self.apiURL)/bot\(self.token)/\(method)"
    
    return await withCheckedContinuation { continuation in
      httpClient.execute(request: buildRequest(url: url, parameters: parameters)!).whenComplete { [self] rst in
        switch rst {
        case .failure(let error):
          logger.warning("request failed with: \(error)")
          continuation.resume(returning: nil)
        case .success(let response):
            ...
  }

  private func buildRequest(url: String, parameters: [String: Any]? = nil) -> HTTPClient.Request? {
    guard var request = try? HTTPClient.Request(url: url, method: (parameters != nil ? .POST : .GET)) else {
      return nil
    }
    
    request.headers.add(name: "User-Agent", value: "Folklore (https://github.com/lyricalsoul/folklore)")
    if let params = parameters {
      request.headers.add(name: "Content-Type", value: "application/json")
      request.body = .string(params.jsonString!)
    }
    
    return request
  }

It fails here. I get a .failure result. I'm using the latest async-http-client version, by the way:

    .package(url: "https://github.com/swift-server/async-http-client.git", from: "1.0.0"),