Konto GitHub Po Śmierci: Kod, Dostęp I Sukcesja
Konto GitHub po śmierci to więcej niż login. Może zawierać publiczne repozytoria, prywatny kod, prawa publikacji pakietów, GitHub Actions, sekrety, strony Pages, organizacje, issues, wydania i reputację zawodową.
Celem nie jest więc zdobycie hasła. Celem jest utrzymanie ważnej pracy jako dostępnej, zarządzanej i bezpiecznej.
GitHub pozwala zaprosić innego użytkownika jako następcę. Po śmierci właściciela następca może zarządzać publicznymi repozytoriami. Pomaga to zachować, zarchiwizować lub przenieść osobiste projekty open source.
Nie jest to jednak pełne dziedziczenie konta. GitHub mówi, że następca nie ma dostępu do prywatnych repozytoriów, ustawień, informacji osobistych ani organizacji, jeśli nie miał już uprawnień.
Rodziny nie powinny więc planować przejęcia przez hasło. Prywatne repozytoria mogą zawierać kod klientów, sekrety, podatności lub informacje umowne. Lepsze pytanie brzmi: co ma się stać z pracą?
Osobiste repozytoria są kruche, gdy ważny pakiet lub narzędzie zależy od jednego konta. Następca pomaga w części publicznej, ale poważne projekty wspólne lepiej umieszczać w organizacji.
GitHub zaleca także ciągłość własności organizacji. Praktycznie oznacza to co najmniej dwóch zaufanych właścicieli, jasne role, rozliczenia, ustawienia bezpieczeństwa i procesy release.
Znaczenie ma też uwierzytelnianie dwuskładnikowe. GitHub wyjaśnia, że dostęp można utracić bez danych 2FA lub metod odzyskiwania. Omijanie 2FA nie powinno być planem spadkowym.
Cyfrowy inwentarz programisty powinien wymieniać ważne repozytoria, właścicieli, maintainerów, rejestry pakietów, domeny, sekrety CI, klucze podpisu i kroki wydania.
Po śmierci rodzina powinna najpierw zmapować widoczne konto: publiczne repozytoria, profil, strony i organizacje. Jeśli jest następca, powinien użyć procesu GitHub. Jeśli nie, upoważniony przedstawiciel lub zweryfikowany członek rodziny może skontaktować się z GitHub.
Nie usuwaj publicznych projektów w pośpiechu. Kod może być częścią dziedzictwa i zależnością dla innych.
Najlepszy plan to organizacje, wielu właścicieli, wskazany następca, udokumentowane release i zabezpieczone rejestry pakietów. Wtedy kod może przeżyć autora bez ujawniania prywatnej pracy.