Öppen källkod-hantering

Status	OPEN
Impact	HIGH
Driver	ola.enebro (Unlicensed)
Approver	Per Persson
Contributors	Martin Hansson (Unlicensed)
Informed
Due date	30 Sep 2022
Resources
Outcome

\uD83D\uDCD8 Bakgrund

I Confluence finns en övergripande beskrivning för hur vi kan hantera öppen källkod inom Sundsvalls kommun i allmänhet och Utvecklingsfabriken i synnerhet. Dock finns några viktiga beaktanden att göra när det kommer till hur vi delar källkoden (med tillbehör) öppet. Se uppställning nedan.

En annan viktig frågeställning vi behöver ta ställning till är för vilket syfte vi ska tillgängliggöra källkoden för våra tjänster.

Att tillgängliggöra koden för att andra ska kunna bidra i utvecklingen enligt klassisk open source-modell.
Att vi delar med oss av det färdiga resultatet av respektive tjänst vi vill dela med oss av. Dock på ett sånt sätt att vi kan begränsa vad som delas publikt för att säkerställa att känsliga uppgifter inte sprids.

🤝 Beroenden

Oavsett alternativ som väljs behöver Utvecklingsfabrikens SpringBoot-ramverk (a.k.a. Dept44) finnas publikt tillgängligt för den som vill bygga något utifrån den öppna källkoden. Bör inte vara några konstigheter.

\uD83C\uDF08 Alternativ

Option 1

Option 2

Helt öppet Vi låter våra repositories i GitHub vara helt öppna och publika. Självklart att vi då lägger känsliga uppgifter, i den mån det går, som lösenord etc i separat konfigurationsrepo i GitLab. Och vi låter naturligtvis inte vem som helst att committa in saker till ett publikt repository.

Privat & publikt Vi skiljer på publikt och privat genom att ha separata repositories där kod från det privata på lämpligt sätt kan speglas till det publika. O-öppet alltså. Vi jobbar i privata repositoryn, varifrån vi även bygger och deployar. Det är ett aktivt val att “publicera” kod från ett privat till publikt repository.

Känsliga uppgifter återfinns i GitLab och de som inte kan finnas där ska kunna filtreras bort i samband med publicering till publikt repository.

Kan merge från main till en branch som heter “public” i det privata repositoryt vara det som något ett jobb i Jenkins ska gå på för att kunna skyffla rätt saker (mha shallow clone etc) till det publika repositoryt?

Pros/cons

Enkelt. Det vi pushar in till GitHub blir tillgängligt för alla.

Varje enskild utvecklare behöver vara noggrann och se till att oönskad information inte kommer med då det är begränsat med kontrollfunktioner innan något de facto hamnar i repot. Mänskliga faktorn kan spela in.

Risk att personuppgifter (framförallt i testdata) slinker med och blir publika.

Risk att keystores med certifikat slinker med och blir publika.

⚠️ Potentiellt hög säkerhetsrisk om känslig information slinker med.

Möjlighet att begränsa vilka delar av det privata repositoryt som speglas ut till det publika. Se exempelvis https://github.com/open-condo-software/gitexporter

Möjlighet att förhindra att oönskad historik kommer med med hjälp av “shallow clone” då det enbart är skillnaden mellan respektive “publicering” som är önskvärd i det publika repositoryt. Minskar risk för att “fulkod” kommer med (även om vi naturligtvis aldrig fulkodar något, någonsin…).

Möjlighet att automatisera (förslagsvis via Jenkins) publicering till publikt repository, även om det bör vara ett aktivt val att faktiskt göra det. Det här steget möjliggör också att införa kontroller för att förhindra att oönskad information slinker med.

Mer komplex uppsättning.

Kräver dubbla repositoryn.

Oklart hur arbetsflödet bäst sätts upp för att åstadkomma detta.

⚠️ Kräver ändå att det privata repositoryt sätts upp på rätt sätt så att känslig information ska kunna filtreras bort på ett vettigt sätt.

✅ Action items

Vad blir följden av att personnummer eller personuppgifter “läckt”? Viten?
För varje certifikat vi har måste vi ha färdiga rutiner för att invalidera och beställa nya certifikat.

\uD83C\uDF1F Outcome

Ja, vad blev det?