setup-swift: Unexpected error, unable to continue. Please report (gpg: no valid OpenPGP data found.)

@dabrahams in the mean time if you’re looking for another workaround that doesn’t involve skipping the signature verification, you could consider using the swift Docker image in your action workflow:

name: Swift

on:
  pull_request:
  push:
    branches: [ "main" ]

jobs:
  test:
    runs-on: ubuntu-latest
    container: swift:5.8
    steps:
      - uses: actions/checkout@v3
      - name: Run tests
        run: swift test

This is as fast as using swift-actions/setup-swift, taking around 30s to initialize the container

Gentle bump: this is breaking CI for Hylo.

I did some debugging of a failing workflow run using action-tmate and it turns out the swift.org server compresses the response, so the file being downloaded is actually gzipped, which is why it cannot be imported in gpg. The same happens in my terminal:

❯ curl -v --output all-keys.asc https://www.swift.org/keys/all-keys.asc
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 17.253.53.204:443...
* Connected to www.swift.org (17.253.53.204) port 443 (#0)
* ALPN: offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
} [318 bytes data]
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* (304) (IN), TLS handshake, Unknown (8):
{ [21 bytes data]
* (304) (IN), TLS handshake, Certificate (11):
{ [3610 bytes data]
* (304) (IN), TLS handshake, CERT verify (15):
{ [80 bytes data]
* (304) (IN), TLS handshake, Finished (20):
{ [36 bytes data]
* (304) (OUT), TLS handshake, Finished (20):
} [36 bytes data]
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256
* ALPN: server accepted http/1.1
* Server certificate:
*  subject: CN=swift.org; O=Apple Inc.; ST=California; C=US
*  start date: Oct 25 18:09:36 2022 GMT
*  expire date: Nov 24 18:09:35 2023 GMT
*  subjectAltName: host "www.swift.org" matched cert's "www.swift.org"
*  issuer: CN=Apple Public Server ECC CA 12 - G1; O=Apple Inc.; ST=California; C=US
*  SSL certificate verify ok.
* using HTTP/1.1
> GET /keys/all-keys.asc HTTP/1.1
> Host: www.swift.org
> User-Agent: curl/7.88.1
> Accept: */*
> 
< HTTP/1.1 200 OK
< Server: Apple
< Date: Sun, 20 Aug 2023 18:33:51 GMT
< Content-Type: text/plain; charset=UTF-8
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Last-Modified: Fri, 18 Aug 2023 19:09:05 GMT
< X-Frame-Options: SAMEORIGIN
< Strict-Transport-Security: max-age=31536000; includeSubdomains
< Content-Encoding: gzip
< Cache-Control: max-age=180, public
< Accept-Ranges: bytes
< Content-Length: 10412
< Via: http/1.1 nlams2-edge-lx-007.ts.apple.com (acdn/84.14362), http/1.1 nlams2-edge-bx-014.ts.apple.com (acdn/84.14362)
< X-Cache: hit-fresh, hit-fresh
< CDNUUID: 9d0b2fa7-c23b-451d-9b8c-e55736742dc1-427031446
< Etag: "41c9-6033743275640"
< Age: 10
< Connection: keep-alive
< 
{ [1300 bytes data]
100 10412  100 10412    0     0   165k      0 --:--:-- --:--:-- --:--:--  221k
* Connection #0 to host www.swift.org left intact

❯ file all-keys.asc 
all-keys.asc: gzip compressed data, max speed, from Unix, original size modulo 2^32 16841

I tried forcing the server to send an uncompressed response by setting accept-encoding: identity and by setting accept-encoding: gzip;q=0 but both attempts still yielded a gzipped response.

What I don’t get is why this happens intermittently. It’s as if some of the swift.org servers are misconfigured and therefore some send a compressed response while others don’t, which is why the action is able to succeed every now and then.

This also makes fixing the bug a little bit annoying: since there is no way of knowing whether the response is compressed or not, the action should first check the file information and then decompress if needed.

I suspect the same issue occurs when the action is able to download the signing keys but then fails to verify the signature file; probably the signature file response is gzipped as well.