image

GitHub-account Ubuntu-ontwikkelaar Canonical gekaapt

zondag 7 juli 2019, 15:53 door Redactie, 25 reacties

Een aanvaller is erin geslaagd een GitHub-account van Ubuntu-ontwikkelaar Canonical te kapen en te gebruiken voor het aanmaken van elf lege repositories. Het account is inmiddels verwijderd en er zijn geen aanwijzingen dat de broncode van Ubuntu is aangepast of er persoonsgegevens zijn gecompromitteerd.

Dat laat Canonical in een reactie op Hacker News weten. Volgens de Ubuntu-ontwikkelaar zijn de gegevens van het betreffende GitHub-account gecompromitteerd, waardoor de aanvaller toegang wist te krijgen en de repositories en andere issues aanmaakte.

"De Launchpad-infrastructuur waar de Ubuntu-distributie wordt gebouwd en beheerd staat los van GitHub en er zijn geen aanwijzingen dat die is getroffen", aldus Canonical. Het onderzoek loopt nog en de Ubuntu-ontwikkelaar zal, nadat het onderzoek, audits en herstelwerkzaamheden zijn afgerond, met een update over het incident komen.

Image

Reacties (25)
07-07-2019, 16:28 door Anoniem
Microsoft hoeft tenminste niet bij Canonical aan te kloppen voor beveiligings advies.
07-07-2019, 20:21 door Anoniem
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.
08-07-2019, 03:28 door Anoniem
Door Anoniem: Microsoft hoeft tenminste niet bij Canonical aan te kloppen voor beveiligings advies.
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... ;-)
08-07-2019, 07:44 door karma4
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.
08-07-2019, 07:49 door Bitje-scheef
Door Anoniem: Microsoft hoeft tenminste niet bij Canonical aan te kloppen voor beveiligings advies.

Blijf jij voorlopig nog maar anoniem :-)
08-07-2019, 07:55 door Anoniem
Geen 2FA? Of ssh key (zonder wachtwoord) uitgelekt?
08-07-2019, 09:46 door Ron625
Het ging in deze om privé code, niet om de code die door Canonical gebruikt wordt.
Een storm in een glas water dus..........
08-07-2019, 09:50 door Anoniem
Door Anoniem: 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.
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.
08-07-2019, 10:28 door Anoniem
Door karma4: Het uitlekken van een account (iets dat je weet) heeft weinig met een os van doen.
Klopt.
Als je dat toch wil.... Git github is op linux gebaseerd. Het heeft alle beperkingen en eigenschappen met de kwetsbaarheden van dat os.
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.
08-07-2019, 11:03 door [Account Verwijderd] - Bijgewerkt: 08-07-2019, 11:04
Door Anoniem:
Door karma4: Als je dat toch wil.... Git github is op linux gebaseerd. Het heeft alle beperkingen en eigenschappen met de kwetsbaarheden van dat os.
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.
08-07-2019, 11:56 door Anoniem
Door karma4: Het uitlekken van een account (iets dat je weet) heeft weinig met een os van doen.
Precies: sleutelbeheer is in tal van verschijningsvormen (fysiek, digitaal) blijkbaar nog geen opgelost probleem.

Door karma4: Als je dat toch wil.... Git github is op linux gebaseerd. Het heeft alle beperkingen en eigenschappen met de kwetsbaarheden van dat os.
Hehe :-)
Git (tool) != GitHub (dienst), maar
GitHub == Microsoft - https://blogs.microsoft.com/blog/2018/10/26/microsoft-completes-github-acquisition/
08-07-2019, 12:11 door Briolet
Door Ron625: Het ging in deze om privé code, niet om de code die door Canonical gebruikt wordt.
Een storm in een glas water dus..........

Ook al was dit privé code, het zegt wel iets over hoe deze programmeur met wachtwoorden omgaat. En waarschijnlijk geen 2FA gebruikt.
08-07-2019, 14:27 door karma4
Door En Rattshaverist: Bovendien is Git helemaal niet 'op Linux gebaseerd'. Het is gewoon een versiebeheerapplicatie, niet meer en niet minder.
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.
08-07-2019, 14:48 door [Account Verwijderd]
Door karma4:
Door En Rattshaverist: Bovendien is Git helemaal niet 'op Linux gebaseerd'. Het is gewoon een versiebeheerapplicatie, niet meer en niet minder.
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.

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.

Door karma4: Alternatief is Atlassian bit bucket zeer populair.

Geweldig...
08-07-2019, 14:53 door Briolet - Bijgewerkt: 08-07-2019, 14:53
Door En Rattshaverist: 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. …

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.
08-07-2019, 18:07 door Anoniem
Door karma4: 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.
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?
Door karma4: Git github is op linux gebaseerd. Het heeft alle beperkingen en eigenschappen met de kwetsbaarheden van dat os.
Dat klinkt alsof broncode van de Linuxkernel in de broncode van git verwerkt is. Is dat wat je denkt of bedoel je iets anders?
08-07-2019, 20:38 door karma4 - Bijgewerkt: 08-07-2019, 20:50
Door Anoniem:
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.
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.


Door Anoniem:
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?
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.
08-07-2019, 22:40 door [Account Verwijderd] - Bijgewerkt: 08-07-2019, 22:41
Door karma4: 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.

@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.
09-07-2019, 09:40 door Anoniem
Door karma4: 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.
Je hebt niet goed gelezen. Onder de kop "GIT URLS" staat:
Git supports ssh, git, http, and https protocols (in addition, ftp, and ftps can be used for fetching, but this is inefficient and deprecated; do not use it).

The native transport (i.e. git:// URL) does no authentication and should be used with caution on unsecured networks.
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.

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.
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.
09-07-2019, 20:47 door karma4
Door En Rattshaverist: … , omdat je beseft dat je fout zit en iets moet verzinnen om zoveel mogelijk gezichtsverlies te voorkomen. Niet gelukt, dat laatste.
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.
09-07-2019, 21:02 door karma4 - Bijgewerkt: 09-07-2019, 21:20
Door Anoniem: Je hebt niet goed gelezen. Onder de kop "GIT URLS" staat:
[Git supports ssh, git, http, and https protocols (in addition, ftp, and ftps can be used for fetching, but this is inefficient and deprecated; do not use it).
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


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. ...
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...
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.
09-07-2019, 21:16 door [Account Verwijderd] - Bijgewerkt: 09-07-2019, 21:16
Door karma4:
Door En Rattshaverist: … , omdat je beseft dat je fout zit en iets moet verzinnen om zoveel mogelijk gezichtsverlies te voorkomen. Niet gelukt, dat laatste.
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.

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!
09-07-2019, 21:21 door karma4
Door En Rattshaverist:
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.
09-07-2019, 22:56 door [Account Verwijderd]
Door karma4:
Door En Rattshaverist:
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. ?
10-07-2019, 12:51 door Anoniem
Door karma4: Dank je, je zegt feitelijk at je afhankelijk van dat achterliggende 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.
Alleen zal zo'n SSH benadering weer de bekende achilleshiel in de home ofwel userprofile opleveren.
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.
Nog vervelender wordt het met dat inichten van zo'n restricted shell. Het zal niet makkelijk in het publieke domein zijn.
Die restricted shell wordt, zoals ik schreef, kant en klaar meegeleverd. Een shell aan een user koppelen is een kleinigheid.
Allemaal persoonlijke account zichtbaar op het OS.
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.
De weerstand vanuit Linux beheer is vrij groot. Het gangbare antwoord "dat moet de applicatie maar oplossen".
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 wordt vaak wel als de totaaloplossing gebracht. Zet git naar en uw versiebeheersprobleem is opgelost.
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.
- Je hebt dat gedoe met de maximale size niet opgepakt
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.
Datascience de data is de werkelijke source.
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.
- Ik mis van je een security model patroon hoe je applicaties vanuit git inricht, specifiek linux.
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.
- 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.
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.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.