Skadlig kod sprids via lömska Github-länkar

Det finns många problem idag.

Ta en simpel sak som att jämföra förändring i XML filer, se vilka förändringar som har skett. Vid pytteliten förändring så ta vilken filecompare som helst, men vid större hur gör man då?

1: Utför kontrollen manuellt, vilket tar lång tid.
2: Kodar ihop något, vilket säkert tar tio gånger så lång tid som alternativ 1. (man hoppas på att det går återanvända)
3: Man laddar hem något som ofta inte är väldigt pålitlig källa som ett githubb projekt.
4: Man laddar upp .csv filerna till någon av dessa hundratals webtjänster som man får upp när man googlar.

Om vi tar den generella utvecklaren som ej jobbar med någon superhemligt, men ändå inget som är helt offentligt. Så gissar jag många väljer alternativ 3 och 4, vilket innebär att den sparar tid för dens risker den tar med att slarva med hanteringen av andras data.

Vore det verkligen det? Publicerad, visst. Men vem ska sitta och granska varje kommentar som postas på GitHub för att verifiera att den inte innehåller skadliga filer?

Ser inte heller hur föreställningar om "utvecklaren vars projekt kommenterats på" kan gå ihop med konceptet fri mjukvara med öppen källkod, som ju ändå får anses vara ett huvudsyfte med GitHub.

ja, om någon lägger upp en kommentar med en fil på mitt projekt, som antagligen är riktat till de som aktivt arbetar på projektet. och de kan ju då godkänna kommentaren? visst är ju då utvecklaren kanske utsatt för risk men om kommentaren ska innehålla en crashdump eller liknande och där är en PDF eller EXE i arkivet kan man ju ana ugglor i mossen, och blockera kommentaren.

varför ska filen ha publik åtkomst utan någon inloggning alls? vill man dela filer publikt med github som nån sorts "free hosting" så får man väl göra ett repo, inte gömma filer i kommentarer "unlisted" som man sedan sprider vidare till kompisar istället för att använda dropbox/gdrive/annat.

är väl rimligt? förhindrar inte någon som inte är med i teamet att forka eller skicka merge request eller vad det heter t.ex.
så hindrar inte opensource alls.

vara inloggad på github och neka all åtkomst utan credentials vore ju minimum oavsett. speciellt från en icke-publicerad kommentar, den filen ska ju vara privat, då. eller tänker jag fel?

Ingen tvivlar på att felet är lätt att fixa när det väl uppdagas. Problemet är fel som ännu ej är upptäckta. Som det här fram till nyligen.

En kommentar behöver inte nödvändigtvis vara riktad endast till aktiva maintainers, och det är inte alla projekt som har aktiva maintainers. Men förstår mer hur du menar nu.

Att den ska ha det tycker jag bör vara utgångspunkten – från användarens perspektiv är det rejält tröttsamt med den typen av artificiella inloggningskrav. Många forum har ju det så, men det är väl pga begränsade resurser och kanske för att locka till registrering. Inget av de argumenten känns försvarligt i GitHubs fall.

Ja, så ska man givetvis inte göra. Men det är inte uppenbart för mig att lösningen är att kräva inloggning för att se bifogade filer.

Nä, men i OSS ingår ju i praktiken även att kunna delta i diskussioner om mjukvaran, vilket var vad jag menade med min invändning mot förslaget att bara uppladdaren eller projektets maintainer(s) borde kunna ladda ner filen.

Håller inte med om att man nödvändigtvis ska behöva vara inloggad för att se bifogade filer (se ovan), men håller med om att filen inte borde finnas tillgänglig om inte kommentaren den hör till gör det. När jag funderade kring det insåg jag emellertid att det nog inte är trivialt att implementera det på ett bra sätt i praktiken.

Slutligen vill jag be om ursäkt för att mitt förra inlägg lät betydligt bistrare än det lät i mitt huvud när jag skrev det.

Steg ett är väl för github att inte serva länkar till https://github.com/XXXX/YYYY/files/ZZZZZ där referern inte är en github-kommentar.

Vad har det här med tråden att göra? Var GitHub det enda du läste??

Men om du inte har väldigt stora XML-filer är det där inte så värst svårt problem, och det borde inte ta så lång tid att skriva en rekursiv jämförelse.