Przejście na zamknięte źródła: zmiany techniczne

Czym jest Cal.diy

Cal.diy to platforma do planowania spotkań o otwartym kodzie źródłowym. Zawiera pełny silnik planowania, framework sklepu z aplikacjami oraz infrastrukturę rezerwacji. To wszystko, co sprawia, że Cal.com jest tak potężnym rozwiązaniem self-hosted dla osób indywidualnych.

Usunięto komercyjne i enterprise’owe funkcje, które dotyczą tylko Cal.com jako usługi zarządzanej. Wszystkie darmowe funkcje nadal są w Cal.diy.

Co usunięto

Rozdzielenie Cal.com i Cal.diy sprowadza się do funkcji komercyjnych i enterprise. Oto, czego już nie ma w Cal.diy:

• Organizations i Teams: wielodostępowe zarządzanie organizacjami, tworzenie teamów, dostępność teamów, przepływy rezerwacji teamów, narzędzia do migracji organizacji, PBAC (kontrola dostępu oparta na uprawnieniach) oraz wszystkie powiązane endpointy API v2

• Routing Forms: cały pakiet aplikacji Routing Forms ze sklepu z aplikacjami, w tym kreator tras, akcje formularzy, okno testowe, integracja routingu z Salesforce, funkcja śledzenia routingu i obsługa kolejkowanych odpowiedzi

• Workflows: zautomatyzowany silnik workflowów (przypomnienia, follow-upy, triggery) oraz wszystkie powiązane odwołania w API v2, bibliotekach platformy i przepływach rezerwacji

• Instant Booking: natychmiastowe typy wydarzeń i cały powiązany kod usługi rezerwacji

• AI Phone: wykonywanie połączeń telefonicznych Cal.ai i zakładka typu wydarzenia AI phone

• Attributes and Segments: React Awesome Query Builder (RAQB), atrybuty członków, filtrowanie oparte na segmentach i ustawienia platformy workspace’u

• SAML/SSO: enterprise’owy flow rejestracji SAML/SSO

• Insights: dashboardy analityczne i raportowe

• API v1: cała aplikacja API v1 została usunięta. Cal.diy korzysta wyłącznie z API v2

• Enterprise UI: kreator konfiguracji licencji, pobieranie dokumentów zgodności, wskazówki EE, funkcje premium dla nazw użytkowników, strona rozliczeń admina, tłumaczenie AI, flow kupowania kredytów

• Booking Audit: logowanie audytu rezerwacji (funkcja obserwowalności dla enterprise)

• Impersonation: podszywanie się pod użytkownika admina w przepływach rezerwacji i synchronizacji kalendarza

Wszystko inne pozostaje w Cal.diy: podstawowa logika planowania, sklep z aplikacjami, przepływy rezerwacji i API v2.

Przygotowanie kodu pod Cal.diy

Aby przygotować repozytorium calcom/cal.com do przejścia na calcom/cal.diy, utrzymywaliśmy osobną gałąź w prywatnym repozytorium, która była zsynchronizowana z główną gałęzią publicznego repozytorium. Ta gałąź była punktem odniesienia, na podstawie którego identyfikowaliśmy i usuwaliśmy funkcje komercyjne przed zmianą nazwy. Porównując ją diffem, mogliśmy dokładnie zobaczyć, jaki kod trzeba było wydzielić, żeby gdy calcom/cal.com stało się calcom/cal.diy, został tylko otwartoźródłowy kod.

Używaliśmy też tej gałęzi, żeby potwierdzić, że wszystkie checki GitHub przechodziły. Zależało nam na czystym przekazaniu repozytorium, więc zanim zmiana nazwy weszła na żywo, dopilnowaliśmy, żeby CI było zielone, a codebase był w dobrym stanie, gotowy, by społeczność mogła z niego korzystać od pierwszego dnia.

Zmiana licencji: z AGPL 3.0 na MIT

Zmieniliśmy licencję Cal.diy z AGPL 3.0 na MIT.

Cal.diy to inny produkt z innym celem niż Cal.com: dać społeczności możliwie najbardziej liberalną platformę do planowania spotkań. MIT lepiej pasuje do tego celu.

Opiekunowie Cal.diy

Cal.diy jest utrzymywany przez byłych stażystów Cal.com, którzy są teraz oficjalnymi opiekunami repozytorium.

Ci inżynierowie spędzili czas w codebase Cal.com. Znają architekturę, wzorce i produkt. Dostarczali realne funkcje podczas staży, reviewowali PR-y i debugowali problemy produkcyjne.

Zespół inżynieryjny Cal.com skupia się na produkcie komercyjnym. Opiekunowie Cal.diy skupiają się na społeczności.

Zmiany w infrastrukturze

Publiczne repozytorium miało lata konfiguracji CI/CD, integracji z botami i automatyzacji DevOps. Wszystko trzeba było przebudować dla prywatnego repozytorium.

GitHub Actions

Cal.diy ma 53 workflowy GitHub Actions. Prywatne repozytorium ma 62. Dotknęliśmy niemal każdego istniejącego workflowa, żeby zaktualizować odwołania do starego repo w krokach checkoutu, URL-ach API, ścieżkach do artefaktów i hookach wdrożeniowych.

Prywatne repozytoria mają inne modele uprawnień. Kilka wczesnych PR-ów naprawiało błędy CI, bo checkout w prywatnym repo wymaga jawnych uprawnień contents: read, które publiczne repozytoria dostają domyślnie.

Sekrety i konfiguracja środowiska

Większość sekretów przechodzi bez zmian, ale kilka trzeba ponownie utworzyć dla publicznego repozytorium, na przykład dane dostępowe do test suites uruchamianych przeciwko Google i Stripe. Nowi opiekunowie wkrótce je skonfigurują, a test suites automatycznie się reaktywują, gdy zobaczą ustawienia.

Backportowanie poprawek bezpieczeństwa

Gdy oba repozytoria były utrzymywane równolegle, bezpieczeństwo było priorytetem w obie strony. Podatności łatano najpierw tam, gdzie zostały wykryte, a potem backportowano do drugiego repo. Czasami poprawka trafiała do publicznego repo i była cherry-pickowana do prywatnego. Czasami działo się odwrotnie.

Przykłady obejmują aktualizację axios do 1.15.0, żeby naprawić krytyczne CVE, aktualizację handlebars do 4.7.9, żeby usunąć krytyczną podatność, blokowanie adresów localhost i loopback w ochronie przed SSRF, dodanie ochrony CSRF do callbacków OAuth przez nonce podpisywane HMAC, zapobieganie IDOR w endpointach tRPC oraz naprawę błędów audytu bezpieczeństwa fast-xml-parser.

Naszym celem było przekazać Cal.diy społeczności w solidnym stanie z perspektywy bezpieczeństwa. To oznaczało traktowanie publicznego repo jak produkcyjnego codebase’u, a nie czegoś na marginesie, nawet gdy komercyjny produkt był budowany w prywatnym repo.