Microsoft hoeft tenminste niet bij Canonical aan te kloppen voor beveiligings advies.

Ik zou denken:laat Github links liggen en gebruik gewoon Laumchpad. Of iets anders, zoals een eigen Gitlab instantie. Kan je zelf over je data beschikken.

Maar gelukkig heeft GitHub niks te maken met de security van Ubuntu zelf. Want die is nog steeds dik in orde. Ik krijg nog steeds regelmatige veiligheidsupdates... ;-)

Het uitlekken van een account (iets dat je weet) heeft weinig met een os van doen.

Als je dat toch wil.... Git github is op linux gebaseerd. Het heeft alle beperkingen en eigenschappen met de kwetsbaarheden van dat os.

Blijf jij voorlopig nog maar anoniem :-)

Geen 2FA? Of ssh key (zonder wachtwoord) uitgelekt?

Het ging in deze om privé code, niet om de code die door Canonical gebruikt wordt.
Een storm in een glas water dus..........

Grappig dat je alleen (software voor) websites noemt om code mee te beheren en niet de onderliggende versiebeheersoftware, zoals git en bij launchpad ook bazaar. Die op zich bieden al de faciliteiten voor gedistribueerde softwareontwikkeling. Wat jij noemt zijn toevoegingen op een basis die zelf ook functioneert.

Maar omdat github op git gebaseerd is heeft iedereen die aan zo'n project meedoet al een eigen kopie van de repository. Ook met een centrale repository is het geheel nog steeds gedistribueerd. Git heeft goede mogelijkheden om op basis daarvan te controleren of er gerommeld is op de centrale repository en om eventuele schade weer te herstellen. Dat een account is gekaapt is niet best, en dat zouden ze zeker beter moeten beschermen. Github ondersteunt 2FA, dit doet vermoeden dat het niet werd gebruikt. Ze hoeven niet te stoppen met Github, ze moeten het goed gebruiken.

Klopt.
Dat leest alsof je denkt dat software die op een OS draait het OS bevat. Git draait op meerdere OS'en, inclusief Windows. Als je git op OS/X of FreeBSD draait neem je echt geen kwetsbaarheden van Linux mee naar die OS'en.

Hij heeft gewoon niet begrepen dat GitHub om broncode en versiebeheer draait (en in dit geval was het niet eens de broncode van Ubuntu maar privécode van een Ubuntu-ontwikkelaar). Bovendien is Git helemaal niet 'op Linux gebaseerd'. Het is gewoon een versiebeheerapplicatie, niet meer en niet minder.

Precies: sleutelbeheer is in tal van verschijningsvormen (fysiek, digitaal) blijkbaar nog geen opgelost probleem.

Hehe :-)
Git (tool) != GitHub (dienst), maar
GitHub == Microsoft - https://blogs.microsoft.com/blog/2018/10/26/microsoft-completes-github-acquisition/

Ook al was dit privé code, het zegt wel iets over hoe deze programmeur met wachtwoorden omgaat. En waarschijnlijk geen 2FA gebruikt.

Ga je even verdiepen in wie git gemaakt heeft, wat het doel is, de cliënt interface met de local repository en de remote koppeling. Alternatief is Atlassian bit bucket zeer populair.

Ga even leren nadenken. Dat Linus zowel Linux als Git heeft bedacht betekent natuurlijk nog niet dat er verder ook maar enig verband is tussen die twee. Oh wacht, je bent aan het oefenen met de termen causatie en correlatie? Nee, dan nog steeds niets.


Geweldig...

Precies. Git kan op elk platform draaien. Zoals deze gitserver voor windows: https://bonobogitserver.com. En je hebt ze ook voor het apple platform. Het is maar voor welk platform je de code compileert.

Hoe zie je dat als onderbouwing dat git op Linux gebaseerd is? Nee, laten we even een stapje terug doen: wat bedoel je eigenlijk hiermee?
Dat klinkt alsof broncode van de Linuxkernel in de broncode van git verwerkt is. Is dat wat je denkt of bedoel je iets anders?

Dit is de manual https://git-scm.com/docs/git-push Let even op hoe er met de credentials om gegaan wordt, welke commando's en directory structuur er wordt gebruikt. Nog interessanter wordt het als je de vraag gaat stellen wat de autorisatie van de destinations files inodes moet zijn. De wijze hoe een en ander beveiligd moet worden ontbreekt volledig.

Je krijgt de kwetsbaarheden mee van de het systeem waarde master staat.
Daar gaat het artikel over met een gekaapt account.

Als je iets gecontroleerd wilt uitrollen met een strikte beveiliging dan ontbreekt dat. Je gaat dan naar andere producten waarbij er shared generieke service accounts wegens het gemak, snel klaar zijn met uitrollen. Dat is niet conform de gangbare security richtlijnen ISo27k en BIO.


Een goede inhoudelijke vraag. Nee het gaat met niet om de broncode van de kernel, die is niet relevant.

Als je applicaties maakt voor een een bedrijf wil je dat die en beheersbaar en veilig zijn. Dan maak ik nog een onderscheid in tools (geen gevoelige bedrijfsgegevens) en de bedrijfsapplicaties welke veel specifieker met meer lagen zijn.. Door monitoring en logging op meerdere manieren bij.
Dat is veel meer dan een "hello workd" thuis hobby iets of een projectverslag dat als binair iets voor de wereld gepubliceerd wordt. Dat laatste lijkt meer op een website rijksoverheid dan wel https://www.ibabs.eu/nl/

https://nl.atlassian.com/ jira (scrum agile werken veranderingen change management ) confluence (documenteren overleggen) zijn populaire tools. Het verbaast me dat zo onbekend is bij de reaguurders.
Dan is deze limiet nog onbekender https://confluence.atlassian.com/bitbucket/what-kind-of-limits-do-you-have-on-repository-file-size-273877699.html maar 1 GB? Er zit iets van een 32-bit iets in.
https://help.github.com/en/articles/what-is-my-disk-quota ook die 1Gb en zelfs minder tot 100Mb.
Waarom zou je 100Gb of Tera's willen opslaan in een repo? Datascience de data is de werkelijke source. Hoe zou je dat moeten archiveren voor review-auditing. 40Gb voor de training/validation is nog vrij weinig.

@karma4 Je hebt eerst dit geschreven en dat hele irrelevante epistel dat je hierboven produceert (https://www.security.nl/posting/616128#posting616310) verduidelijkt noch onderbouwt ook maar iets van jouw eerste uitspraak. Ergo pure draaierij en spindoctoring, zoals gewoonlijk, omdat je beseft dat je fout zit en iets moet verzinnen om zoveel mogelijk gezichtsverlies te voorkomen. Niet gelukt, dat laatste.

Je hebt niet goed gelezen. Onder de kop "GIT URLS" staat:
Niemand die enigzins bij zijn verstand is gebruikt native transport voor push. Het meest gangbaar is om ssh te gebruiken, waarmee de authenticatie van de user geregeld is op dat niveau. Git kent verder credential helpers en Microsoft biedt er een voor Windows, zodat de Windows-authenticatiemechanismen ook gebruikt kunnen worden.

De autorisatie op de repository op de server koppel je op *nix-achtige systemen die je via ssh openstelt aan een groep waar de betreffende users lid van zijn. Deze users voorzie je niet van bash maar van een speciale niet-interactieve shell (git-shell, die wordt standaard meegeleverd) die enkel de git-acties voor zenden en ontvangen ondersteunt en al het andere afschermt. Je kan de repository configureren om alleen "fast-forward"-commits te accepteren, zodat deze users geen branches kunnen vervangen, ook niet met de optie --force. En dan zijn er ook nog "hooks" waarmee je aan acties op de server extra controles kan toevoegen. Daarmee is bijvoorbeeld een repository op te zetten die alleen maar commits accepteert die met GPG digitaal ondertekend zijn door bekende ontwikkelaars. Heel vergelijkbaar met de user exits die ik bij diverse mainframepakketten heb meegemaakt, en ook daar wel eens gebruikt heb om autorisatiecontroles die niet out-of-the-box werden ondersteund te implementeren.

Beveiliging ontbreekt niet volledig, git dwingt je alleen niet om het op een specifieke manier te doen maar faciliteert meerdere benaderingen conform de unix-filosofie: maak een programma dat één ding goed doet en zet het zo op dat het goed gecombineerd kan worden met programma's die andere aspecten van het totaal afhandelen. Met andere woorden: git is geen totaaloplossing maar een bouwsteen die niet alles zelf implementeert maar het evenmin blokkeert.

Wie wel een totaaloplossing wil kan misschien beter voor iets anders kiezen (mogelijk iets dat op git gebaseerd is en een aantal keuzes heeft voorgebakken). Het voordeel van git's benadering is dat het moelijk zal zijn om een workflow te bedenken waar het niet goed in te passen is.

Een evangelist zou ik zijn blauwe ogen moeten geloven? Eerder het omgekeerde laat hem maar met de echte onderbouwing komen. Daar heb je enkel constant faals zijn produceren met de persoonlijke aanval. Niet best als onderbouwing.

Dank je, je zegt feitelijk at je afhankelijk van dat achterliggende OS. Alleen zal zo'n SSH benadering weer de bekende achilleshiel in de home ofwel userprofile opleveren. Nog vervelender wordt het met dat inichten van zo'n restricted shell. Het zal niet makkelijk in het publieke domein zijn. Allemaal persoonlijke account zichtbaar op het OS. De weerstand vanuit Linux beheer is vrij groot. Het gangbare antwoord "dat moet de applicatie maar oplossen". Maak er een LDAP clustering van en heb je hebt een feestje.

Ik stuurde hier een beetje op aan. Daarom had ik die analytics vraag training validation ook genoemd. Het is de omgeving waar de shell en meer gewoon gefrustreerd wordt door Linux beheerders omdat het gebruik van een shell als gevaarlijk betiteld wordt. Wat houvast voor de gangbare vragen:
9.2.3 Management of privileged access rights
9.4 System and application access control
9.4.4 Use of privileged utility programs
9.4.5 Access control to program source code
12.5.1 Installation of software on operational systems
14.2.1 Secure development policy

Het wordt vaak wel als de totaaloplossing gebracht. Zet git naar en uw versiebeheersprobleem is opgelost.

Overigens:
- Je hebt dat gedoe met de maximale size niet opgepakt
- Ik mis van je een security model patroon hoe je applicaties vanuit git inricht, specifiek linux.
- Ik vergelijk het even met Panvalet Rational Endevor en RACF ACF2 via de SAF calls. Niet iets waar een bedrijf op zit te wachten om overal hooks met exits in te richten. Te kostbaar om te maken en te onderhouden.
De vraagstelling tussen doelgebruik en de techniek gaat te vaak mis in misvattingen.

Jij komt met de onzin Als je dat toch wil.... Git github is op linux gebaseerd. Het heeft alle beperkingen en eigenschappen met de kwetsbaarheden van dat os.

Toon maar aan dat dit geen klinkklare onzin is en anders zwijg!

Al lang gebeurt door anoniem 09:40 hierboven. Het zou gaan als je eerst goed over de onderwerpen nadenkt voor je wat post.

ROFL Je gelooft werkelijk dat wat daar is geschreven bevestigt wat jij stelt met Als je dat toch wil.... Git github is op linux gebaseerd. Het heeft alle beperkingen en eigenschappen met de kwetsbaarheden van dat os. ?

Zoals elk programma faciliteiten gebruikt die het OS biedt. Dacht je dat programma's die iets over het netwerk doen allemaal hun eigen IP-stack meeslepen? Of dat programma's die data opslaan allemaal hun eigen filesysteem implementeren? Echt niet.
Als dat een probleem is is ssh wellicht niet de optie die voor een specifieke repository gekozen moet worden. Nogmaals: er is keuze en het is configureerbaar.
Die restricted shell wordt, zoals ik schreef, kant en klaar meegeleverd. Een shell aan een user koppelen is een kleinigheid.
Op een server die voor dat doel is ingericht. Dat is geen probleem. XS4ALL heeft er geen enkele moeite mee om voor een kwart miljoen klanten een account op de shellservers te maken voor ssh-toegang, om maar een voorbeeld te noemen. Ze hebben daar vast werk bespaard door iets te automatiseren. En als je ssh niet de goede oplossing vindt gebruik je een voor jou beter werkende benadering.
Kennelijk ben jij beheerders gewend die niet bereid zijn een server in te richten voor de applicatie waarvoor die ingericht moet worden. Ik ben gewend dat beheerders hun taken wel serieus nemen.
Het is de bouwsteen die het versiebeheer doet. Wie op basis van de uitspraak "...en uw probleem is opgelost", wie die uitspraak ook doet, een pakket selecteert zonder zelf te onderzoeken of het wel bij zijn eisen en wensen aansluit is totaal onprofessioneel bezig. Werk jij in organisaties die wél uitgebreid aan ISO-normeringen voldoen maar totaal níét nadenken bij de selectie van de software die ze daarbij gebruiken? Intrigerend...

Op de website van git staat uitgebreide documentatie, inclusief een compleet boek dat het uitgebreid beschrijft dat kosteloos online is in te zien en te downloaden. Niemand is afhankelijk van verkoperspraatjes, je kan het gratis en voor niets downloaden, leren gebruiken, gedetailleerde documentatie ervan lezen, grip krijgen op wat het wel en niet doet, uitzoeken wat je eventueel nog meer nodig hebt, beoordelen of het geschikt voor jouw doeleinden is.
Inderdaad. Jij gaat toch ook wel eens niet op elk aspect van wat een ander schrijft in? Ik heb meer dan eens van jou meegemaakt dat je selectief op mij antwoordde. Of helemaal niet.

Maar ik kan er wel wat over zeggen. Git heeft geen ingebouwde maximum grootte. Je noemt onder andere diskquota van github (een dienst gebaseerd op git) en ziet dat kennelijk aan voor limieten van git zelf. Git is, net als elk ander programma, natuurlijk onderhevig aan de limieten van het filesysteem waarop de data worden opgeslagen. Het kan geen grotere bestanden aanmaken dan het filesysteem ondersteunt. Het kan wel de repository over meerdere bestanden verdelen.
Git is gemaakt om broncode van software mee te beheren, en programmabroncode is voornamelijk tekst. Een project als de Linux-kernel is niet bepaald een klein project, en daar werkt het goed voor. Het is echt niet zo dat omdat je het woord "source" ook voor andere dingen kan gebruiken git opeens voor die andere dingen ontworpen is en aangeraden wordt.
Wat bedoel je met applicaties vanuit git inrichten? Als je het over het gebruik van git zelf hebt, lees dan nog eens wat ik al geschreven had: git schrijft niet een bepaald patroon voor, het faciliteert wel dat je patronen die je kiest kan implementeren.
Endevor is een van de pakketten waar ik in het verleden uitgebreid mee gewerkt heb, en dan heb ik het ook over de configuratie en security. Dat is absoluut geen pakket dat je even neerzet en dat dan gewoon werkt. De inrichting is maatwerk voor een organisatie en vergt een forse hoeveelheid denk-, implementeer- en testwerk. De invoering was een project van de nodige maanden en door de jaren heen is het een hoop inspanning blijven kosten. Te kostbaar om te maken en te onderhouden? Welnee, bedrijven die die inspanning niet bereid zijn te leveren krijgen het niet eens in een bruikbare staat. Git is aanzienlijk laagdrempeliger.

Leer trouwens eens om opsommingen goed te noteren. Je bedoelt: Panvalet, Rational en Endevor. Zoals je het schrijft lijkt het alsof Panvalet Rational Endevor de naam van een enkel pakket is. Hetzelfde geldt voor RACF ACF2, ook dat zijn twee produkten. Vermoedelijk had je daar het woord "of" tussen moeten plaatsen. Leesbaarheid doet er toe, leg de inspanning niet altijd bij de lezer neer als jij degene bent die wat kwijt wilt.