mboost-dp1
Claus Jørgensen (1) skrev:Kan i huske dengang hvor alle sagde at der ikke var nogle sårbarheder i Linux?
r/agedlikemilk lulz
Jeps. Var det ikke også noget med at Linux også fik et kæmpe angreb et for et par år siden som kunne udnyttes til at skrive i BIOS'en, kernel eller på boot sektoren? Den havde i hvertfald direkte adgang til al CPU'en uden om alle sikkerhedsmekanismer, så vidt jeg husker. Og jeg mener også, at der blev skrevet om det her på siden. Hvad gik det ud på?
Jeg er dog lidt usikker pga min hukommelse. Sorry guys :)
Det må vel betyde, at der findes intet system der er sikkert, så længe det er koblet på internettet?
Sårbarhederne der rammer/også rammer Linux, er er ofte i blackboxes, firmware/binære blobs, og i hardware. Det er svært at bygge sikkerhed omkring noget man ikke har source til.
Når det er dele af kernel der er usikker, bliver det som regel fundet og rettet enormt hurtigt, grundet de mange øjne der er på koden.
At være processor kritisk er altid en god idé. Der findes ikke ret meget hardware der er fuldt åbent, men SiFive laver RISC-V SoC'ere som kunne blive interessante til en telefon med mere åbent hardware (selv om der nok er noget vej endnu).
Ellers er det i øjeblikket AMD på PC-markedet der er mest åbent (software). De har vidst stadigvæk enkelte lukkede firmware blobs, men på alle andre fronter, er de både hjælpsomme med dokumentation, og med udvikling af åbne drivere til både CPU og GPU.
Med andre ord, hvis man har en PC der kører Linux, har man større potentiale for at opnå bedre sikkerhed med AMD, end med intel/mVidia.
Når det er dele af kernel der er usikker, bliver det som regel fundet og rettet enormt hurtigt, grundet de mange øjne der er på koden.
At være processor kritisk er altid en god idé. Der findes ikke ret meget hardware der er fuldt åbent, men SiFive laver RISC-V SoC'ere som kunne blive interessante til en telefon med mere åbent hardware (selv om der nok er noget vej endnu).
Ellers er det i øjeblikket AMD på PC-markedet der er mest åbent (software). De har vidst stadigvæk enkelte lukkede firmware blobs, men på alle andre fronter, er de både hjælpsomme med dokumentation, og med udvikling af åbne drivere til både CPU og GPU.
Med andre ord, hvis man har en PC der kører Linux, har man større potentiale for at opnå bedre sikkerhed med AMD, end med intel/mVidia.
Claus Jørgensen (7) skrev:#6
Android er fyldt med sikkerhedshuller, be it hardware or software.
Og en hardware fejl der tillader software installation er stadigvæk en fejl der kunne løses med software i sidste ende.
I know. Men i dette tilfælde er det logisk set hardwaren og ikke styresystemet. Der er altid fejl i alt indenfor IT teknologi.
Claus Jørgensen (7) skrev:#6
Android er fyldt med sikkerhedshuller, be it hardware or software.
Og en hardware fejl der tillader software installation er stadigvæk en fejl der kunne løses med software i sidste ende.
Er Android det?
Eller giver Android bare flere muligheder for at skyde sig selv i foden fordi brugeren ikke er låst til én appstore?
Bortset fra specielle exploits som beskrevet her mener jeg ikke at Android apps bare lige kan bryde ud af deres container eller tilegne sig ekstra permissions.
linos (5) skrev:Sårbarhederne der rammer/også rammer Linux, er er ofte i blackboxes, firmware/binære blobs, og i hardware. Det er svært at bygge sikkerhed omkring noget man ikke har source til.
Når det er dele af kernel der er usikker, bliver det som regel fundet og rettet enormt hurtigt, grundet de mange øjne der er på koden.
At være processor kritisk er altid en god idé. Der findes ikke ret meget hardware der er fuldt åbent, men SiFive laver RISC-V SoC'ere som kunne blive interessante til en telefon med mere åbent hardware (selv om der nok er noget vej endnu).
Ellers er det i øjeblikket AMD på PC-markedet der er mest åbent (software). De har vidst stadigvæk enkelte lukkede firmware blobs, men på alle andre fronter, er de både hjælpsomme med dokumentation, og med udvikling af åbne drivere til både CPU og GPU.
Med andre ord, hvis man har en PC der kører Linux, har man større potentiale for at opnå bedre sikkerhed med AMD, end med intel/mVidia.
Hørt
Claus Jørgensen (1) skrev:Kan i huske dengang hvor alle sagde at der ikke var nogle sårbarheder i Linux?
r/agedlikemilk lulz
oh noes
hvis blot microsoft havde skrevet linux som et closed source styresystem i stedetfor
Så længe et styresystem kun har en lille markedsandel, så er der ikke ret mange der kigger efter sikkerhedshuller.
Men lige så snart markedsandelen stiger, bliver der mere fokus på sikkerheden. Eksempel er mængden af skadelig software til MacOS/OS X kraftig stigende.
Apple forsøger dog at komme rundt om det med, at alle programmer/apps skal hentes igennem deres Store.
Linux burde være nemmer, at finde sikkerhedshuller og rette da kildekoden er åben. (Det er nu en gang bøvlet at arbejde med bind for øjnene)
Men lige så snart markedsandelen stiger, bliver der mere fokus på sikkerheden. Eksempel er mængden af skadelig software til MacOS/OS X kraftig stigende.
Apple forsøger dog at komme rundt om det med, at alle programmer/apps skal hentes igennem deres Store.
Linux burde være nemmer, at finde sikkerhedshuller og rette da kildekoden er åben. (Det er nu en gang bøvlet at arbejde med bind for øjnene)
#16
At rette sikkerhedshuller er ligeså svært med open source som closed source. Fordi dem som er ansvarlig for at rette fejlen har jo adgang til koden alligevel.
Og Android har også en app-store, ikke at det har hjulpet dem. Ligesom på Windows er størstedelen af usikkerhederne i userland, så at Android kører på Linux hjælper absolut nul mod sikkerhedshuller.
At rette sikkerhedshuller er ligeså svært med open source som closed source. Fordi dem som er ansvarlig for at rette fejlen har jo adgang til koden alligevel.
Apple forsøger dog at komme rundt om det med, at alle programmer/apps skal hentes igennem deres StoreKun til iOS. MacOS som desktop har en del sårbarheder (og Apple er typisk langsommere end Microsoft til at rette fejlene)
Og Android har også en app-store, ikke at det har hjulpet dem. Ligesom på Windows er størstedelen af usikkerhederne i userland, så at Android kører på Linux hjælper absolut nul mod sikkerhedshuller.
Claus Jørgensen (17) skrev:#16
At rette sikkerhedshuller er ligeså svært med open source som closed source. Fordi dem som er ansvarlig for at rette fejlen har jo adgang til koden alligevel.Apple forsøger dog at komme rundt om det med, at alle programmer/apps skal hentes igennem deres StoreKun til iOS. MacOS som desktop har en del sårbarheder (og Apple er typisk langsommere end Microsoft til at rette fejlene)
Og Android har også en app-store, ikke at det har hjulpet dem. Ligesom på Windows er størstedelen af usikkerhederne i userland, så at Android kører på Linux hjælper absolut nul mod sikkerhedshuller.
Det sker desværre alt for ofte at sikkerhedsbrister stammer fra dårlig kode, og ved closed source er det de samme folk som lavede fejlen, der kommer til at rette den, og det er typisk efter at en brist allerede har været fundet og udnyttet.
Linus plejer at rykke folk fra hinanden, hvis de forsøger på at få middelmådig kode med i Linux kernelen.
Koden i Linux kernelen bliver reviewet af mange, i hele tiden, og bliver konstant opdateret med mange idéer og optimiseringer - det samme kan ikke siges om closed source. Det er garanteret ikke altid dårlig kode, det er nok oftere godt, end dårligt, men det er typisk skrevet af en mindre gruppe af folk, der alle anskuer koden fra deres lille verden/niche/synspunkt.
Claus Jørgensen (17) skrev:#16
At rette sikkerhedshuller er ligeså svært med open source som closed source. Fordi dem som er ansvarlig for at rette fejlen har jo adgang til koden alligevel.Apple forsøger dog at komme rundt om det med, at alle programmer/apps skal hentes igennem deres StoreKun til iOS. MacOS som desktop har en del sårbarheder (og Apple er typisk langsommere end Microsoft til at rette fejlene)
Og Android har også en app-store, ikke at det har hjulpet dem. Ligesom på Windows er størstedelen af usikkerhederne i userland, så at Android kører på Linux hjælper absolut nul mod sikkerhedshuller.
Det sker desværre alt for ofte at sikkerhedsbrister stammer fra dårlig kode, og ved closed source er det de samme folk som lavede fejlen, der kommer til at rette den, og det er typisk efter at en brist allerede har været fundet og udnyttet.
Linus plejer at rykke folk fra hinanden, hvis de forsøger på at få middelmådig kode med i Linux kernelen.
Koden i Linux kernelen bliver reviewet af mange, i hele tiden, og bliver konstant opdateret med mange idéer og optimiseringer - det samme kan ikke siges om closed source. Det er garanteret ikke altid dårlig kode, det er nok oftere godt, end dårligt, men det er typisk skrevet af en mindre gruppe af folk, der alle anskuer koden fra deres lille verden/niche/synspunkt - derfor er faren for at de overser en angrebsvinkel, større.
#23 Det kommer da i høj grad and på hvilke områder du snakker om her.
Ja, i det meste open source, er det de samme devs/maintainers der skriver deres respektive områder af et program, men hvis du ser på kernel, er der mange forskellige personer og virksomheder der kommitter kode. Ja, det bliver typisk endegyldigt tilføjet efter at primært Linus, eller Greg har reviewet koden, men det laver ikke om på at det er andre der har skrevet den i første omgang. Men du har selvfølgelig ret i at meget andet software skrives af et lille hold, men meget af den software bliver læst af andre og modificeret/forked. Alt der er kritisk for et helt funktionelt (GNU/)Linux OS, er med garanti set igennem af mange flere øjne, med meget bredere perspektiv, end nogen anden closed source software.
I Linux kernel, vil jeg påstå at størstedelen af koden der tilføjes, bliver skrevet af andre end maintainers. I det meste andet software, er det primært maintainers der skriver koden. Men igen - de kritiske dele, og især ting der har med sikkerhed og privacy, bliver gransket under mange forstørrelsesglas. Det sker ikke i samme grad med closed source.
Du har ret i at det meget sandsynligt er personen der har lavet en fejl, som kommer til at rette den ved open source også, men forskellen er stadig at det vil blive gennemset af mange øjne, så man kan være ret sikker på at fikset er lavet ordentligt - men du aner ikke hvad du har med at gøre i closed source, I'm fejlrettelsen er et plaster på et plaster, på en bandage, eller om det er en rettelse der er solidt integreret i softwaren.
På hvilke områder er Linux og Windows stort set identiske?
Ja, i det meste open source, er det de samme devs/maintainers der skriver deres respektive områder af et program, men hvis du ser på kernel, er der mange forskellige personer og virksomheder der kommitter kode. Ja, det bliver typisk endegyldigt tilføjet efter at primært Linus, eller Greg har reviewet koden, men det laver ikke om på at det er andre der har skrevet den i første omgang. Men du har selvfølgelig ret i at meget andet software skrives af et lille hold, men meget af den software bliver læst af andre og modificeret/forked. Alt der er kritisk for et helt funktionelt (GNU/)Linux OS, er med garanti set igennem af mange flere øjne, med meget bredere perspektiv, end nogen anden closed source software.
I Linux kernel, vil jeg påstå at størstedelen af koden der tilføjes, bliver skrevet af andre end maintainers. I det meste andet software, er det primært maintainers der skriver koden. Men igen - de kritiske dele, og især ting der har med sikkerhed og privacy, bliver gransket under mange forstørrelsesglas. Det sker ikke i samme grad med closed source.
Du har ret i at det meget sandsynligt er personen der har lavet en fejl, som kommer til at rette den ved open source også, men forskellen er stadig at det vil blive gennemset af mange øjne, så man kan være ret sikker på at fikset er lavet ordentligt - men du aner ikke hvad du har med at gøre i closed source, I'm fejlrettelsen er et plaster på et plaster, på en bandage, eller om det er en rettelse der er solidt integreret i softwaren.
På hvilke områder er Linux og Windows stort set identiske?
#24
Jeg gætter på at du ikke er professionel udvikler hvis du tror kernel udvikling ikke er relativ ens.
Og du lader heller ikke til at have erfaring med code reviews (som alle større virksomheder bruger), fordi
er ikke sandt. Kernel udvikling hos Microsoft bliver også gennemset af utrolig mange mennesker.
Jeg gætter på at du ikke er professionel udvikler hvis du tror kernel udvikling ikke er relativ ens.
Og du lader heller ikke til at have erfaring med code reviews (som alle større virksomheder bruger), fordi
Alt der er kritisk for et helt funktionelt (GNU/)Linux OS, er med garanti set igennem af mange flere øjne, med meget bredere perspektiv, end nogen anden closed source software.
er ikke sandt. Kernel udvikling hos Microsoft bliver også gennemset af utrolig mange mennesker.
Og Open Source i sig selv betyder intet for sikkerhed, bare se https://newz.dk/brave-indsaettter-reklamelinks-i-b...
Jeg vil faktisk vove at påstå at open source projekter generelt har mindre seriøse code-reviews end hos professionelle virksomheder. Store projekter som Linux kernen er "exception to the rule" så at sige.
Jeg vil faktisk vove at påstå at open source projekter generelt har mindre seriøse code-reviews end hos professionelle virksomheder. Store projekter som Linux kernen er "exception to the rule" så at sige.
#26:
du griber en masse holdninger ud af den blå luft og lader som om de er fakta
ja det kan være underholdende men det er hvad jeg vil kalde for en trolde teknik
men ok
ikke fordi at det ikke kan være temmelig sjovt
....
ms er forresten officielt glade for open source...
uofficielt er det embrace extend extinguish
spyware must prevail at all costs
....
jeg har engang arbejdet med vindmølle software og derfor er jeg vind guru og kan udtale mig skråsikkert om alt der smager af vind
sig mig du store ms guru, hvorfor har dine helte ved ms ikke frigivet den ikke/mindre spyware inficerede lts udgave af win 10 til masserne?
du griber en masse holdninger ud af den blå luft og lader som om de er fakta
ja det kan være underholdende men det er hvad jeg vil kalde for en trolde teknik
men ok
ikke fordi at det ikke kan være temmelig sjovt
....
ms er forresten officielt glade for open source...
uofficielt er det embrace extend extinguish
spyware must prevail at all costs
....
jeg har engang arbejdet med vindmølle software og derfor er jeg vind guru og kan udtale mig skråsikkert om alt der smager af vind
sig mig du store ms guru, hvorfor har dine helte ved ms ikke frigivet den ikke/mindre spyware inficerede lts udgave af win 10 til masserne?
#27
Du er ikke programmør, og har aldrig arbejdet på store projekter, så du har nul erfaring med open eller closed source udvikling.
Så ingen af dine holdninger er relevante, da de ikke er baseret i virkeligheden.
Og hvis nogle troller, så er det dig. Alt hvad du siger er løgn og latin.
Du er ikke programmør, og har aldrig arbejdet på store projekter, så du har nul erfaring med open eller closed source udvikling.
Så ingen af dine holdninger er relevante, da de ikke er baseret i virkeligheden.
Og hvis nogle troller, så er det dig. Alt hvad du siger er løgn og latin.
Claus Jørgensen (26) skrev:Og Open Source i sig selv betyder intet for sikkerhed
Her er et mod-eksempel der piller din påstand fra hinanden:
AES.
Al moderne kryptering er baseret på open source algoritmer som eksperter konstant prøver at pille fra hinanden.
Men ih, jo, Microsoft kunne da nok have banket en closed source super sikker algoritme sammen som vi alle bare skulle acceptere med bind for øjnene, for de er jo så professionelle. LAN manager hash. Need I say more.
#29
At algoritmerne er åbne betyder jo ikke at implementeringerne er sikre. Der altid konstant fejl i implementering af kryptering.
Og du er ikke særlig god til at læse. Jeg sikker ikke at open source gør ting usikre, jeg siger at de ikke er MERE sikre end closed source.
Specielt da størstedelen af udviklerne på "vigtige" open source projekter er ansat i den private sektor alligevel.
Men det er jo lidt meget at forvente at en folk sysadmins uden programmeringserfaring ved noget som helst om software udvikling.
At algoritmerne er åbne betyder jo ikke at implementeringerne er sikre. Der altid konstant fejl i implementering af kryptering.
Og du er ikke særlig god til at læse. Jeg sikker ikke at open source gør ting usikre, jeg siger at de ikke er MERE sikre end closed source.
Specielt da størstedelen af udviklerne på "vigtige" open source projekter er ansat i den private sektor alligevel.
Men det er jo lidt meget at forvente at en folk sysadmins uden programmeringserfaring ved noget som helst om software udvikling.
Claus Jørgensen (30) skrev:Jeg sikker ikke at open source gør ting usikre, jeg siger at de ikke er MERE sikre end closed source.
Her er en closed source password wallet fra en stor professional virksomhed som f.eks. Microsoft (eller Facebook).
Her er en open source password wallet med mange år på bagen og et godt rygte.
Hvor gemmer du dine passwords?
#31
Ret dårligt eksempel, hvis min password wallet skal hostes online vil jeg hellere se Microsoft hoste det end en tilfældigt hjemmeside hosted af en nørd fra hans mors kælder (aka. CBM)
Brave er et bedre eksempel. En Open Source version af Chromium som bildte alle folk ind at den var privatlivs orienteret, og så viser det sig at de har kode checket ind der indsætter reklamer.
Open Source hjalp slet ikke her (fordi at fejlen blev opdaget af en slutbruger, ikke ved code-inspection)
Ret dårligt eksempel, hvis min password wallet skal hostes online vil jeg hellere se Microsoft hoste det end en tilfældigt hjemmeside hosted af en nørd fra hans mors kælder (aka. CBM)
Brave er et bedre eksempel. En Open Source version af Chromium som bildte alle folk ind at den var privatlivs orienteret, og så viser det sig at de har kode checket ind der indsætter reklamer.
Open Source hjalp slet ikke her (fordi at fejlen blev opdaget af en slutbruger, ikke ved code-inspection)
Claus Jørgensen (28) skrev:#27
Du er ikke programmør, og har aldrig arbejdet på store projekter, så du har nul erfaring med open eller closed source udvikling.
Så ingen af dine holdninger er relevante, da de ikke er baseret i virkeligheden.
Og hvis nogle troller, så er det dig. Alt hvad du siger er løgn og latin.
lol
nej jeg har da slet ikke arbejdet som systemudvikler siden 2007
ROTFLMFAO
Claus Jørgensen (34) skrev:#33
At du sidder og skriver små scripts i perl hele dagen uden nogle kollegaer giver dig altså ingen viden eller erfaring om faktisk udvikling.
c,c++,delphi,java,perl,php,js er de sprog jeg arbejder mest med
nogle opgaver er scripts andre er ny funktionalitet eller bugfix til eksisterende software (desktop, web, whatever the case may be)
#35
Proving my point. Du sider åbenlyst ikke og arbejder specialiseret på et produkt med mange udviklere, hvor der er brug for code-reviews, pen-testing, legal review, etc.
Har du nogensinde lavet et pull-request eller code-review? Jeg tvivler :p
Men du kan jo passende poste et link til alt det open source du har skrevet eller kontributeret til de sidste 13 år! Fordi closed source er jo ondskaben selv, så det arbejder du vel ikke med :P
Proving my point. Du sider åbenlyst ikke og arbejder specialiseret på et produkt med mange udviklere, hvor der er brug for code-reviews, pen-testing, legal review, etc.
Har du nogensinde lavet et pull-request eller code-review? Jeg tvivler :p
Men du kan jo passende poste et link til alt det open source du har skrevet eller kontributeret til de sidste 13 år! Fordi closed source er jo ondskaben selv, så det arbejder du vel ikke med :P
#32 Du kom med et ret stejlt statement om at open source i sig selv intet betyder for sikkerhed. Jeg kom bare med et par mod eksempler.
Hvad angår kritisk kode som krypteringsalgoritmer tror jeg at alle IT kyndige der er ved deres fulde fem vil foretrække at bruge en åben standard som AES, SHA osv. som i de typiske implementeringer er OPEN source og grundigt undersøgt af eksperter verden over.
Frem for en closed source hjemme-opfundet ROT-13 plus lidt xor obfuscation som en smart manager mener er verdens bedste krypteringsalgoritme.
Hele verdens internet kører i det store og hele på Linux agtige maskiner, med Linux agtige TCP-IP stakke og TSL implementeringer, apache/nginx webservere, load balancers osv. Det hele open source og ekstremt battle-hardened. Kom ikke og sig at open source ikke er en model der kan levere ekstrem robust kode.
Jeg har ikke nogen speciel holdning til Brave. Det er muligvis et eksempel på en bad actor, ligesom der er bad actors inden for closed source. Folk skiftede hurtigt videre. I det mindste kan man ikke gå og gemme på overvågningskode for evigt i open source projekter, som man kan med closed source.
Hvad angår kritisk kode som krypteringsalgoritmer tror jeg at alle IT kyndige der er ved deres fulde fem vil foretrække at bruge en åben standard som AES, SHA osv. som i de typiske implementeringer er OPEN source og grundigt undersøgt af eksperter verden over.
Frem for en closed source hjemme-opfundet ROT-13 plus lidt xor obfuscation som en smart manager mener er verdens bedste krypteringsalgoritme.
Hele verdens internet kører i det store og hele på Linux agtige maskiner, med Linux agtige TCP-IP stakke og TSL implementeringer, apache/nginx webservere, load balancers osv. Det hele open source og ekstremt battle-hardened. Kom ikke og sig at open source ikke er en model der kan levere ekstrem robust kode.
Jeg har ikke nogen speciel holdning til Brave. Det er muligvis et eksempel på en bad actor, ligesom der er bad actors inden for closed source. Folk skiftede hurtigt videre. I det mindste kan man ikke gå og gemme på overvågningskode for evigt i open source projekter, som man kan med closed source.
#38
De fleste programmeringssprog og deres standard library er jo open source nu om dage (ObjC er det eneste jeg umiddelbart kan tænke på der ikke er), og derfor er krypteringsalgoritme implementeringer jo det også (fordi de typisk er en del af standard biblioteket)
Pointen er at open source ikke i sig selv er en process der sikre sikkerhed. Sikker kode kommer fra best practices, erfaring og testing.
Best practices bliver overholdet meget meget bedre af store virksomheder som Microsoft og Google end hos en-mands programmører/konsulenter som CBM.
Og testing er en langvarig process som rigtig tit kræver et specielt setup, hvilket betyder at det ikke er noget der sker bare tilfældigt. Store virksomheder som Microsoft og Google skal opfylde visse standarder, og pen-testing er bla. en af dem.
Hvornår har i sidst haft en professionel sikkerhedsekspert gennemgå alt jeres kode? Hvornår har i sidst udført et code-scan for sikkerhedshuller og licens/patent violations?
At det er "open source" er bare en model hvor mange sælger servicen (support og hosting), og hvor produktet i sig selv ikke er så relevant.
Jeg har skrevet meget open source, sikkert mere end de fleste herinde. Og jeg ser ikke open source som en metafor for kvalitet. Fordi på projekter med flere millioner linjer kode, så er der ingen der vil læse og gennemgå det hele.
De fleste programmeringssprog og deres standard library er jo open source nu om dage (ObjC er det eneste jeg umiddelbart kan tænke på der ikke er), og derfor er krypteringsalgoritme implementeringer jo det også (fordi de typisk er en del af standard biblioteket)
Pointen er at open source ikke i sig selv er en process der sikre sikkerhed. Sikker kode kommer fra best practices, erfaring og testing.
Best practices bliver overholdet meget meget bedre af store virksomheder som Microsoft og Google end hos en-mands programmører/konsulenter som CBM.
Og testing er en langvarig process som rigtig tit kræver et specielt setup, hvilket betyder at det ikke er noget der sker bare tilfældigt. Store virksomheder som Microsoft og Google skal opfylde visse standarder, og pen-testing er bla. en af dem.
Hvornår har i sidst haft en professionel sikkerhedsekspert gennemgå alt jeres kode? Hvornår har i sidst udført et code-scan for sikkerhedshuller og licens/patent violations?
Kom ikke og sig at open source ikke er en model der kan levere ekstrem robust kode.Open source som model er irrelevant. Hvis udviklerne på de projekter du nævnte ikke fik betaling for det, så havde de ikke arbejdet på projekterne, slut prut finale. Linux var aldrig nogen sinde blevet så stort som det er hvis det kun var universitets studerende der arbejde på det.
At det er "open source" er bare en model hvor mange sælger servicen (support og hosting), og hvor produktet i sig selv ikke er så relevant.
Jeg har skrevet meget open source, sikkert mere end de fleste herinde. Og jeg ser ikke open source som en metafor for kvalitet. Fordi på projekter med flere millioner linjer kode, så er der ingen der vil læse og gennemgå det hele.
Claus Jørgensen (39) skrev:#38
De fleste programmeringssprog og deres standard library er jo open source nu om dage (ObjC er det eneste jeg umiddelbart kan tænke på der ikke er), og derfor er krypteringsalgoritme implementeringer jo det også (fordi de typisk er en del af standard biblioteket)
Pointen er at open source ikke i sig selv er en process der sikre sikkerhed. Sikker kode kommer fra best practices, erfaring og testing.
Best practices bliver overholdet meget meget bedre af store virksomheder som Microsoft og Google end hos en-mands programmører/konsulenter som CBM.
Og testing er en langvarig process som rigtig tit kræver et specielt setup, hvilket betyder at det ikke er noget der sker bare tilfældigt. Store virksomheder som Microsoft og Google skal opfylde visse standarder, og pen-testing er bla. en af dem.
Hvornår har i sidst haft en professionel sikkerhedsekspert gennemgå alt jeres kode? Hvornår har i sidst udført et code-scan for sikkerhedshuller og licens/patent violations?Kom ikke og sig at open source ikke er en model der kan levere ekstrem robust kode.Open source som model er irrelevant. Hvis udviklerne på de projekter du nævnte ikke fik betaling for det, så havde de ikke arbejdet på projekterne, slut prut finale. Linux var aldrig nogen sinde blevet så stort som det er hvis det kun var universitets studerende der arbejde på det.
At det er "open source" er bare en model hvor mange sælger servicen (support og hosting), og hvor produktet i sig selv ikke er så relevant.
Jeg har skrevet meget open source, sikkert mere end de fleste herinde. Og jeg ser ikke open source som en metafor for kvalitet. Fordi på projekter med flere millioner linjer kode, så er der ingen der vil læse og gennemgå det hele.
antal kodelinier er det centrale her, ikke closed vs open source
selv i langt mindre closed eller open source projekter ...vil jeg mene at ingen ser alt igennem
larsp (11) skrev:brostenen (8) skrev:Der er altid fejl i alt indenfor IT teknologi.
Jeg har engang skrevet et program uden fejl.
Tag den.
Var det et styresystem, tekstbehandler eller andet så som et lydstudie? Ellers klap lige hesten der, med dit selvros. Vi har jo alle skrevet en "hello world", med loop og uden fejl. På hele to linjer....
Jeg tog den... Og dit argument var?
brostenen (42) skrev:Ellers klap lige hesten der, med dit selvros.
Det var ikke selvros. Det var bare en reaktion på at du skrev at al IT altid har bugs.
Simple programmer kan godt skrives korrekt og uden bugs. Matematikere var engang optaget af at bevise korrekthed af kode.
Simpel kode til embedded der er skrevet UDEN brug af frameworks og direkte på stålet kan godt vises at være korrekt i den henseende at det altid vil gøre det som det er tiltænkt så længe chippen eksekverer instruktionerne rigtigt.
Men kode-unger nu om dage tror jo at programmering er ensbetydende med at hive en bunke node js moduler ind, plastre til med noget kode fra stack overflow og så komme lidt læbestift på den nye frankenstein. Derefter løbes der så hurtig som muligt efter man har hevet i håndtaget og animeret bæstet. Med det perspektiv kan jeg godt forstå at man tænker at al IT altid har bugs.
#43
Korrekt kode != matematisk korrekt kode. "bugs" inkludere fejl hvor _funktionaliteten_ er inkorrekt, men selven koden er korrekt.
Hvis man altid går ud fra at der er fejl i et produkt, så inkludere man det i sin tidsramme (for hvornår projektet er færdigt / kan leveres til kunden). Gamle programmører som stadigvæk arbejder waterfall (*host* folk over 50 *host*) bliver altid overrasket over at der er fejl, og det er derfor vi ender om med at statslige IT udbud går som meget over budget.
Og jeg har erfaring med dette, da jeg har kørt greenfield projekts hvor vi erstattede to gamle løsninger med en ny, med alle best-practices applied. Vi snakker et drop fra 30-40% crashrate til 0.3% (hvilket stadigvæk var for højt, ifølge cheferne). På et produkt med brugerantal talt i 10+ millioner (eller 100+ millioner hvis vi tæller det overordnet produkt, ikke kun vores platform)
Derudover har vi ironien i at du forsvarer open source så meget, og så pludselig snakker grimt om at hive open source moduler ind i et projekt for ikke at skulle skrive det samme kode om igen. Det er altså fantastisk :D
Selv Rust er bygget om omkring et modul system. Java, C#, Swift, Kotlin, Ruby, Python, PHP har alle et modul og pakkesystem. Det er kun C/C++ der ikke rigtigt har et.
Korrekt kode != matematisk korrekt kode. "bugs" inkludere fejl hvor _funktionaliteten_ er inkorrekt, men selven koden er korrekt.
Hvis man altid går ud fra at der er fejl i et produkt, så inkludere man det i sin tidsramme (for hvornår projektet er færdigt / kan leveres til kunden). Gamle programmører som stadigvæk arbejder waterfall (*host* folk over 50 *host*) bliver altid overrasket over at der er fejl, og det er derfor vi ender om med at statslige IT udbud går som meget over budget.
Men kode-unger nu om dage tror jo at programmering er ensbetydende med at hive en bunke node js moduler ind, plastre til med noget kode fra stack overflow og så komme lidt læbestift på den nye frankensteinDet er faktisk langt flere fejl i gammel kode, specielt i periode 90-2010 da der primært blev brugt sprog der ikke havde null-protection, folk skrev ikke unit-tests, folk havde ikke et CI-setup der byggede hver eneste commit og kørte alle tests (fordi det tog for lang tid), folk brugte ikke code-reviews, osv.
Og jeg har erfaring med dette, da jeg har kørt greenfield projekts hvor vi erstattede to gamle løsninger med en ny, med alle best-practices applied. Vi snakker et drop fra 30-40% crashrate til 0.3% (hvilket stadigvæk var for højt, ifølge cheferne). På et produkt med brugerantal talt i 10+ millioner (eller 100+ millioner hvis vi tæller det overordnet produkt, ikke kun vores platform)
Derudover har vi ironien i at du forsvarer open source så meget, og så pludselig snakker grimt om at hive open source moduler ind i et projekt for ikke at skulle skrive det samme kode om igen. Det er altså fantastisk :D
Selv Rust er bygget om omkring et modul system. Java, C#, Swift, Kotlin, Ruby, Python, PHP har alle et modul og pakkesystem. Det er kun C/C++ der ikke rigtigt har et.
larsp (43) skrev:
Det var ikke selvros. Det var bare en reaktion på at du skrev at al IT altid har bugs.
Ja. Det ved jeg godt jeg har skrevet, og der er altid opdateringer til Windows, MacOS og Linux. Om en bug så er en sikkerhedsbrist eller funktionalitets fejl, kan diskuteres. Med alle de opdateringer der dagligt er i IT feltet, så syntes jeg det er meget selvros, når du skriver at du har skrevet et program som aldrig skulle have nogen former for opdateringer.
larsp (29) skrev:Claus Jørgensen (26) skrev:Og Open Source i sig selv betyder intet for sikkerhed
Her er et mod-eksempel der piller din påstand fra hinanden:
AES.
Al moderne kryptering er baseret på open source algoritmer som eksperter konstant prøver at pille fra hinanden.
Ikke noget godt forsøg på et eksempel.
Algoritmer er formler. De kan patenteres ikke copyrightes. Der vil typisk eksistere både closed source og open source implementationer af en vigtig algoritme.
Implementationer i kode kan være closed source eller open source. Og kan copyrightes.
Man kan ikke sammenligne en algoritme med closed/open source.
larsp (38) skrev:#32 Du kom med et ret stejlt statement om at open source i sig selv intet betyder for sikkerhed. Jeg kom bare med et par mod eksempler.
Et eksempel som ikke gover mening.
larsp (38) skrev:
Hvad angår kritisk kode som krypteringsalgoritmer tror jeg at alle IT kyndige der er ved deres fulde fem vil foretrække at bruge en åben standard som AES, SHA osv.
Uden tvivl.
larsp (38) skrev:
som i de typiske implementeringer er OPEN source og grundigt undersøgt af eksperter verden over.
Der er stadig et par enkelt Windows PC'ere her og der som bruger MS-CAPI.
De fleste open source produkter bruger OpenSSL for som implementering. Og hvis jeg skulle vælge et godt eksempel på open source kvalitet, så ville jeg ikke vælge OpenSSL!
[/quote]
linos (19) skrev:
Det sker desværre alt for ofte at sikkerhedsbrister stammer fra dårlig kode,
Jeg vil stramme den en tand og sige sikkerhedsbrister altid stammer fra dårlig kode.
God kode indeholder ikke sikkerhedsbrister.
linos (19) skrev:
og ved closed source er det de samme folk som lavede fejlen, der kommer til at rette den, og det er typisk efter at en brist allerede har været fundet og udnyttet.
Linus plejer at rykke folk fra hinanden, hvis de forsøger på at få middelmådig kode med i Linux kernelen.
Koden i Linux kernelen bliver reviewet af mange, i hele tiden, og bliver konstant opdateret med mange idéer og optimiseringer - det samme kan ikke siges om closed source. Det er garanteret ikke altid dårlig kode, det er nok oftere godt, end dårligt, men det er typisk skrevet af en mindre gruppe af folk, der alle anskuer koden fra deres lille verden/niche/synspunkt.
linos (24) skrev:#23 Det kommer da i høj grad and på hvilke områder du snakker om her.
Ja, i det meste open source, er det de samme devs/maintainers der skriver deres respektive områder af et program, men hvis du ser på kernel, er der mange forskellige personer og virksomheder der kommitter kode. Ja, det bliver typisk endegyldigt tilføjet efter at primært Linus, eller Greg har reviewet koden, men det laver ikke om på at det er andre der har skrevet den i første omgang. Men du har selvfølgelig ret i at meget andet software skrives af et lille hold, men meget af den software bliver læst af andre og modificeret/forked.
Meget store dele af Linux kernel leveres idag af store firmaer (Intel, Redhat, Samsung, IBM, Google, AMD etc.).
Jeg har svært ved at tro at der er den store forskel på processen når en Intel udvikler som del af sit arbejder leverer noget open source til Linux kernel versus noget closed source til et proprietært produkt.
Linus er måske en tand skarpere end den typiske interne proukt ejer, men det kan næppe gøre den store forskel.
linos (24) skrev:
Alt der er kritisk for et helt funktionelt (GNU/)Linux OS, er med garanti set igennem af mange flere øjne, med meget bredere perspektiv, end nogen anden closed source software.
Med garanti?
Det lyder imponerende.
Har du arbejdet med alt closed source software siden du kan udtale dig om det?
Eller synes du bare at det lyder super cool at sige sådan?
linos (24) skrev:
Du har ret i at det meget sandsynligt er personen der har lavet en fejl, som kommer til at rette den ved open source også, men forskellen er stadig at det vil blive gennemset af mange øjne, så man kan være ret sikker på at fikset er lavet ordentligt
Du tror ikke at de virksomheder der laver kommercielle OS kender den fidus med at lave nogen reviewe en rettelse?
Jeg skal hermed røbe en hemmelighed for dig - det gør de.
larsp (43) skrev:
Simpel kode til embedded der er skrevet UDEN brug af frameworks og direkte på stålet kan godt vises at være korrekt i den henseende at det altid vil gøre det som det er tiltænkt så længe chippen eksekverer instruktionerne rigtigt.
Det kan lade sig gøre, men det er dyrt for ikke-trivielle programmer.
Det var derfor jeg spurgte hvor mange linier der var i dit program uden fejl.
Men der software hvor man er villig til at betale for at det virker korrekt.
Sådan nogle typer bruger vil typisk SPARK eller lignende.
Claus Jørgensen (44) skrev:
Det er faktisk langt flere fejl i gammel kode, specielt i periode 90-2010 da der primært blev brugt sprog der ikke havde null-protection, folk skrev ikke unit-tests, folk havde ikke et CI-setup der byggede hver eneste commit og kørte alle tests (fordi det tog for lang tid), folk brugte ikke code-reviews, osv.
Jeg tror stadigt at der overvejende bruges sprog uden null protection idag.
Unit test går faktisk tilbage til aller først i 00'erne.
(i 2003 oplevede jeg en Tech Lead som sagde at det var acceptabelt at koden ikke var færdig til deadline, men at det var uacceptabelt at unit test ikke var færdig til deadline)
Code review blev populært allerede tilbage midt i 70'erne, så det er slet ikke nyt.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund