Gå til innhold

Utvikler saboterte egne, mye brukte Javascript-biblioteker


Anbefalte innlegg

Videoannonse
Annonse

Kan nok skyldes litt dårlig mental helse. I følge New York Post at han forårsaket en brann i forsøk på å lage en bombe i 2020 og lar ikke sønnen leke ute. Han forklarte ikke bakgrunnen til at leiligheten brant på twitter og ba om penger, derfor tror jeg det er samme person.

Det er bra at det var enkelt å rydde opp med å bare rulle tilbake en versjon og midlertidig sperre tilgangen for å avgrense skadepotensialet. Denne typen risiko tenker jeg man må ha et bevisst forhold til og håndtere på en grei måte.

Ref:  https://nypost.com/2020/09/16/resident-of-nyc-home-with-suspected-bomb-making-materials-charged/

Endret av tovare
Redigerte for å konsolidere kommentar.
  • Innsiktsfullt 1
Lenke til kommentar

Det er viden kjent at dersom en  bruker andres kildekode uten noen form for koderevidering må man regne med at uønskede ting kan skje. Dette er et ikke-problem.

Det jeg derimot reagerer på er Github sin praksis i å kaste personen ut av sitt eget repository.

Det kan kanskje hende at vilkårene til Github er brutt, men det bekrefter bare nok en gang at Github ikke er et seriøst sted jeg ønsker å publisere min kode hos.

  • Innsiktsfullt 1
Lenke til kommentar
Andreas328328 skrev (4 minutter siden):

Det kan kanskje hende at vilkårene til Github er brutt, men det bekrefter bare nok en gang at Github ikke er et seriøst sted jeg ønsker å publisere min kode hos.

Nå skjønner jeg ikke helt. Skal man ikke kaste ut d som saboterer og bryter egne retningslinjer? Hvorfor er det useriøst?

  • Liker 1
Lenke til kommentar
Nimrad skrev (1 time siden):

Nå skjønner jeg ikke helt. Skal man ikke kaste ut d som saboterer og bryter egne retningslinjer? Hvorfor er det useriøst?

Jeg forstår argumentasjonen fra begge sider, men er mest enig med @Andreas328328 her. 

De to aktuelle pakkene burde nok blitt sperret fra npmjs, men å nekte ham tilgang til samtlige repos, virker overdramatisk for meg. 

PS: Jeg antar bedrifter ikke installerer nye pakker rett i prod? Ergo er det vel noe begrenset skadepotensiale her. Ja, han har nok irritert på seg en utvikler eller tre, siden koden man jobber på lokalt (evnt via en test-server) slutter å fungere. Men det bør være ganske begrenset antall bedrifter som har klart å få dette ut i produksjonsmiljøene sine. 

(Ikke at jeg bifaller eller støtter aksjonsformen på noen måte. Nei, nix og jnet. Jeg synes bare ikke det var så veldig alvorlig. Mest barnslig...)

  • Liker 2
Lenke til kommentar
13 hours ago, Andreas328328 said:

Det kan kanskje hende at vilkårene til Github er brutt, men det bekrefter bare nok en gang at Github ikke er et seriøst sted jeg ønsker å publisere min kode hos.

Github kan aldri vinne. Hvis dette hadde vist seg å være et tilfelle av en hacket konto, og det ikke var den originale utvikleren som hadde gjort endringene og GitHub IKKE hadde sperret kontoen slik at flere av prosjektene kunne blitt sabortert. Så hadde jo det blitt feil og "at Github ikke er et seriøst sted jeg ønsker å publisere min kode hos".

Kall meg naiv, men jeg velger å tro at Github sperret kontoen for å hindre evt mer sabotasje fra andre enn utvikleren selv.

Lenke til kommentar
hanlan skrev (3 timer siden):

Github kan aldri vinne. Hvis dette hadde vist seg å være et tilfelle av en hacket konto, og det ikke var den originale utvikleren som hadde gjort endringene og GitHub IKKE hadde sperret kontoen slik at flere av prosjektene kunne blitt sabortert. Så hadde jo det blitt feil og "at Github ikke er et seriøst sted jeg ønsker å publisere min kode hos".

Kall meg naiv, men jeg velger å tro at Github sperret kontoen for å hindre evt mer sabotasje fra andre enn utvikleren selv.

Det fremgår av enhver Open Source lisens at utgiver kan aldri holdes juridisk ansvarlig for hvordan programvaren fungerer eller ikke fungerer.

Hvis du kombinerer dette med at GitHub er laget for å tracke enhver endring, og for å rulle tilbake enhver endring utført med vilje eller uvilje, og at ethvert selskap med et snev av sikkerhetskrav alltid gjør koderevidering av ekstern kode, er sabotasje/hacking irrelevant.

En utgiver av open source kan også når som helst velge å legge inn bakdører i sin egen kode. Det er deres fulle rett.

Nytteverdien av slik kode er derimot ikke spesielt høy, og repositorier med slik kode ville fått dårlig rating/kommentarer da.

 

Lenke til kommentar

GitHub sin Terms of Service og Acceptable Use Policies er lett leselig og forståelig.

Det er for min egen del lett å se flere brudd denne brukeren har gjort seg skyldig i.

GitHub er styrt av en Kardemommeby lov hvor politmester Sebastian er byttet ut med General Sod som til syvende og sist vurderer om du har plaget noen eller vært snill og grei.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...