Curl 60 nur bei AUR Paketen

EOS Deutsch
1

hi

ich habe seit ein paar Wochen folgende Problematik. jedes mal wenn ich versuche AUR pakete zu updaten oder zu installieren schmeist mir yay einen curl60 raus. das ganze betrifft nur Pakete aus der AUR. seit Juli versuche ich dafür eine Lösung zu finden und komme jetzt nicht mehr weiter. Könnte das packnew bzw packsave file dafür verantwortlich sein?

**==> Erstelle Paket: ventoy-bin 1.1.17-1 (Do 27 Aug 2026 14:40:39 CEST)** 
**==> Prüfe Laufzeit-Abhängigkeiten...** 
**==> Prüfe Buildtime-Abhängigkeiten...** 
**==> Empfange Quellen...** 
  **-> Lade ventoy-1.1.17-linux.tar.gz herunter...** 
curl: (60) SSL: no alternative certificate subject name matches target hostname 'github.com' 
More details here: https://curl.se/docs/sslcerts.html 
 
curl failed to verify the legitimacy of the server and therefore could not 
establish a secure connection to it. To learn more about this situation and 
how to fix it, please visit the webpage mentioned above. 
**==> FEHLER: Fehler beim Download von https://github.com/ventoy/Ventoy/releases/download/v1.1.17/ventoy-1.1.17-linux.tar.gz** 
    **Breche ab...** 
 **->** Fehler beim Erstellen: ventoy-bin-exit status 1 
 **->** Die folgenden Pakete konnten nicht installiert werden. Ein manueller Eingriff ist erforderlich: 
ventoy-bin - exit status 1 
zen-browser-bin - exit status 1 
orca-slicer-bin - exit status 1 
litehtml0.9 - exit status 1 
openixsuit-bin - exit status 1 
splix - exit status 1
2

Der entsprechende Download-Link lautet:

https://github.com/ventoy/Ventoy/releases/download/v1.1.17/ventoy-1.1.17-linux.tar.gz

Sie könnten die Datei manuell in Ihrem Browser herunterladen (vorausgesetzt, das funktioniert) und sie dort ablegen: ~/.cache/yay/ventoy-bin/

3

das habe ich teils schon gemacht, löst mein problem aber leider nicht

4

Können Sie bestätigen, dass sich die heruntergeladene Datei noch im Verzeichnis ~/.cache/yay/ventoy-bin/ befindet und die folgende SHA-256-Prüfsumme aufweist:

7fb4ed08cef6a6b4d39dd19260d8c80291a78dfdf9af7d461571e23cbbc43805
5

ja ligt genau so vor

6

Ist Ihr System ansonsten auf dem neuesten Stand?

7

ja ist es

der Weg mit in

~/.cache/yay/...

einfügen funtioniert auch nur für einige awendungen, nicht für alle

8

Ich arbeite über einen Übersetzer, was mit gewissen Schwierigkeiten verbunden ist, daher habe ich mich zunächst auf die „niedrig hängenden Früchte“ konzentriert.

Könntest du bitte Folgendes versuchen:

yay -G ventoy-bin
cd ventoy-bin
makepkg -sri

Dadurch wird an dem Ort, an dem du yay -G ventoy-bin ausführst, ein Verzeichnis namens ventoy-bin (das AUR-Paket) erstellt. Dabei werden zum Erstellen native Arch-Tools anstelle von yay verwendet.

9

Sollte dies ebenfalls fehlschlagen, können Sie die problematische Datei in diesen Ordner herunterladen:

https://github.com/ventoy/Ventoy/releases/download/v1.1.17/ventoy-1.1.17-linux.tar.gz

Ändern Sie anschließend die PKGBUILD-Datei so, dass die Zeile, die derzeit lautet:

source=("https://github.com/ventoy/Ventoy/releases/download/v${pkgver}/${pkgname%-bin}-${pkgver}-linux.tar.gz"

wie folgt geändert wird:

source=("${pkgname%-bin}-${pkgver}-linux.tar.gz"

Auf diese Weise wird erwartet, dass die Datei lokal vorhanden ist, anstatt zu versuchen, sie herunterzuladen.

10

einige Programme, inkl ventoy, haben sich so updaten lassen.
bei anderen funktioniert dieses workaround leider nicht. (z.B. orca-slicer-bin)

11

Wenn ich mir das PKGBUILD von orca-slicer-bin anschaue, sehe ich keinen Grund, warum dieser Ansatz nicht funktionieren sollte. Es ist im Grunde dasselbe.

Ich möchte noch anmerken, dass ich das Problem mit curl und GitHub hier nicht reproduzieren kann. Das Paket lässt sich ohne Eingriffe erfolgreich erstellen. Das scheint ein Problem mit Ihrer Verbindung zu sein. Der hier gegebene Ratschlag dient lediglich dazu, dieses Problem zu umgehen.

12

Interessehalber was ist denn die Ausgabe von curl -Iv https://github.com?

13

sehe ich das richtig, dass das Zertifikat abgelaufen ist?

[user@PC ~]$ curl -Iv https://github.com
* Host github.com:443 was resolved.
* IPv6:
* IPv4:
*   Trying [IPv6]:443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* SSL Trust Anchors:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_CHACHA20_POLY1305_SHA256 / x25519 / RSASSA-PSS
* ALPN: server accepted h2
* Server certificate:
*   subject: CN=autoconfig.giebel.it
*   start date: Oct  2 21:01:49 2025 GMT
*   expire date: Dec 31 21:01:48 2025 GMT
*   issuer: C=US; O=Let's Encrypt; CN=R13
*   Certificate level 0: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*  subjectAltName does not match hostname github.com
* SSL: no alternative certificate subject name matches target hostname 'github.com'
* closing connection #0
curl: (60) SSL: no alternative certificate subject name matches target hostname 'github.com'
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the webpage mentioned above.
14

Das Problem scheint hier zu liegen.

Bei mir wird Folgendes angezeigt:

* Server certificate:
*   subject: CN=github.com
*   start date: Jul  3 00:00:00 2026 GMT
*   expire date: Sep 30 23:59:59 2026 GMT
15

Da Ihr Browser die Datei offenbar herunterladen kann, handelt es sich vielleicht um ein DNS-Problem (da Browser oft separat konfigurierte DNS-Einstellungen verwenden)?

Versuchen Sie doch einmal Folgendes, um zu sehen, welcher Server die Auflösung für Sie übernimmt:

nslookup github.com
16

der output

user@PC ~]$ nslookup github.com
Server:         49.12.67.122
Address:        49.12.67.122#53

Non-authoritative answer:
Name:   github.com
Address: 140.82.121.3
17

dig gibt an, dass diese IP-Adresse zu dnsforge.de gehört.

Weißt du, wo das konfiguriert ist? Versuche doch mal, es zu ändern – wenn auch nur vorübergehend – zum Beispiel auf Quad9.

18

der dns ist ncht das Problem. Hab den schon deaktiviert gehabt und anschließend wieder aktiviert

19

DNS speichert Daten im Cache, daher würde ich nicht mit sofortigen Ergebnissen rechnen.

Wenn Sie nslookup erneut ausführen, wird die Adresse dann immer noch auf dnsforge.de aufgelöst?

20

https://giebel.it/ erscheint mir relativ spezifisch. Klingelt da irgendwas unter dem Namen, machen die u.U. IT Dienstleistung bei euch?