Hoe een merkenclaim tijdelijk het internet stukmaakte

| AE 8525 | Auteursrecht, Merken, Open source, Software | 23 reacties

kaartenhuis-cards-modules-blokken-software-scriptsWhoa. Elf regels code weghalen leidde tot een stukgegaan internet, las ik bij BusinessInsider. Dit was het onverwachte gevolg van een merkenclaim van sociaal netwerk Kik tegen softwaremodule Kik. Op basis van die claim werd de module weggehaald, waar de developer zo boos over werd dat hij al zijn code weghaalde. Waaronder dus die ene van elf regels die het internet stuk maakte.

Of nou ja, stukmaken is een groot woord. De elf regels implementeerden een vrij basale functie (het links uitvullen van een tekst met een zelf te kiezen teken tot een bepaalde lengte), maar duizenden softwareprojecten maakten er gebruik van.

Het begon allemaal met een merkenclaim van dat sociale netwerk waar ik ook nog nooit van had gehoord. Die claim is een tikje raar: twee softwarepakketten of -diensten mogen best dezelfde naam hebben, zolang ze maar niet verwant aan elkaar zijn. Een sociaal netwerk en een installatiescript hebben weinig met elkaar te maken, dus merkenrechtelijk zou die claim afgewezen moeten worden. Echter, de beheerder van de software repository (NPM) heeft eigen beleid en vindt dat namen toebehoren aan de partij bij wie dat het meest voor de hand ligt. Aangezien dat sociale netwerk bekender is dan het installatiescript, moest het script plaats maken.

De auteur van het script zag dit als ‘kapen’ van zijn project, mede omdat NPM die code zelf weer beschikbaar stelde als lapmiddel, en besloot met al zijn projecten daar weg te gaan. En toen ging het internet dus stuk: één van zijn projecten was dat left-pad programma van elf regels waar die duizenden projecten op rekenden. Al die projecten konden ineens niet meer worden gecompileerd, totdat iemand een alternatief uploadde. Inderdaad, een nogal ruime definitie van “stuk”. Maar goed, journalistieke vrijheid hè.

Juridisch gezien een zeer merkwaardig verhaal. Die merkenclaim riekt nogal gezocht, en de mails daarover doen nogal bullying aan. En nee, ze hoeven niet ieder gebruik van een merknaam aan te pakken maar alleen als de merknaam anders een generieke term wordt.

Hoewel een club als NPM best beleid mag maken dat strenger is dan het merkenrecht, doet het wel gek aan om zó ver te gaan met je regels. Bovendien zou je verwachten dat men eerst overlegt alvorens projecten offline te halen of naamswijzigingen af te dwingen.

Dat herpubliceren van de code door NPM lijkt me legaal. De code was open source, en dan mag je forken tegen de wens van de auteurs in. Handig is anders, dat wel.

Maar sjonge zeg, wat een geblunder.

Arnoud

Deel dit artikel

  1. Het betreft in dit geval een software database. Wanneer je hierin het commando ‘npm install kik’ uitvoert wordt het pakket met de naam ‘kik’ geinstalleerd. In zo’n geval kan je geen dubbele namen hebben, ook als dat juridisch wel mag. De specifieke aanpassing is dat vanaf een nieuw versienummer de naam kik overging, en dat alle code nog gewoon bleef werken aangezien die met een versienummer gelinkt is aan ‘kik’.

    Het probleem hier is dat in een opensource project de oude eigenaar van ‘kik’ op delete all drukte en toen al zijn scripts, inclusief ‘left-pad’ en ‘kik’ verwijderde. Hiermee breken alle scripts die hierop gebaseerd zijn. En een stap erger, als iemand een nieuw script upload met de naam ‘left-pad’ wordt deze automatisch gebruikt in alle andere projecten gebruikt. Iets wat meteen een behoorlijk veiligheidsrisico teweeg brengt.

    Samengevat 1. Een repository maakte een beslissing voor een project boven een ander, zonder gevolgen omdat de oude en nieuwe code nog steeds naast elkaar blijven werken. 2. Een ontwikkelaar kon op delete all drukken en verwijderde al zijn code wat veel projecten onmiddellijk brak. 3. De website ondersteunde om meteen die naam in te pikken met alle gevolgen van dien.

    Dat die laatste 2 dingen konden gebeuren betekend een slecht opgezette repository. Het eerste punt dat er geen dubbele namen mogen zitten in een API is erg voor de hand liggend, met een gedocumenteerd beleid en automatische overgangssituatie.

  2. Ik snap niet hoe dit zoveel websites kapot heeft kunnen maken. Als ik een website maak en daarbij extern ontwikkelde componenten gebruik, dan maak ik een lokale kopie van die componenten, en de website maakt vervolgens gebruik van die lokale kopie. Als ik die lokale kopie een keer wil updaten (kan nodig zijn voor security updates), dan doe ik dat handmatig, en ik test de site eerst met de update, voordat de update online gaat.

    Misschien kan je je website een beetje sneller maken door de scripts te laten hosten door een andere partij, maar je maakt je website wel fragiel: iedere derde partij die een dependency levert kan dan potentieel je website kapot maken. Ik heb nooit het idee gehad dat het verstandig is om dat risico te nemen.

      • Dat maakt geen verschil: dan maak je gewoon een installatie-script of Makefile of zo dat de compilatie uitvoert. Het geheel van eigen code + installatie-script + gedownloade componenten is redelijk self-contained, en kan heel goed als geheel getest worden en dan in de zelfde vorm op een ander platform worden geïnstalleerd.

        Het is wel zaak dat de (platform-afhankelijke) compilatie-stap gescheiden is van de download-stap. Als je pakket-distributie dat niet aan kan (bijv. de download-acties zelf zijn platform-afhankelijk), dan is dat vervelend, en moet je maar een work-around maken. Je kunt bijvoorbeeld een test-systeem hebben dat qua platform identiek is aan je produktie-systeem (sowieso een goed idee), en daarop je downloads uitvoeren bij het maken van een nieuwe revisie. Dat downloaden (plus eventueel compileren) is een eenmalige stap; daarna ga je het geheel testen op het test-systeem, en daarna installeer je het op je produktie-systeem. Bij het installeren op het produktie-systeem moet er NIET opnieuw gedownload worden: je moet precies datgene installeren wat je getest hebt.

        Bij deze manier van werken zou je op het produktie-systeem NOOIT upstream-regressies mee moeten krijgen. Zo wel, dan test je blijkbaar niet goed genoeg.

        Het gaat in dit geval trouwens toch om Javascript-code? Hoe kan er dan sprake zijn van platform-afhankelijke compilatie?

    • Haney heeft er helaas heel erg weinig van begrepen, en dat artikel bestaat dan ook grotendeels uit gebazel van iemand die uit een monolitisch ecosysteem (.NET) komt, en daardoor een zeer eenzijdig beeld heeft van hoe dependencies werken, en zijn mening blijkbaar baseert op hoe het werkt in andere talen/ecosystemen.

      Ten eerste: dependencies zijn altijd wenselijk. Er zitten – afhankelijk van de situatie – mogelijk haken en ogen aan, maar daarvan afgezien is het hebben van dependencies an sich zonder twijfel een wenselijk iets, daar het de betrouwbaarheid van software sterk verbetert, doordat iedereen gezamenlijk de implementatie-problemen oplost.

      Dit betekent dat je niet iedere keer hetzelfde probleem op moet lossen, en tegen dezelfde caveats aan moet lopen die iemand anders een jaar geleden al door had. Dit is essentieel.

      Ten tweede: Haney impliceert dat het aantal regels code relevant is voor of iets een dependency moet zijn, maar dat is volslagen onzin. Het aantal regels code heeft niets, maar dan ook niets te maken met de complexiteit van code – sterker nog, je kunt er niet eens aan afzien hoe vaak de code gepatcht moest worden om het correct te laten werken. Deze post gaat daar verder op in, en ik raad je zeer sterk aan om hem te lezen.

      Ten derde: Haney wijst de problemen toe aan het hebben van veel dependencies, maar dit is onjuist; het hebben van veel dependencies is wederom wenselijk, en is an sich geen probleem. Het probleem ligt hier bij de infrastructuur, die bijvoorbeeld het verwijderen van modules toelaat. Dat zou absoluut niet het geval moeten zijn.

      Hetzelfde geldt voor het krijgen van automatische updates; dit is een kwestie van shrinkwrap gebruiken en handmatig je updates controleren, iets dat je sowieso al zou moeten doen. Voor degenen die dat niet doen, is het automatisch binnenhalen van updates de meest wenselijke optie vanuit beveiligings-oogpunt (het alternatief is namelijk dat je voor altijd op dezelfde mogelijk-lekke versie blijft zitten). Dit punt wordt niet expliciet benoemd in Haney’s post, maar is iets dat ik op veel andere plaatsen bekritiseert zie worden.

      Ten vierde;

      The more dependencies you take on, the more points of failure you have.

      Dit is misleidend. Het hebben van veel kleine dependencies zorgt er nu juist voor dat dit risico verminderd wordt; het is namelijk voor vrijwel iedere dependency triviaal om hem te patchen, vervangen of zelfs forken als dat nodig blijkt. In een monolitisch en rolling-your-own ecosysteem (dat Haney aanbeveelt) is dit onbegonnen werk. Er zijn in een “modulair ecosysteem” dus meer punten waarop het kan falen, maar ieder individueel punt is vele malen makkelijker om op te lossen, waardoor je netto op winst uitkomt qua onderhoud.

      Dit wordt nog versterkt door de andere (deels al genoemde) voordelen van kleine modules, zoals het hergebruik van oplossingen (en dus minder kans dat hetzelfde probleem op diverse plaatsen optreedt).

      Tot slot, punt vijf:

      It feels to me as if the entire job of an NPM-participating developer is writing the smallest amount of code possible to string existing library calls together in order to create something new that functions uniquely for their personal or business need.

      Als je deze opmerking uit zijn verband haalt, klinkt het bijna als een compliment. Het doel van software ontwikkelen is juist om zo effectief en robuust mogelijk een idee om te zetten in een werkende applicatie. De opmerking van Haney is bijna letterlijk de functieomschrijving van een programmeur! Dit doet uiteraard niet af aan de noodzaak om kennis te hebben van de onderliggende technologie, maar dat is niet het punt; zie wederom het artikel dat ik eerder al linkte.

      Kort samengevat; Haney begrijpt niet hoe het NPM-ecosysteem in elkaar zit, begrijpt daardoor ook niet waar de daadwerkelijke problemen liggen, en maakt ‘elitaire’ opmerkingen betreffende competentie van programmeurs, ondanks dat dat er helemaal niets mee te maken heeft.

      • Ten eerste: dependencies zijn altijd wenselijk.….het hebben van veel dependencies is wederom wenselijk

        Goed dat je ook de andere kant van het verhaal laat horen, maar volgens mij sla je compleet door: er zitten technisch nogal wat bezwaren aan dependencies en er is veel voor te zeggen om het aantal dependencies te beperken; zowel per module, per laag, als voor een gehele applicatie (vooral harde dependencies). Bij iedere extra (gebruikte) interface zou je je moeten afvragen of de voordelen wel opwegen tegen de nadelen. Daarnaast kunnen er ook nog bezwaren zijn vanuit de marktverhoudingen of vanwege juridische aspecten.

        • Daar gaat het nu juist om – mijn opmerking dat dependencies wenselijk zijn is uitdrukkelijk vanuit de aanname dat de technische bezwaren niet bestaan. Waarom? Omdat dat een nuttige ‘baseline’ levert m.b.t. het oplossen van die technische problemen. Pas als je kunt zeggen “we willen eigenlijk X, maar…”, heb je een zinnig uitgangspunt om de problemen in kwestie verhelpen.

          Dit is extra belangrijk omdat het dependency-model van Node.js/NPM nu juist ontworpen wordt met de bedoeling om dergelijke bezwaren zoveel mogelijk te verhelpen, en het is derhalve ook extra stuitend dat de post van Haney daar volledig aan voorbij gaat.

          Om maar even wat veel genoemde beperkingen te herzien:

          • Juridische bezwaren – Geen punt als je vooraf een set acceptabele licenties vast stelt (bijv. enkel permissive open-source licenties). NPM lost dit op door de licentie als computer-leesbaar veld in de package.json op te slaan. Er zijn meerdere ‘auditing tools’ en diensten om dependencies met onwenselijke licenties buiten de deur te houden.
          • Afhankelijkheid – Deze is bij kleine dependencies vele malen kleiner dan bij grote dependencies – minder kans op implicit dependencies binnen de dependency zelf, geen tight coupling, makkelijk te auditen, makkelijk te lezen, makkelijk te fixen en beheren. Ook wanneer je het tegenover “roll your own” stelt, winnen third-party dependencies al snel – ‘interne’ modules worden bijna zonder uitzondering spaghettisoep door de jaren heen omdat er allerlei niet-generieke aannames en fouten gemaakt worden, en dus heb je al snel een voordeel bij het afhankelijk zijn van een derde partij, zelfs als het af en toe fout gaat.
          • Dependency conflicts – In veel talen een probleem, en een bijzonder sterke reden om geen kleine dependencies te gebruiken – echter volledig irrelevant voor Node.js, daar die met ‘nested, project-local dependencies’ werkt, waarbij een dependency conflict letterlijk technisch onmogelijk is. De enige uitzondering daarbij zijn peer dependencies (voor plugin-gebaseerde systemen), en dat zijn doorgaans sowieso de essentiele dependencies waar je niet zonder kunt.
          • Audit surface – Vaak genoemd als nadeel, maar is het niet. Wegens het gebrek aan tight coupling en de hoge graad van hergebruik is het zeer moeilijk om dubieuze code in dependencies te verstoppen, en wordt de hoeveelheid code die uberhaupt ge-audit moet worden, sterk verminderd. Zeker in combinatie met shrinkwrap. Het is niet het aantal modules of regels code waardoor audits duurder/moeilijker worden, maar de complexiteit en de subtiele verschillen tussen implementaties.

          Als je meer problemen ziet hoor ik ze graag, maar in de praktijk zijn de nadelen in het dependency model van Node.js miniem, zeker tegenover de voordelen ervan. Ik erger me er dan ook regelmatig aan dat andere talen aan brakke dependency-modellen vast blijven houden (global dependencies, ‘platte’ dependency-structuur, enz.).

          • Moet bekennen dat ik weinig van node.js weet en er geen ervaring mee heb, maar wat ik ervan begrijp is dat npm er onderdeel van is en iedere kleine dependency blijkbaar je applicatie kan laten omvallen. Ik begrijp uit je bijdrage dat dit niet altijd een probleem hoeft te zijn, maar het voorbeeld met kik geeft aan dat het ook gigantisch mis kan gaan. Dit risico kan best acceptabel zijn, maar dat lijkt me erg afhankelijk van de applicatie. Bovendien is een module met veel afhankelijkheden ook erg lastig om in isolatie te testen. Als de afhankelijkheden van heel hoge kwaliteit zijn is dat al minder een probleem, maar als er meerdere modules ontwikkeld moeten worden, wil je die onafhankelijk van elkaar kunnen testen en om (veel) dependencies dan als voordelen te presenteren gaat me ver. Een ander punt is dat het moeilijker kan worden (delen van) je code/logica naar andere platformen te porten/vertalen. Verder is het veelal handig dependencies te beperken tot 1 richting: GUI wel afhankelijk van de business logica, maar niet andersom.

            • Moet bekennen dat ik weinig van node.js weet en er geen ervaring mee heb, maar wat ik ervan begrijp is dat npm er onderdeel van is en iedere kleine dependency blijkbaar je applicatie kan laten omvallen.

              Dat is nu precies het punt wat ik aandroeg in mijn originele reactie: het probleem dat ten grondslag ligt aan het Kik-debacle is de infrastructuur, niet het hebben van veel dependencies. Zodra de infrastructuur gefixt wordt, zit hier dus totaal geen risico meer in.

              Betreffende de scenarios die je noemt:

              Testen – Het in isolatie testen van modules is doorgaans niet iets dat je zelf doet – iedere module kan zijn eigen setje met tests hebben die de gehele API surface testen. Verder heb je met de interne werking van die modules helemaal niets te maken, dat is juist het punt van loose coupling; je maakt je enkel druk over de API die de module beschikbaar maakt, en alles wat er op een lager niveau foutgaat is niet jouw probleem.

              Ook test-commando’s staan opgeslagen in de package.json, en dus kun je vrij eenvoudig alle modules weigeren die geen tests bevatten. Is er een probleem met de module (bijv. ontbrekende tests) en fixt de upstream het niet, dan is het triviaal om het zelf te forken en je eigen tests te schrijven.

              Netto is het alleen maar makkelijker om te testen met kleine modules, omdat de modulaire structuur van nature al individueel testbare ‘units’ oplevert per module. Dat is bij tightly coupled / monolitische code niet het geval.

              Porten – Wederom maken veel kleine dependencies dit alleen maar makkelijker. Door de loose coupling zijn impliciete dependencies veel minder (of zelfs helemaal niet) aanwezig, en bestaat je code dus echt alleen nog maar uit het implementeren van je business requirements – en dus kun je zeer gemakkelijk de code naar een andere taal porten, omdat je enkel gelijkwaardige dependencies hoeft te vinden, en niet door bergen aan workarounds en aannames heen hoeft te werken. Makkelijker leesbare code is ook makkelijker port-bare code.

              Je laatste argument – “Verder is het veelal handig dependencies te beperken tot 1 richting” – is me niet geheel duidelijk.

              • Bedankt voor je uitleg over de manier van werken bij Node.js/NPM.

                Wat zou er dan moeten veranderen aan de infrastructuur om dit probleem op te lossen? Zoals ik al eerder schreef, den ik dat het in ieder geval nodig is dat iedereen zijn eigen kopie bijhoudt van dependencies, en die niet automatisch op produktie-systemen updatet, zodat je niet automatisch upstream regressies mee krijgt.

                Daarnaast (of in plaats daarvan?) zou je upstream regressies tegen moeten gaan. Hoe doe je dat? In principe kan elke wijziging tot een regressie leiden. Het probleem wordt misschien kleiner als je nieuwe code altijd door alle oude(!) test-suites laat controleren, maar test suites kunnen nooit alle use cases dekken, dus dit garandeert niet dat er nooit regressies zijn.

                Je zou ook altijd alle oude revisies beschikbaar kunnen houden. Dat lost ook niet alles op, want vaak heb je juist een reden om te willen upgraden. Daarnaast, en nu wordt het interessant en on-topic, zou je tegen juridische problemen aan kunnen lopen. In dit geval was de juridische klacht nogal twijfelachtig, maar wat als er een module is die auteursrechten schendt of een gepatenteerd algoritme implementeert? Moet zo’n module dan verwijderd kunnen worden, met allerlei regressies als resultaat? Bij een auteursrechtenschending zou je een module kunnen vervangen door een “schone” her-implementatie, maar bij gepatenteerde algoritmes zou dat zomaar onmogelijk kunnen zijn. Moet je infrastructuur dan maar peer-to-peer zijn, om de wet buiten spel te zetten?

                • Wat zou er dan moeten veranderen aan de infrastructuur om dit probleem op te lossen?

                  Aan de kant van NPM: packages moeten volledig ‘immutable’ worden – dat wil zeggen:

                  1) Ze kunnen nooit verwijderd worden.

                  2) Als er dan toch een reden is om een package te verwijderen (zie volgende antwoorden), mag de package-naam nooit hergebruikt worden. Eens weg blijft weg.

                  Zoals ik al eerder schreef, den ik dat het in ieder geval nodig is dat iedereen zijn eigen kopie bijhoudt van dependencies,

                  Dat ligt echter aan de kant van de gebruiker, en dat kan al met Sinopia.

                  Daarnaast (of in plaats daarvan?) zou je upstream regressies tegen moeten gaan. Hoe doe je dat? In principe kan elke wijziging tot een regressie leiden. Het probleem wordt misschien kleiner als je nieuwe code altijd door alle oude(!) test-suites laat controleren, maar test suites kunnen nooit alle use cases dekken, dus dit garandeert niet dat er nooit regressies zijn.

                  Dit is niet automatisch op te lossen, ongeacht je dependency model. De enige oplossing hiervoor is om een update-beleid in te stellen waar je shrinkwrap gebruikt om alle versies vast te zetten, en bij het verschijnen van een update direct een audit doet en (als er geen regressies zijn) de update door te voeren. Dit is al mogelijk.

                  Je zou ook altijd alle oude revisies beschikbaar kunnen houden.

                  Dat is sowieso nodig, en is een onderdeel van immutable packages. Packages op NPM kunnen al als ‘deprecated’ gemarkeerd worden, voor bijvoorbeeld gevallen waar er een lek bekend is. Het zou beter zijn als NPM aan hun kant een speciale tag zou hebben voor lekke packages, en de package manager weigert deze te installeren tenzij de gebruiker het expliciet toelaat.

                  Daarnaast, en nu wordt het interessant en on-topic, zou je tegen juridische problemen aan kunnen lopen. In dit geval was de juridische klacht nogal twijfelachtig, maar wat als er een module is die auteursrechten schendt of een gepatenteerd algoritme implementeert? Moet zo’n module dan verwijderd kunnen worden, met allerlei regressies als resultaat? Bij een auteursrechtenschending zou je een module kunnen vervangen door een “schone” her-implementatie, maar bij gepatenteerde algoritmes zou dat zomaar onmogelijk kunnen zijn. Moet je infrastructuur dan maar peer-to-peer zijn, om de wet buiten spel te zetten?

                  Wat mij betreft wel. Dit is wederom het zoveelste voorbeeld waar wetten op ‘intellectueel eigendom’ de maatschappij schade berokkenen. Het is niet voor niets dat ik in zijn geheel tegen dergelijke wetten ageer.

                  Totdat je op P2P uitkomt, zul je (als registry) helaas soms packages moeten verwijderen. Als je als organisatie of ontwikkelaar Sinopia draait, kun je in ieder geval de schade enigszins beperken.

                    • Helaas doet de nieuwe policy dat dus absoluut niet. Het klinkt mooi, maar werken in de praktijk kan het niet.

                      Verwijdering van modules: Nog steeds een probleem. Ze beweren: “If you contact support, they will check to see if removing that version of your package would break any other installs. If so, we will not remove it.” — dit controleren is echter niet mogelijk, daar ze alleen maar de dependencies van andere modules op NPM kunnen controleren, en dat dus niet het gros van de software-projecten omvat (aangezien die doorgaans niet geupload worden naar NPM).

                      Security placeholder packages: Volslagen nutteloos. Aldus NPM, “If another member of the community wishes to publish a package with the same name as a security placeholder, they’ll need to contact support@npmjs.com. npm will determine whether to grant this request. (Generally, we will.)”. Je houdt dus hetzelfde probleem, echter kost het je nu een e-mailtje meer om bijvoorbeeld een module te vervangen door malware. De enige juiste oplossing hier is om de package name in z’n geheel permanent onbruikbaar te maken. Wat NPM hier voorstelt is slechts ‘security theater’.

                      Gezien mijn ervaringen met NPM in het verleden, durf ik wel te zeggen dat het infrastructuur-team geen flauw benul heeft waar ze mee bezig zijn, zeker niet op het gebied van beveiliging. Dit is niet het eerste incident, en ik verwacht ook niet dat deze problemen intern opgelost gaan worden.

                      • Ik linkte het slechts als toevoeging. Had er ook zo mijn bedenkingen bij. Zelf gebruik ik NPM vrijwel niet.

                        Wat je tweede punt betreft ben ik het met je eens. De controle zou opgelost kunnen worden dmv transparency. Hetzelfde geldt voor het eerste punt, maar waar jij zegt dat ze alleen controlleren tov NPM, weet ik dat zo net nog niet. Ik neem juist aan dat ze conservatief te werk gaan.

                        Waarom worden deze modules eigenlijk door een bedrijf beheerd ipv door een community? Dat is toch bij andere package managers ook niet zo? Flikker het gewoon in git ergens online. Ben je ook klaar. Of niet? Hoe is deze situatie eigenlijk ontstaan? Ik bedoel, als je niet tevreden bent met Github dan move je toch naar Gitlab of host je het zelf?

                        Want dit bedrijf neemt het blijkbaar niet op voor hun gebruikers als ze zo makkelijk zwichten (nav hun handelen bij Kik). Had ook netjes opgelost kunnen worden met meta packages en suggesties. Zo doet APT dat ook.

                        • Wat je tweede punt betreft ben ik het met je eens. De controle zou opgelost kunnen worden dmv transparency. Hetzelfde geldt voor het eerste punt, maar waar jij zegt dat ze alleen controlleren tov NPM, weet ik dat zo net nog niet. Ik neem juist aan dat ze conservatief te werk gaan.

                          De enige afdoend conservatieve oplossing zou zijn om alles met >0 downloads automatisch als “in gebruik” te zien, en hun uitleg suggereert al dat dat niet het geval gaat zijn. Zelfs iets met een enkele download per jaar kan in actief gebruik zijn. Hoe zou je dan internet-wide vast willen stellen wat nog in gebruik is?

                          Waarom worden deze modules eigenlijk door een bedrijf beheerd ipv door een community? Dat is toch bij andere package managers ook niet zo? Flikker het gewoon in git ergens online. Ben je ook klaar. Of niet? Hoe is deze situatie eigenlijk ontstaan? Ik bedoel, als je niet tevreden bent met Github dan move je toch naar Gitlab of host je het zelf?

                          NPM was van origine community-operated. Op een gegeven moment hebben ze er een bedrijf van gemaakt met de gedachte dat ze zo “beter de infrastructuur kunnen ondersteunen”. Daar heeft helaas niemand iets tegen gedaan op dat moment.

                          Een package registry is niet hetzelfde als een project host. Hosten op GitHub (zoals bijv. gebeurt met Go) is niet haalbaar; je kunt niet van host wisselen zonder een dependency te slopen (want de URL is ge-hardcode in je project), en Git repository tags/blobs zijn niet immutable, waardoor je geen semantic versioning toe kunt passen. Dat is dus geen optie, ook niet voor andere self-hosted opties. Uiteindelijk zul je ergens op een identifier moeten vertrouwen, of dat nu een package name op NPM is, of een domeinnaam.

                          Gedecentraliseerde package registries zijn moeilijk. Hoe hou je de dependency trees consistent?

                          • Wat bedoel je met “Git repository [..]blobs zijn niet immutable”? Git refereert toch naar blobs met hun SHA1sum? Als jij in je code verwijst naar een bepaalde SHA1sum van een commit/blob, weet je zeker dat je een specifieke revisie krijgt (zolang niemand SHA1 kraakt; SHA1 is een beetje een verouderde keuze).

                            Als je niet wilt verwijzen naar een specifieke revisie, maar naar “de nieuwste revisie”, dan is het inderdaad moeilijk. Er is geen geautomatiseerde manier om te garanderen dat de wijzigingen in de nieuwste revisie niets kapot maken; je zult dan altijd iemand moeten vertrouwen, of zelf handmatig alles controleren. Dat vertrouwen zou trouwens in principe wel decentraal kunnen, via een web of trust achtig systeem. Mensen zouden digitale handtekeningen kunnen zetten onder beweringen als “ik heb dit getest, en het lijkt te werken”, of “ik heb een source code audit gedaan, en geen problemen gevonden”, of “deze revisie heeft bugs”.

Laat een reactie achter

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren en <em> en <strong> voor italics en vet.

(verplicht)

Volg de reacties per RSS