crates.io-Entwicklungsupdate

 (blog.rust-lang.org)
1 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • In den vergangenen sechs Monaten hat crates.io einen Quellcode-Viewer eingeführt, mit dem sich veröffentlichte Pakete direkt prüfen lassen, außerdem ein von GitHub unabhängiges Kontosystem eingeführt und Hinweise zu Sicherheit sowie zum Ersatz durch die Standardbibliothek ausgebaut
  • Der neue Tab Code unterstützt Dateisuche, Syntax-Highlighting und teilbare Zeilenauswahl; über ZIP- und JSON-Manifeste im CDN sowie HTTP-Range-Requests werden nur die benötigten Dateien geladen, ohne den API-Server zu belasten
  • Gemäß RFC #3946 wurde mit der Implementierung von eigenen crates.io-Benutzernamen begonnen; nach Unterstützung für Benutzernamensänderungen und einer Sicherheitsprüfung sollen künftig auch andere Authentifizierungsanbieter als GitHub unterstützt werden
  • Das Frontend wurde vollständig von Ember.js auf Svelte migriert; auch Suche, Reverse-Dependency-Abfragen, CDN-Caching und die Verarbeitung des Git-Index wurden im Sinne von mehr Performance und Stabilität verbessert
  • Auf Paketseiten werden nun RustSec-Warnungen bei eingestellter Wartung sowie Ersatz-APIs der Standardbibliothek wie std::sync::LazyLock angezeigt, um Dependency-Audits und das Entfernen unnötiger Abhängigkeiten zu unterstützen

Quellcode-Viewer zum Prüfen veröffentlichter Pakete

  • Im neuen Tab Code auf der Paketseite lassen sich die Dateien jeder veröffentlichten Version direkt in crates.io durchsuchen
    • Gezeigt werden nicht verknüpfte Repositories, sondern genau die Dateien, die cargo beim Hinzufügen einer Abhängigkeit tatsächlich herunterlädt
    • Dadurch lassen sich auch Dateien prüfen, die im Repository nicht vorhanden sind, etwa das von cargo erzeugte normalisierte Cargo.toml, was Dependency-Audits erleichtert
  • Der Viewer unterstützt Suche im Dateibaum, Syntax-Highlighting und Zeilenauswahl nach GitHub-Art
    • Durch Klicken oder Ziehen über Zeilennummern wird eine teilbare URL im Format #L10-L20 erzeugt
  • Der Server erzeugt für alle veröffentlichten Versionen ZIP-Dateien und ein JSON-Manifest, das die Dateistruktur beschreibt
    • Da die von cargo verwendeten .crate-Dateien gzip-komprimierte Tarballs ohne wahlfreien Zugriff sind, werden sie in einem Hintergrundjob erneut als durchsuchbare ZIPs verpackt
    • ZIPs und Manifeste werden über ein statisches CDN ausgeliefert
    • Das Frontend lädt zunächst das Manifest und ruft einzelne Dateien nur bei Bedarf per HTTP-Range-Request ab
    • Die Quellcode-Navigation erzeugt dadurch praktisch keine zusätzliche Last auf dem crates.io-API-Server; auch bestehende Versionen wurden gesammelt nachverarbeitet, sodass selbst alte Releases unterstützt werden
  • Die Rendering-Bibliothek des Code-Viewers ist ursprünglich ein Diff-Renderer; auf derselben Infrastruktur basiert auch ein in Entwicklung befindlicher Vergleichs-Viewer zwischen Versionen
    • Nach Fertigstellung lassen sich die exakten Änderungen zwischen zwei veröffentlichten Versionen direkt auf crates.io prüfen

Von GitHub unabhängige crates.io-Konten

  • Das crates.io-Team hat Ende Mai RFC #3946 angenommen
  • Bisher waren GitHub-Login und crates.io-Identität eng gekoppelt, auch der Benutzername wurde durch das GitHub-Konto bestimmt; die RFC führt nun einen eigenen crates.io-Benutzernamen ein, der von verknüpften Konten unabhängig ist
  • Dieser eigene Benutzername ist eine Voraussetzung dafür, künftig Logins über andere Authentifizierungsanbieter als GitHub zu unterstützen
  • Mit der Implementierung wurde begonnen, aber als wesentliche noch unfertige, sichtbare Funktion fehlt die Änderung des Benutzernamens
    • Nach Abschluss dieses Teils sollen weitere RFCs und die Umsetzung für Logins über andere Authentifizierungsanbieter folgen
    • Da dies direkte Auswirkungen auf Authentifizierung und Kontosicherheit hat, erfolgt die Auslieferung langsam in kleinen, sorgfältig geprüften Schritten

Sicherheitshinweise und Verweise auf Ersatz in der Standardbibliothek

  • Der bestehende Tab Security zeigt Sicherheitswarnungen aus der RustSec-Datenbank; bei Paketen, die RustSec als nicht mehr gepflegt markiert, erscheint nun zusätzlich oben auf der Seite ein Warnbanner
    • Über das Banner gelangt man zum entsprechenden Advisory mit Details und möglichen Alternativen
  • Bei Paketen, deren Funktionalität in die Standardbibliothek übernommen wurde, erscheint ein Banner mit „You might not need this dependency“
    • So kann lazy_static seit Rust 1.80 durch std::sync::LazyLock ersetzt werden
    • In der Dependency-Liste erhalten ersetzte Pakete zudem ein kleines Glühbirnen-Symbol mit demselben Hinweis
  • Die zugehörigen Daten werden im neuen Repository rust-lang/std-replacement-data verwaltet
    • Zugelassen sind nur Einträge zu Ersetzungen durch die Standardbibliothek
    • Jeder Eintrag muss auf stabilisierte APIs aus std, core oder alloc sowie auf die entsprechende Rust-Version verweisen
    • Bevor ein Eintrag hinzugefügt wird, werden die Maintainer des Pakets informiert und erhalten Zeit für Rückmeldungen
    • Neue Einträge können dem Repository vorgeschlagen werden; die gesammelten Daten lassen sich auch in anderen Tools nutzen

Migration des Svelte-Frontends abgeschlossen

  • Das Experiment zur Umstellung des crates.io-Frontends von Ember.js auf Svelte wurde erfolgreich abgeschlossen
    • Das neue Frontend hat funktional Gleichstand mit dem bisherigen erreicht
    • Nach einem öffentlichen Test im April wurde es Anfang Mai zum Standard-Frontend
    • Die Ember.js-Anwendung wurde aus dem Repository entfernt
  • Es handelte sich um eine 1:1-Migration, bei der bestehendes Design und bestehende Funktionen unverändert übernommen wurden, damit Nutzer möglichst keine Umstellung bemerken
  • Team und Beitragende können nun mit einem modernen Framework arbeiten, die Einstiegshürde für neue Mitwirkende senken und iterativ schneller entwickeln; der Quellcode-Viewer ist ein Beispiel dafür
  • Es wird sowohl dem Ember.js-Team, das crates.io über viele Jahre begleitet hat, als auch dem Svelte-Team für die Unterstützung beim Wechsel gedankt

Ferris-Fehlerseite

  • Ferris auf den Fehlerseiten von crates.io folgt nun dem Mauszeiger mit den Augen
  • Auch die 404-Fehlerseite bietet eine kleine Interaktion

Performance von Suche und Reverse-Dependency-Abfragen

  • Bei der Suche nach Relevanz wurde zuvor der Rang aller Pakete berechnet, die zum Suchbegriff passten; bei kurzen oder häufigen Begriffen konnte das 1 bis 2 Sekunden dauern
    • Jetzt wird die Rangberechnung auf die 1.000 passenden Pakete mit den meisten jüngsten Downloads begrenzt
  • Der Endpoint für Reverse Dependencies berechnet bei jeder Anfrage nicht mehr die komplette Menge abhängiger Pakete neu
    • Die Ergebnisse kommen aus einer vorberechneten Tabelle, die per Datenbank-Trigger synchronisiert wird
    • Aufwendige Joins wurden durch begrenzte Index-Scans ersetzt, was das Risiko von Timeouts deutlich senkt

Architektur-Dokumentation und Markdown-Rendering

  • ARCHITECTURE.md wurde umfassend überarbeitet und konzentriert sich nun auf die übergeordneten Systeme von crates.io und ihr Zusammenspiel
    • enthalten sind die Verarbeitungsschritte bei cargo publish
    • außerdem die Gründe, warum ein normaler Paketdownload nicht über den API-Server läuft
    • sowie die Methode, mit der Download-Zahlen aus CDN-Zugriffslogs berechnet werden
  • Das README rendert nun Definitionslisten als verbreitete Markdown-Erweiterung
    • Der Markdown-Renderer comrak unterstützte Definitionslisten bereits, die Erweiterung war jedoch nicht aktiviert

Verbesserte Effizienz des CDN-Caches

  • Dateien, die auf das statische CDN hochgeladen werden, erhalten nun Metadaten mit Cache-Tags
    • Statt für jede Datei-URL einzeln eine Invalidierungsanfrage zu senden, lassen sich alle Cache-Dateien eines bestimmten Pakets oder Releases auf einmal invalidieren
  • Der globale Response-Header Vary: Cookie, der CDN-Caching für öffentliche API-Antworten und Frontend-Assets behinderte, wurde entfernt
    • Für benutzerspezifische Antworten wird stattdessen Cache-Control: no-store gesetzt
    • Dadurch hat sich die Cache-Hit-Rate an den CDN-Edges verbessert

Barrierefreiheit und Verarbeitung des Git-Index

  • Die Barrierefreiheit von crates.io wurde für Nutzer von Screenreadern verbessert
    • dekorative Icons werden im Accessibility-Tree ausgeblendet
    • die Überschriftenhierarchie wurde korrigiert
    • Listen verwenden nun korrektes Listen-Markup
    • ARIA-Snapshot-Tests wurden eingeführt, um unbemerkte Regressionen zu verhindern
    • In den kommenden Monaten soll die Barrierefreiheit weiter verbessert werden
  • Die lokale Kopie des Git-Index in den Background-Workern wurde auf ein bares, flaches Repository umgestellt
    • Dadurch entfallen etwa 250.000 ausgecheckte Dateien und die komplette Commit-Historie auf der Festplatte
    • Das verbessert die Verarbeitung bei steigender Veröffentlichungsfrequenz von Paketen
  • Für das periodische Squashen des Index wird nun die GitHub-API verwendet, statt lokal große Git-Packs zu erzeugen
    • Die frühere lokale Pack-Erzeugung hatte auf Produktions-Workern bereits zu Out-of-Memory-Problemen geführt

Feedback-Kanäle

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 시간 전
Meinungen auf Lobste.rs

  • Es ist erfreulich, dass daran gearbeitet wird, crates.io-Konten von GitHub zu entkoppeln

    • Früher mochte ich es, mich bei verschiedenen Diensten mit einem GitHub-Konto anmelden zu können, aber inzwischen wirkt das weniger attraktiv. Tailscale unterstützt OIDC-Identitätsanbieter, daher habe ich es so eingerichtet, dass ich mich über Codeberg und WebFinger meiner eigenen Domain anmelden kann.
      Um sich mit der E-Mail-Adresse der eigenen Domain example@example.com anzumelden, legt man unter https://example.com/.well-known/webfinger eine JSON-Datei ab, deren subject acct:example@example.com ist und deren OpenID-Connect-Issuer-href auf https://codeberg.org verweist.
      In den Codeberg-Einstellungen erstellt man dann eine OAuth2-Anwendung mit der Redirect-URI https://login.tailscale.com/a/oauth_response und trägt die ausgegebenen Client ID und Client Secret bei Tailscale ein. crates.io dürfte künftig wohl einen ähnlichen Weg anbieten.

  • Mir war nicht bewusst, wie groß die jüngsten Verbesserungen bei crates.io sind. Normalerweise suche ich zuerst auf lib.rs, aber vielleicht ändert sich diese Gewohnheit bald; die Veränderung, die mir am besten gefällt, ist Ferris.

    • Ich frage mich, wie viel von diesen Verbesserungen der Einführung von Agents zu verdanken ist.

  • Die Veränderung an Ferris’ Augen ergibt physikalisch nicht wirklich Sinn. Die weißen Stellen in den schwarzen Augen sind spiegelnde Highlights; wenn der Mauszeiger die Lichtquelle wäre, ließe sich das kaum als Darstellung deuten, bei der die Augen dem Cursor folgen.

  • Wenn ich Abhängigkeiten auditiere, verlinke ich zuerst ~/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/ per Symlink nach ~/cargosrc, damit ich leichter auf die von Cargo heruntergeladenen Dateien zugreifen kann.
    Für jede zu prüfende Abhängigkeit klone ich das Git-Repository, checke die Zielversion aus, lösche lokal die getrackten Dateien und sende dem rust-analyzer-Prozess SIGSTOP. Dann füge ich die Abhängigkeit in der Cargo.toml des Projekts hinzu, führe cargo fetch aus, kopiere den Inhalt des heruntergeladenen Verzeichnisses $dependency-$version in das geklonte Repository, committe ihn und prüfe die Unterschiede in einem Git-History-Viewer.
    Nach der Prüfung speichere ich die Kombination aus Abhängigkeit, Version und Hash aus Cargo.lock per Skript in einer vertrauenswürdigen Datenbank, damit ich dieselbe Version nicht noch einmal prüfen muss. Auch wenn der Ablauf kompliziert aussieht, habe ich das meiste automatisiert, sodass es effizienter ist als eine Web-UI. Es wäre schön, wenn Cargo einen solchen Review-Prozess auf der Kommandozeile unterstützen würde. Außerdem frage ich mich, ob es neben Tools wie cargo-crev Plugins gibt, die den Review selbst unterstützen.

  • Die Implementierung, bei der das Frontend zunächst nur das Manifest lädt und die einzelnen Dateien dann bei Bedarf per HTTP-Range-Requests nachlädt, findet sich hier; sie verwendet den im Browser integrierten DecompressionStream.