Datalek bij Radboudumc door oud-medewerker die data op GitHub plaatste
Het datalek bij het Radboudmc dat eerder deze maand aan het licht kwam is veroorzaakt door een oud-medewerker die bestanden op ontwikkelaarsplatform GitHub plaatste, zo blijkt uit onderzoek. De voormalige medewerker blijkt voornamelijk scripts voor het automatiseren van processen op GitHub te hebben geplaatst, maar er stond ook vertrouwelijke informatie tussen uit de it-omgeving van het Radboudmc, waaronder (inlog)namen, e-mailadressen en telefoonnummers van medewerkers en partnerorganisaties.
Uit het onderzoek blijkt verder dat de bestanden op GitHub door derden zijn gedownload. Eén van deze personen heeft de netwerkinformatie die in de bestanden stond gebruikt om de servers van het Radboudumc voor cryptomining te gebruiken. Volgens het medisch centrum is er geen ongeoorloofde toegang geweest tot bedrijfsapplicaties van het Radboudumc, zoals financiële administratie of het elektronisch patiëntendossier.
Naar aanleiding van het datalek heeft het Radboudumc de beveiliging van het netwerk naar eigen zeggen op meerdere fronten verder aangepast en verbeterd. Details worden echter niet gegeven. Tevens is er aangifte gedaan tegen zowel de veroorzaker van het datalek als de persoon die achter het cryptominen zat.
Reacties (19)
Ik hoor Steve Balmer nog zeggen op een presentatie...developer developer developers (staat in dit geval los van Microsoft) En ik ben zelf jaren developer geweest en naderhand een andere richting ingeslagen Infrastructuur specialist en later Security specialist. En ik weet hoe de dingen gaan. Security en al haar maatregelen worden vaak als lastig ervaren laat staan dat er richtlijnen en protocollen worden gelezen. Omdat Developers zo gericht zijn op hun product en het oplossen van knelpunten en deadlines.
Maar dit kan natuurlijk niet.
Ik kan mij niet voorstellen dat er niet ergens een richtlijn c.q. protocol bij het RadboudMC overtreden is.
In dit geval hoop ik dat het RadboudMC en andere instellingen hierdoor gewaarschuwd zijn en dit in hun protocollen opnemen dat dit soort acties verboden zijn en tot (zelf te bepalen) maatregelen kan leiden.
Maar dit kan natuurlijk niet.
Ik kan mij niet voorstellen dat er niet ergens een richtlijn c.q. protocol bij het RadboudMC overtreden is.
In dit geval hoop ik dat het RadboudMC en andere instellingen hierdoor gewaarschuwd zijn en dit in hun protocollen opnemen dat dit soort acties verboden zijn en tot (zelf te bepalen) maatregelen kan leiden.
25-08-2021, 11:12 door
Power2All
... github die open staat voor iedereen, en dan gevoelige informatie erop zetten.
Wat bezielde de persoon die dit deed ???
Je kan toch een private repository fixen, of was de persoon dat "vergeten" ?
Naja, nogal een oversight van hier tot Tokyo....
Wat bezielde de persoon die dit deed ???
Je kan toch een private repository fixen, of was de persoon dat "vergeten" ?
Naja, nogal een oversight van hier tot Tokyo....
Hoe kan een oud-medewerker kennelijk nog beschikken over (account)gegevens van medewerkers? Dat lijkt mij een 'datalek' (vind ik nog steeds een verkeerde term, omdat een datalek ook niet-persoonsgegevens kan betreffen) op zich.
Of is dit gebeurd toen deze oud-medewerker nog in dienst was bij het RadboudUMC? Onduidelijke berichtgeving over dit 'datalek'.
Of is dit gebeurd toen deze oud-medewerker nog in dienst was bij het RadboudUMC? Onduidelijke berichtgeving over dit 'datalek'.
Door Power2All: ... github die open staat voor iedereen, en dan gevoelige informatie erop zetten.
Wat bezielde de persoon die dit deed ???
Je kan toch een private repository fixen, of was de persoon dat "vergeten" ?
Naja, nogal een oversight van hier tot Tokyo....
Wat bezielde de persoon die dit deed ???
Je kan toch een private repository fixen, of was de persoon dat "vergeten" ?
Naja, nogal een oversight van hier tot Tokyo....
Je houdt altijd kneuzen die denken "héé, dat bestand staat niet onder versiebeheer, dat kan toch nooit de bedoeling zijn" (niet beseffende dat er een sync naar een remote repository is) of gewoon per ongeluk (neem bv. file name completion) het bestand toevoegen aan versiebeheer. De echte vraag moet echter zijn hoe dergelijke persoonsgevoelige informatie überhaupt in de context van de (lokale) git repository terecht is gekomen. Zo'n databestand hoort daar helemaal niet te staan (bij scripts, e.d.).
25-08-2021, 11:46 door
Power2All
Door Toje Fos:
Je houdt altijd kneuzen die denken "héé, dat bestand staat niet onder versiebeheer, dat kan toch nooit de bedoeling zijn" (niet beseffende dat er een sync naar een remote repository is) of gewoon per ongeluk (neem bv. file name completion) het bestand toevoegen aan versiebeheer. De echte vraag moet echter zijn hoe dergelijke persoonsgevoelige informatie überhaupt in de context van de (lokale) git repository terecht is gekomen. Zo'n databestand hoort daar helemaal niet te staan (bij scripts, e.d.).
Door Power2All: ... github die open staat voor iedereen, en dan gevoelige informatie erop zetten.
Wat bezielde de persoon die dit deed ???
Je kan toch een private repository fixen, of was de persoon dat "vergeten" ?
Naja, nogal een oversight van hier tot Tokyo....
Wat bezielde de persoon die dit deed ???
Je kan toch een private repository fixen, of was de persoon dat "vergeten" ?
Naja, nogal een oversight van hier tot Tokyo....
Je houdt altijd kneuzen die denken "héé, dat bestand staat niet onder versiebeheer, dat kan toch nooit de bedoeling zijn" (niet beseffende dat er een sync naar een remote repository is) of gewoon per ongeluk (neem bv. file name completion) het bestand toevoegen aan versiebeheer. De echte vraag moet echter zijn hoe dergelijke persoonsgevoelige informatie überhaupt in de context van de (lokale) git repository terecht is gekomen. Zo'n databestand hoort daar helemaal niet te staan (bij scripts, e.d.).
Ik heb dat ook afgeleerd te doen.
Sowieso, voor private projecten, heb ik mijn eigen Gitea server (GitLab is een beetje zwaar voor wat kleine projecten, Gitea is perfect voor dat soort kleinschalige gesloten projecten), en voor open-source projecten gaat het op Github.
Sowieso, als je met gevoelige data gaat werken als logins en API dingen, behoor je dit totaal onafhankelijk te maken, en met secrets of environment variables te werken, zoals je in Docker dat ook doet.
Door Power2All: ... github die open staat voor iedereen, en dan gevoelige informatie erop zetten.
Wat bezielde de persoon die dit deed ???
Je kan toch een private repository fixen, of was de persoon dat "vergeten" ?
Naja, nogal een oversight van hier tot Tokyo....
Wat bezielde de persoon die dit deed ???
Je kan toch een private repository fixen, of was de persoon dat "vergeten" ?
Naja, nogal een oversight van hier tot Tokyo....
Git is wat dit betreft een ramp. Voor je het weet worden niet alleen je script sources maar ook allerlei andere
dingen erin geplaatst en het is niet eens goed geregeld hoe je die weer kunt verwijderen, dan moet je door allerlei
hoepels springen. Het lijkt aantrekkelijk om met een "in principe staat alles erin tenzij excluded" model te werken
maar ik vond het aloude "alleen wat je expliciet in de versioning stopt komt erin" (van sccs, rcs, etc) model wat
dit betreft toch prettiger. Tuurlijk, er is het risico dat je nieuwe files vergeet erin te plaatsen. Maar er komen
tenminste niet per ongeluk dingen in die gevoelig zijn, heel veel ruimte kosten (gecompileerde executables bijv), etc.
Door Toje Fos:
Je houdt altijd kneuzen die denken "héé, dat bestand staat niet onder versiebeheer, dat kan toch nooit de bedoeling zijn" (niet beseffende dat er een sync naar een remote repository is) of gewoon per ongeluk (neem bv. file name completion) het bestand toevoegen aan versiebeheer. De echte vraag moet echter zijn hoe dergelijke persoonsgevoelige informatie überhaupt in de context van de (lokale) git repository terecht is gekomen. Zo'n databestand hoort daar helemaal niet te staan (bij scripts, e.d.).
Waar staat dat het om een databestand gaat? Wie weet gaat het om wat gegevens die her en der in de scripts zelf staan. Bijvoorbeeld een script wat notificaties stuurt naar beheerders kan emails nodig hebben. Een deployment script dat een aantal account toevoegt aan de local admins. Een "if username =" optie in een loginscript. Een dev die zijn email en telefoonnummer in het script heeft staan zodat zijn collega's weten wie ze over dat script moeten raadplegen. Alles is tegenwoordig een datalek en een datalek bij een medische instelling is natuurlijk extra sensationeel.Door Power2All: ... github die open staat voor iedereen, en dan gevoelige informatie erop zetten.
Wat bezielde de persoon die dit deed ???
Je kan toch een private repository fixen, of was de persoon dat "vergeten" ?
Naja, nogal een oversight van hier tot Tokyo....
Wat bezielde de persoon die dit deed ???
Je kan toch een private repository fixen, of was de persoon dat "vergeten" ?
Naja, nogal een oversight van hier tot Tokyo....
Je houdt altijd kneuzen die denken "héé, dat bestand staat niet onder versiebeheer, dat kan toch nooit de bedoeling zijn" (niet beseffende dat er een sync naar een remote repository is) of gewoon per ongeluk (neem bv. file name completion) het bestand toevoegen aan versiebeheer. De echte vraag moet echter zijn hoe dergelijke persoonsgevoelige informatie überhaupt in de context van de (lokale) git repository terecht is gekomen. Zo'n databestand hoort daar helemaal niet te staan (bij scripts, e.d.).
Door Anoniem:
Als je ' Security by Design' en ' Privacy by Design' hanteert, hoort er een Chinese Wall tussen programmecode en data te zitten. Als er (gevoelige) data in programmacode of scripts zit, is deze scheiding niet op orde.Door Toje Fos:
Je houdt altijd kneuzen die denken "héé, dat bestand staat niet onder versiebeheer, dat kan toch nooit de bedoeling zijn" (niet beseffende dat er een sync naar een remote repository is) of gewoon per ongeluk (neem bv. file name completion) het bestand toevoegen aan versiebeheer. De echte vraag moet echter zijn hoe dergelijke persoonsgevoelige informatie überhaupt in de context van de (lokale) git repository terecht is gekomen. Zo'n databestand hoort daar helemaal niet te staan (bij scripts, e.d.).
Waar staat dat het om een databestand gaat? Wie weet gaat het om wat gegevens die her en der in de scripts zelf staan. Bijvoorbeeld een script wat notificaties stuurt naar beheerders kan emails nodig hebben. Een deployment script dat een aantal account toevoegt aan de local admins. Een "if username =" optie in een loginscript. Een dev die zijn email en telefoonnummer in het script heeft staan zodat zijn collega's weten wie ze over dat script moeten raadplegen. Alles is tegenwoordig een datalek en een datalek bij een medische instelling is natuurlijk extra sensationeel.Door Power2All: ... github die open staat voor iedereen, en dan gevoelige informatie erop zetten.
Wat bezielde de persoon die dit deed ???
Je kan toch een private repository fixen, of was de persoon dat "vergeten" ?
Naja, nogal een oversight van hier tot Tokyo....
Wat bezielde de persoon die dit deed ???
Je kan toch een private repository fixen, of was de persoon dat "vergeten" ?
Naja, nogal een oversight van hier tot Tokyo....
Je houdt altijd kneuzen die denken "héé, dat bestand staat niet onder versiebeheer, dat kan toch nooit de bedoeling zijn" (niet beseffende dat er een sync naar een remote repository is) of gewoon per ongeluk (neem bv. file name completion) het bestand toevoegen aan versiebeheer. De echte vraag moet echter zijn hoe dergelijke persoonsgevoelige informatie überhaupt in de context van de (lokale) git repository terecht is gekomen. Zo'n databestand hoort daar helemaal niet te staan (bij scripts, e.d.).
Door Anoniem:
Door Toje Fos: ... Zo'n databestand hoort daar helemaal niet te staan (bij scripts, e.d.).
Waar staat dat het om een databestand gaat? Wie weet gaat het om wat gegevens die her en der in de scripts zelf staan. Bijvoorbeeld een script wat notificaties stuurt naar beheerders kan emails nodig hebben. Een deployment script dat een aantal account toevoegt aan de local admins. Een "if username =" optie in een loginscript. Een dev die zijn email en telefoonnummer in het script heeft staan zodat zijn collega's weten wie ze over dat script moeten raadplegen. Alles is tegenwoordig een datalek en een datalek bij een medische instelling is natuurlijk extra sensationeel.Uit het door redactie gelinkte artikel:
het datalek is veroorzaakt door een voormalig medewerker van het Radboudumc. De oud-medewerker in kwestie heeft een aantal bestanden van het Radboudumc op GitHub geplaatst, een online platform waar softwareontwikkelaars kennis met elkaar delen. In deze bestanden stonden vooral scripts voor het automatiseren van processen. Tussen de scripts was echter ook vertrouwelijke informatie uit de IT-omgeving van het Radboudumc te vinden, inclusief de eerder gemelde persoonsgegevens
Dus databestand of databestanden (want anders had men wel geschreven "in de scripts was ook vertrouwelijke...").
Door Toje Fos:
Uit het door redactie gelinkte artikel:
Dus databestand of databestanden (want anders had men wel geschreven "in de scripts was ook vertrouwelijke...").
Heeft waarschijnlijk een git commit -a gedaan of een .gitignore vergeten.Door Anoniem:
Door Toje Fos: ... Zo'n databestand hoort daar helemaal niet te staan (bij scripts, e.d.).
Waar staat dat het om een databestand gaat? Wie weet gaat het om wat gegevens die her en der in de scripts zelf staan. Bijvoorbeeld een script wat notificaties stuurt naar beheerders kan emails nodig hebben. Een deployment script dat een aantal account toevoegt aan de local admins. Een "if username =" optie in een loginscript. Een dev die zijn email en telefoonnummer in het script heeft staan zodat zijn collega's weten wie ze over dat script moeten raadplegen. Alles is tegenwoordig een datalek en een datalek bij een medische instelling is natuurlijk extra sensationeel.Uit het door redactie gelinkte artikel:
het datalek is veroorzaakt door een voormalig medewerker van het Radboudumc. De oud-medewerker in kwestie heeft een aantal bestanden van het Radboudumc op GitHub geplaatst, een online platform waar softwareontwikkelaars kennis met elkaar delen. In deze bestanden stonden vooral scripts voor het automatiseren van processen. Tussen de scripts was echter ook vertrouwelijke informatie uit de IT-omgeving van het Radboudumc te vinden, inclusief de eerder gemelde persoonsgegevens
Dus databestand of databestanden (want anders had men wel geschreven "in de scripts was ook vertrouwelijke...").
Door Anoniem:
Git is wat dit betreft een ramp. Voor je het weet worden niet alleen je script sources maar ook allerlei andere
dingen erin geplaatst en het is niet eens goed geregeld hoe je die weer kunt verwijderen, dan moet je door allerlei
hoepels springen. Het lijkt aantrekkelijk om met een "in principe staat alles erin tenzij excluded" model te werken
maar ik vond het aloude "alleen wat je expliciet in de versioning stopt komt erin" (van sccs, rcs, etc) model wat
dit betreft toch prettiger. Tuurlijk, er is het risico dat je nieuwe files vergeet erin te plaatsen. Maar er komen
tenminste niet per ongeluk dingen in die gevoelig zijn, heel veel ruimte kosten (gecompileerde executables bijv), etc.
Door Power2All: ... github die open staat voor iedereen, en dan gevoelige informatie erop zetten.
Wat bezielde de persoon die dit deed ???
Je kan toch een private repository fixen, of was de persoon dat "vergeten" ?
Naja, nogal een oversight van hier tot Tokyo....
Wat bezielde de persoon die dit deed ???
Je kan toch een private repository fixen, of was de persoon dat "vergeten" ?
Naja, nogal een oversight van hier tot Tokyo....
Git is wat dit betreft een ramp. Voor je het weet worden niet alleen je script sources maar ook allerlei andere
dingen erin geplaatst en het is niet eens goed geregeld hoe je die weer kunt verwijderen, dan moet je door allerlei
hoepels springen. Het lijkt aantrekkelijk om met een "in principe staat alles erin tenzij excluded" model te werken
maar ik vond het aloude "alleen wat je expliciet in de versioning stopt komt erin" (van sccs, rcs, etc) model wat
dit betreft toch prettiger. Tuurlijk, er is het risico dat je nieuwe files vergeet erin te plaatsen. Maar er komen
tenminste niet per ongeluk dingen in die gevoelig zijn, heel veel ruimte kosten (gecompileerde executables bijv), etc.
Hoe kom je daar bij ?
Je moet bij git toch echt een eerste keer
git add <file>
of git add <directory>
doen voordat de files daarin deel van de git repo worden.
git status
On branch blabla
Your branch is up to date with 'origin/blabla.
Untracked files:
(use "git add <file>..." to include in what will be committed)
secretdata.txt
nothing added to commit but untracked files present (use "git add" to track)
De digitale samenleving,so much fun.
NLNU2021
Pen&papier vs de digitale samenleving.
NLNU1998
NLNU2021
Pen&papier vs de digitale samenleving.
NLNU1998
Door Toje Fos: Je houdt altijd kneuzen die denken "héé, dat bestand staat niet onder versiebeheer, dat kan toch nooit de bedoeling zijn" (niet beseffende dat er een sync naar een remote repository is) of gewoon per ongeluk (neem bv. file name completion) het bestand toevoegen aan versiebeheer. De echte vraag moet echter zijn hoe dergelijke persoonsgevoelige informatie überhaupt in de context van de (lokale) git repository terecht is gekomen. Zo'n databestand hoort daar helemaal niet te staan (bij scripts, e.d.).
Het is de valkuil van open source gelovigen. Hoe vaak is er niet ergens een manager dat alles met git in de cloud moet. Dacht je nu echt dat die zich over de risico's van de informatie wat er staat iets aantrekt. Op die wijze verdwijnt ongelooflijk veel gevoelige informatie naar de openbare ruimte. aan de andere kant is een goed backup met DR proces weer te duur.Door Anoniem: ...
Als je ' Security by Design' en ' Privacy by Design' hanteert, hoort er een Chinese Wall tussen programmecode en data te zitten. Als er (gevoelige) data in programmacode of scripts zit, is deze scheiding niet op orde.
Daar heb je gelijk in. Dat betekent dat je eerst goed moet nadenken waar alle neer te zetten voordat je aan verioning en releases gaat werken. In de praktijk gaat dat andersom. Eerst en hackaton (poc) en gaan bouwen en daarna kijken of en hoe het veilig oe moetenAls je ' Security by Design' en ' Privacy by Design' hanteert, hoort er een Chinese Wall tussen programmecode en data te zitten. Als er (gevoelige) data in programmacode of scripts zit, is deze scheiding niet op orde.
Door karma4:
Door Toje Fos: Je houdt altijd kneuzen die denken "héé, dat bestand staat niet onder versiebeheer, dat kan toch nooit de bedoeling zijn" (niet beseffende dat er een sync naar een remote repository is) of gewoon per ongeluk (neem bv. file name completion) het bestand toevoegen aan versiebeheer. De echte vraag moet echter zijn hoe dergelijke persoonsgevoelige informatie überhaupt in de context van de (lokale) git repository terecht is gekomen. Zo'n databestand hoort daar helemaal niet te staan (bij scripts, e.d.).
Het is de valkuil van open source gelovigen.Wot? Als je 'per ongeluk' closed source software of databestanden op GitHub zet in een public repository dan is dat de valkuil van open source 'gelovigen'? Tuurlijk, karma4, het is goed hoor, doe rustig aan.
Door Anoniem:
Hoe kom je daar bij ?
Je moet bij git toch echt een eerste keer
git add <file>
of git add <directory>
doen voordat de files daarin deel van de git repo worden.
Door Anoniem:
Git is wat dit betreft een ramp. Voor je het weet worden niet alleen je script sources maar ook allerlei andere
dingen erin geplaatst en het is niet eens goed geregeld hoe je die weer kunt verwijderen, dan moet je door allerlei
hoepels springen. Het lijkt aantrekkelijk om met een "in principe staat alles erin tenzij excluded" model te werken
maar ik vond het aloude "alleen wat je expliciet in de versioning stopt komt erin" (van sccs, rcs, etc) model wat
dit betreft toch prettiger. Tuurlijk, er is het risico dat je nieuwe files vergeet erin te plaatsen. Maar er komen
tenminste niet per ongeluk dingen in die gevoelig zijn, heel veel ruimte kosten (gecompileerde executables bijv), etc.
Door Power2All: ... github die open staat voor iedereen, en dan gevoelige informatie erop zetten.
Wat bezielde de persoon die dit deed ???
Je kan toch een private repository fixen, of was de persoon dat "vergeten" ?
Naja, nogal een oversight van hier tot Tokyo....
Wat bezielde de persoon die dit deed ???
Je kan toch een private repository fixen, of was de persoon dat "vergeten" ?
Naja, nogal een oversight van hier tot Tokyo....
Git is wat dit betreft een ramp. Voor je het weet worden niet alleen je script sources maar ook allerlei andere
dingen erin geplaatst en het is niet eens goed geregeld hoe je die weer kunt verwijderen, dan moet je door allerlei
hoepels springen. Het lijkt aantrekkelijk om met een "in principe staat alles erin tenzij excluded" model te werken
maar ik vond het aloude "alleen wat je expliciet in de versioning stopt komt erin" (van sccs, rcs, etc) model wat
dit betreft toch prettiger. Tuurlijk, er is het risico dat je nieuwe files vergeet erin te plaatsen. Maar er komen
tenminste niet per ongeluk dingen in die gevoelig zijn, heel veel ruimte kosten (gecompileerde executables bijv), etc.
Hoe kom je daar bij ?
Je moet bij git toch echt een eerste keer
git add <file>
of git add <directory>
doen voordat de files daarin deel van de git repo worden.
Ja en wat gebeurt er als je "git add directory" doet en in die directory of ergens daaronder staan nu of later toevallig
bestandjes die niet mee hadden gemoeten? Dan gaan die mee. En als je dat ziet, dan is dat al bijna niet meer
terug te draaien. "dan had je maar een .gitignore moeten maken". Ja achteraf is het makkelijk kletsen...
Door Anoniem:
Ja en wat gebeurt er als je "git add directory" doet en in die directory of ergens daaronder staan nu of later toevallig
bestandjes die niet mee hadden gemoeten? Dan gaan die mee. En als je dat ziet, dan is dat al bijna niet meer
terug te draaien. "dan had je maar een .gitignore moeten maken". Ja achteraf is het makkelijk kletsen...
Door Anoniem: <voorbeelden en kanttekeningen bij professioneel gebruik van git>.
Ja en wat gebeurt er als je "git add directory" doet en in die directory of ergens daaronder staan nu of later toevallig
bestandjes die niet mee hadden gemoeten? Dan gaan die mee. En als je dat ziet, dan is dat al bijna niet meer
terug te draaien. "dan had je maar een .gitignore moeten maken". Ja achteraf is het makkelijk kletsen...
Ja, als je met een zaag je vingers afzaagt? En dan ook nog je handen eraf? En je voeten misschien ook nog? Software ontwikkeling is een vak.
Door Anoniem:…Voor je het weet worden niet alleen je script sources maar ook allerlei andere
dingen erin geplaatst en het is niet eens goed geregeld hoe je die weer kunt verwijderen, dan moet je door allerlei
hoepels springen.
dingen erin geplaatst en het is niet eens goed geregeld hoe je die weer kunt verwijderen, dan moet je door allerlei
hoepels springen.
Het idee van een versie systeem is nu juist dat ook verwijderde bestanden of programmaregels ten allen tijde weer terug te zien zijn. (-:
Toch is deze situatie echt wel voorzien voor het geval er onbewust gevoelige info in de repository komt. De handleiding beschrijft duidelijk hoe zo iets toch volledig verwijderd kan worden. En het is terecht dat dit niet te simpel gaat om te voorkomen dat dit vaak gebeurd. (B.v. voor het verdoezelen van een stomme programmeerfout)
Verder sluit ik me bij reageerder #3 aan. Het echte datalek was natuurlijk dat een oud-werknemer nog in het bezit was van dergelijke data.
Door Toje Fos:
Ja, als je met een zaag je vingers afzaagt? En dan ook nog je handen eraf? En je voeten misschien ook nog? Software ontwikkeling is een vak.
Als het om software en computers gaat, gaan bij de meeste hersenpanden de lichtjes uit.Door Anoniem:
Ja en wat gebeurt er als je "git add directory" doet en in die directory of ergens daaronder staan nu of later toevallig
bestandjes die niet mee hadden gemoeten? Dan gaan die mee. En als je dat ziet, dan is dat al bijna niet meer
terug te draaien. "dan had je maar een .gitignore moeten maken". Ja achteraf is het makkelijk kletsen...
Door Anoniem: <voorbeelden en kanttekeningen bij professioneel gebruik van git>.
Ja en wat gebeurt er als je "git add directory" doet en in die directory of ergens daaronder staan nu of later toevallig
bestandjes die niet mee hadden gemoeten? Dan gaan die mee. En als je dat ziet, dan is dat al bijna niet meer
terug te draaien. "dan had je maar een .gitignore moeten maken". Ja achteraf is het makkelijk kletsen...
Ja, als je met een zaag je vingers afzaagt? En dan ook nog je handen eraf? En je voeten misschien ook nog? Software ontwikkeling is een vak.
Door Anoniem:
Ja en wat gebeurt er als je "git add directory" doet en in die directory of ergens daaronder staan nu of later toevallig
bestandjes die niet mee hadden gemoeten? Dan gaan die mee. En als je dat ziet, dan is dat al bijna niet meer
terug te draaien. "dan had je maar een .gitignore moeten maken". Ja achteraf is het makkelijk kletsen...
Door Anoniem:
Hoe kom je daar bij ?
Je moet bij git toch echt een eerste keer
git add <file>
of git add <directory>
doen voordat de files daarin deel van de git repo worden.
Door Anoniem:
Git is wat dit betreft een ramp. Voor je het weet worden niet alleen je script sources maar ook allerlei andere
dingen erin geplaatst en het is niet eens goed geregeld hoe je die weer kunt verwijderen, dan moet je door allerlei
hoepels springen. Het lijkt aantrekkelijk om met een "in principe staat alles erin tenzij excluded" model te werken
maar ik vond het aloude "alleen wat je expliciet in de versioning stopt komt erin" (van sccs, rcs, etc) model wat
dit betreft toch prettiger. Tuurlijk, er is het risico dat je nieuwe files vergeet erin te plaatsen. Maar er komen
tenminste niet per ongeluk dingen in die gevoelig zijn, heel veel ruimte kosten (gecompileerde executables bijv), etc.
Door Power2All: ... github die open staat voor iedereen, en dan gevoelige informatie erop zetten.
Wat bezielde de persoon die dit deed ???
Je kan toch een private repository fixen, of was de persoon dat "vergeten" ?
Naja, nogal een oversight van hier tot Tokyo....
Wat bezielde de persoon die dit deed ???
Je kan toch een private repository fixen, of was de persoon dat "vergeten" ?
Naja, nogal een oversight van hier tot Tokyo....
Git is wat dit betreft een ramp. Voor je het weet worden niet alleen je script sources maar ook allerlei andere
dingen erin geplaatst en het is niet eens goed geregeld hoe je die weer kunt verwijderen, dan moet je door allerlei
hoepels springen. Het lijkt aantrekkelijk om met een "in principe staat alles erin tenzij excluded" model te werken
maar ik vond het aloude "alleen wat je expliciet in de versioning stopt komt erin" (van sccs, rcs, etc) model wat
dit betreft toch prettiger. Tuurlijk, er is het risico dat je nieuwe files vergeet erin te plaatsen. Maar er komen
tenminste niet per ongeluk dingen in die gevoelig zijn, heel veel ruimte kosten (gecompileerde executables bijv), etc.
Hoe kom je daar bij ?
Je moet bij git toch echt een eerste keer
git add <file>
of git add <directory>
doen voordat de files daarin deel van de git repo worden.
Ja en wat gebeurt er als je "git add directory" doet en in die directory of ergens daaronder staan nu of later toevallig
bestandjes die niet mee hadden gemoeten? Dan gaan die mee. En als je dat ziet, dan is dat al bijna niet meer
terug te draaien. "dan had je maar een .gitignore moeten maken". Ja achteraf is het makkelijk kletsen...
Met genoeg werk kun je alles fout doen - ergens houd de bescherming van software en veilige defaults op.
Maar ik reageerde op iemand die beweerde dat je met git alles "vanzelf" upload en dat dat vroeger met SCCS , RCS e.d. niet vanzelf ging .
Die bewering is onwaar - ook bij git worden nieuwe files _niet_ default toegevoegd .
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
