Readthedocs.org: Ungültige Submodul-URL in öffentlichen Repositorys

Erstellt am 1. Mai 2018  ·  3Kommentare  ·  Quelle: readthedocs/readthedocs.org

Vor einiger Zeit haben wir diesem Commit als Sicherheitsschritt einen Submodul-URL-Validator hinzugefügt: https://github.com/rtfd/readthedocs.org/commit/43de909b5. Wir erlauben verschiedene URL-Schemata und schützen uns vor denen, die wir nicht unterstützen möchten.

Bei einem Blick auf Sentry-Fehlerberichte habe ich festgestellt, dass es einige Projekte gibt, die _ungültig_ (für unsere Regeln) [email protected] Submodul-URLs für öffentliche Repositorys haben, die aufgrund unserer Regeln fehlschlagen.

Diese Projekte sind zum Beispiel:

Wir haben dies als ungültige Repos markiert, da wir nicht sicher sein können, ob sie öffentlich sind, aber möglicherweise benötigen wir einen zusätzlichen Schritt, bevor wir sie als ungültig markieren. Ich bin mir nicht sicher, aber ich öffne dieses Thema, um zumindest die Diskussion zu beginnen.

Andererseits ist das einzige Feedback, das wir dem Benutzer geben,

Eine oder mehrere Submodul-URLs sind ungültig

die, ohne die Regeln zu kennen, sehr schwer zu erkennen ist, dass Sie die HTTPS-Version der Submodul-URL benötigen, damit sie funktioniert.

Ich glaube auch nicht, dass wir unsere Benutzer zwingen wollen, die HTTPS-Version der Submodul-URL zu verwenden (je nach Verwendung des Moduls ist dies kein guter Workflow für die Entwickler).

Verwandt:

Wachpostenproblem: https://sentry.io/read-the-docs/readthedocs-org/issues/502672091/events/latest/

design decision
Quelle
picture humitos

Hilfreichster Kommentar

Hallo, ich hatte gerade ein ähnliches Problem, bei dem RTD berichtete:

Eine oder mehrere Submodul-URLs sind ungültig.

Ich brauchte eine Weile, um herauszufinden, dass es daran lag, dass das Submodul eine SSH-URL hatte - tatsächlich wollte ich ein Problem einreichen. Ich habe es auf HTTPS umgestellt und das Problem war weg.

Ich denke, die Botschaft ist nicht ganz klar. Es wäre auch schön, wenn das RTD-Handbuch diese Einschränkung beschreiben würde (ich habe versucht, nach "Submodulen" zu suchen, und es kommt nichts.)

picture jcarrano am 7. Dez. 2018
👍3

Alle 3 Kommentare

Wir könnten die ungültige URL hier https://github.com/rtfd/readthedocs.org/blob/dfc8fc9eba8dc9caae171ca0b3e8f6a71594e088/readthedocs/vcs_support/backends/git.py#L117 -L121 zurückgeben und gezeigt, dass dies zumindest besser ist Hinweis.

Ich glaube auch nicht, dass wir unsere Benutzer zwingen wollen, die HTTPS-Version der Submodul-URL zu verwenden (je nach Verwendung des Moduls ist dies kein guter Workflow für die Entwickler).

Ich denke das gleiche, gibt es eine Möglichkeit, dass Benutzer das übertreten können? Ich meine, wenn wir ihre privaten Schlüssel nicht haben, können wir ihren Code nicht abrufen.

stsewd picture stsewd am 26. Okt. 2018
👍1

Hallo, ich hatte gerade ein ähnliches Problem, bei dem RTD berichtete:

Eine oder mehrere Submodul-URLs sind ungültig.

Ich brauchte eine Weile, um herauszufinden, dass es daran lag, dass das Submodul eine SSH-URL hatte - tatsächlich wollte ich ein Problem einreichen. Ich habe es auf HTTPS umgestellt und das Problem war weg.

Ich denke, die Botschaft ist nicht ganz klar. Es wäre auch schön, wenn das RTD-Handbuch diese Einschränkung beschreiben würde (ich habe versucht, nach "Submodulen" zu suchen, und es kommt nichts.)

jcarrano picture jcarrano am 7. Dez. 2018
👍3

mit https als Schema für Submodule zu arbeiten ist nicht ideal. Könnten die URLs umgewandelt werden (wie die referenzierenden Commits in dieser Ausgabe), bevor die Submodule Klone sind?

funkyfuture picture funkyfuture am 16. März 2019
War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

SylvainCorlay picture SylvainCorlay  ·  3Kommentare
pllim picture pllim  ·  3Kommentare
gtalarico picture gtalarico  ·  4Kommentare
jaraco picture jaraco  ·  4Kommentare
humitos picture humitos  ·  4Kommentare