Network Options

ca_roots() :: Union{Nothing, String}

Die Funktion ca_roots() informiert den Aufrufer, wo, falls vorhanden, eine Datei oder ein Verzeichnis mit PEM-kodierten Wurzeln von Zertifizierungsstellen zu finden ist. Standardmäßig gibt diese Funktion auf Systemen wie Windows und macOS, auf denen die integrierten TLS-Engines wissen, wie man Hosts mit dem integrierten Zertifikatsüberprüfungsmechanismus des Systems verifiziert, nothing zurück. Auf klassischen UNIX-Systemen (außer macOS) werden Wurzelzertifikate typischerweise in einer Datei in /etc gespeichert: die gängigen Orte für das aktuelle UNIX-System werden durchsucht, und wenn einer dieser Pfade existiert, wird er zurückgegeben; wenn keiner dieser typischen Wurzelzertifikatpfade existiert, wird der Pfad zu den Wurzelzertifikaten zurückgegeben, die mit Julia gebündelt sind.

Der Standardwert, der von ca_roots() zurückgegeben wird, kann überschrieben werden, indem die Umgebungsvariablen JULIA_SSL_CA_ROOTS_PATH, SSL_CERT_DIR oder SSL_CERT_FILE gesetzt werden, in diesem Fall gibt diese Funktion immer den Wert der ersten dieser Variablen zurück, die gesetzt ist (unabhängig davon, ob der Pfad existiert oder nicht). Wenn JULIA_SSL_CA_ROOTS_PATH auf den leeren String gesetzt ist, werden die anderen Variablen ignoriert (als ob sie nicht gesetzt wären); wenn die anderen Variablen auf den leeren String gesetzt sind, verhalten sie sich so, als wären sie nicht gesetzt.

ca_roots_path() :: String

Die Funktion ca_roots_path() ist ähnlich der Funktion ca_roots(), mit dem Unterschied, dass sie immer einen Pfad zu einer Datei oder einem Verzeichnis von PEM-kodierten Wurzeln der Zertifizierungsstellen zurückgibt. Wenn sie auf einem System wie Windows oder macOS aufgerufen wird, wo die Systemstammzertifikate nicht im Dateisystem gespeichert sind, gibt sie derzeit den Pfad zu dem Satz von Stammzertifikaten zurück, die mit Julia gebündelt sind. (In Zukunft könnte diese Funktion stattdessen die Stammzertifikate vom System extrahieren und sie in einer Datei speichern, deren Pfad zurückgegeben wird.)

Wenn es möglich ist, eine Bibliothek, die TLS verwendet, so zu konfigurieren, dass die Systemzertifikate verwendet werden, ist das im Allgemeinen vorzuziehen: d.h. es ist besser, ca_roots() zu verwenden, das nothing zurückgibt, um anzuzeigen, dass die Systemzertifikate verwendet werden sollen. Die Funktion ca_roots_path() sollte nur verwendet werden, wenn Bibliotheken konfiguriert werden, die einen Pfad zu einer Datei oder einem Verzeichnis für Stammzertifikate benötigen.

Der Standardwert, der von ca_roots_path() zurückgegeben wird, kann überschrieben werden, indem die Umgebungsvariablen JULIA_SSL_CA_ROOTS_PATH, SSL_CERT_DIR oder SSL_CERT_FILE gesetzt werden, in welchem Fall diese Funktion immer den Wert der ersten dieser Variablen zurückgibt, die gesetzt ist (unabhängig davon, ob der Pfad existiert oder nicht). Wenn JULIA_SSL_CA_ROOTS_PATH auf den leeren String gesetzt ist, werden die anderen Variablen ignoriert (als ob sie nicht gesetzt wären); wenn die anderen Variablen auf den leeren String gesetzt sind, verhalten sie sich so, als wären sie nicht gesetzt.

ssh_dir() :: String

Die Funktion ssh_dir() gibt den Speicherort des Verzeichnisses zurück, in dem das ssh-Programm Konfigurationsdateien speichert/sucht. Standardmäßig ist dies ~/.ssh, kann jedoch durch Setzen der Umgebungsvariable SSH_DIR überschrieben werden.

ssh_key_pass() :: String

Die Funktion ssh_key_pass() gibt den Wert der Umgebungsvariable SSH_KEY_PASS zurück, wenn sie gesetzt ist, oder nothing, wenn sie nicht gesetzt ist. In Zukunft könnte es möglich sein, ein Passwort auf andere Weise zu finden, wie z.B. durch sicheren Systemspeicher. Daher sollten Pakete, die ein Passwort zum Entschlüsseln eines SSH-Privatschlüssels benötigen, diese API verwenden, anstatt direkt die Umgebungsvariable zu überprüfen, damit sie solche Fähigkeiten automatisch erhalten, wenn sie hinzugefügt werden.

ssh_key_name() :: String

Die Funktion ssh_key_name() gibt den Basisnamen der Schlüsseldateien zurück, die SSH beim Herstellen einer Verbindung verwenden sollte. Es gibt normalerweise keinen Grund, warum diese Funktion direkt aufgerufen werden sollte, und Bibliotheken sollten im Allgemeinen die Funktionen ssh_key_path und ssh_pub_key_path verwenden, um vollständige Pfade zu erhalten. Wenn die Umgebungsvariable SSH_KEY_NAME gesetzt ist, gibt diese Funktion diesen Wert zurück; andernfalls gibt sie standardmäßig id_rsa zurück.

ssh_key_path() :: String

Die Funktion ssh_key_path() gibt den Pfad der SSH-Privatschlüsseldatei zurück, die für SSH-Verbindungen verwendet werden sollte. Wenn die Umgebungsvariable SSH_KEY_PATH gesetzt ist, wird dieser Wert zurückgegeben. Andernfalls wird standardmäßig zurückgegeben

joinpath(ssh_dir(), ssh_key_name())

Dieser Standardwert hängt wiederum von den Umgebungsvariablen SSH_DIR und SSH_KEY_NAME ab.

ssh_pub_key_path() :: String

Die Funktion ssh_pub_key_path() gibt den Pfad der SSH-Öffentlichen Schlüsseldatei zurück, die für SSH-Verbindungen verwendet werden sollte. Wenn die Umgebungsvariable SSH_PUB_KEY_PATH gesetzt ist, wird dieser Wert zurückgegeben. Wenn dies nicht gesetzt ist, aber SSH_KEY_PATH gesetzt ist, wird dieser Pfad mit dem angehängten Suffix .pub zurückgegeben. Wenn keines gesetzt ist, wird standardmäßig zurückgegeben

joinpath(ssh_dir(), ssh_key_name() * ".pub")

Dieser Standardwert hängt wiederum von den Umgebungsvariablen SSH_DIR und SSH_KEY_NAME ab.

ssh_known_hosts_files() :: Vector{String}

Die Funktion ssh_known_hosts_files() gibt einen Vektor von Pfaden zu SSH bekannten Hosts-Dateien zurück, die verwendet werden sollten, wenn die Identitäten von Remote-Servern für SSH-Verbindungen hergestellt werden. Standardmäßig gibt diese Funktion zurück

[joinpath(ssh_dir(), "known_hosts"), bundled_known_hosts]

wobei bundled_known_hosts der Pfad zu einer Kopie einer bekannten Hosts-Datei ist, die mit diesem Paket gebündelt ist (enthält bekannte Hosts-Schlüssel für github.com und gitlab.com). Wenn die Umgebungsvariable SSH_KNOWN_HOSTS_FILES gesetzt ist, wird ihr Wert jedoch in Pfade am :-Zeichen (oder am ; unter Windows) aufgeteilt und dieser Vektor von Pfaden wird stattdessen zurückgegeben. Wenn eine Komponente dieses Vektors leer ist, wird sie auf die standardmäßigen bekannten Hosts-Pfade erweitert.

Pakete, die ssh_known_hosts_files() verwenden, sollten idealerweise nach übereinstimmenden Einträgen suchen, indem sie den Hostnamen und die Schlüsseltypen vergleichen und den ersten Eintrag in einer der Dateien, der übereinstimmt, als die definitive Identität des Hosts betrachten. Wenn der Aufrufer den Schlüsseltyp nicht vergleichen kann (z. B. weil er gehasht wurde), muss er den obigen Algorithmus approximieren, indem er nach allen übereinstimmenden Einträgen für einen Host in jeder Datei sucht: Wenn eine Datei Einträge für einen Host hat, muss einer von ihnen übereinstimmen; der Aufrufer sollte nur dann weiter nach weiteren bekannten Hosts-Dateien suchen, wenn es in einer früheren Datei keine Einträge für den betreffenden Host gibt.

ssh_known_hosts_file() :: String

Die Funktion ssh_known_hosts_file() gibt einen einzelnen Pfad zu einer SSH-known-hosts-Datei zurück, die verwendet werden sollte, wenn die Identitäten von Remote-Servern für SSH-Verbindungen festgestellt werden. Sie gibt den ersten Pfad zurück, der von ssh_known_hosts_files zurückgegeben wird und tatsächlich existiert. Aufrufer, die in mehr als einer known-hosts-Datei nachsehen können, sollten stattdessen ssh_known_hosts_files verwenden und nach Hostübereinstimmungen in allen Dateien suchen, die in den Dokumentationen dieser Funktion beschrieben sind.

verify_host(url::AbstractString, [transport::AbstractString]) :: Bool

Die Funktion verify_host informiert den Aufrufer darüber, ob die Identität eines Hosts bei der Kommunikation über sichere Transportprotokolle wie TLS oder SSH überprüft werden sollte. Das Argument url kann sein:

1. eine gültige URL, die mit proto:// beginnt
2. ein ssh-Stil nackter Hostname oder ein Hostname, der mit user@ vorangestellt ist
3. ein scp-Stil Host wie oben, gefolgt von : und einem Pfad

In jedem Fall wird der Hostname-Teil herausgefiltert und die Entscheidung, ob überprüft werden soll oder nicht, basiert ausschließlich auf dem Hostnamen, nicht auf anderen Aspekten der Eingabe-URL. Insbesondere spielt das Protokoll der URL keine Rolle (mehr dazu unten).

Das Argument transport gibt an, um welche Art von Transport es sich bei der Abfrage handelt. Die derzeit bekannten Werte sind SSL/ssl (Alias TLS/tls) und SSH/ssh. Wenn der Transport weggelassen wird, gibt die Abfrage nur dann true zurück, wenn der Hostname unabhängig vom Transport nicht überprüft werden sollte.

Der Hostname wird mit den Hostmustern in den relevanten Umgebungsvariablen abgeglichen, abhängig davon, ob transport angegeben ist und welchen Wert es hat:

• JULIA_NO_VERIFY_HOSTS — Hosts, die für keinen Transport überprüft werden sollten
• JULIA_SSL_NO_VERIFY_HOSTS — Hosts, die für SSL/TLS nicht überprüft werden sollten
• JULIA_SSH_NO_VERIFY_HOSTS — Hosts, die für SSH nicht überprüft werden sollten
• JULIA_ALWAYS_VERIFY_HOSTS — Hosts, die immer überprüft werden sollten

Die Werte jeder dieser Variablen sind eine durch Kommas getrennte Liste von Hostnamenmustern mit folgender Syntax — jedes Muster wird an . in Teile aufgeteilt, und jeder Teil muss eines der folgenden sein:

1. Ein literales Domainnamenkomponente, das aus einem oder mehreren ASCII-Buchstaben, Ziffern, Bindestrichen oder Unterstrichen besteht (technisch gesehen kein Teil eines legalen Hostnamens, wird aber manchmal verwendet). Eine literale Domainnamenkomponente passt nur zu sich selbst.
2. Ein **, das null oder mehr Domainnamenkomponenten übereinstimmt.
3. Ein *, das genau eine Domainnamenkomponente übereinstimmt.

Beim Abgleichen eines Hostnamens mit einer Mustervorlage in einer dieser Variablen wird der Hostname an . in Komponenten aufgeteilt, und diese Wortfolge wird mit dem Muster abgeglichen: Ein literales Muster passt genau zu einer Hostnamenkomponente mit diesem Wert; ein *-Muster passt genau zu einer Hostnamenkomponente mit beliebigem Wert; ein **-Muster passt zu beliebig vielen Hostnamenkomponenten. Zum Beispiel:

• ** passt zu jedem Hostnamen
• **.org passt zu jedem Hostnamen in der Top-Level-Domain .org
• example.com passt nur zu dem exakten Hostnamen example.com
• *.example.com passt zu api.example.com, aber nicht zu example.com oder v1.api.example.com
• **.example.com passt zu jeder Domain unter example.com, einschließlich example.com selbst, api.example.com und v1.api.example.com

```