mboost-dp1

Sidebars

android smartphones mærker hurtigste opdateringer undersøgelse / Newz.dk

Google

Over 1 milliard android-enheder ramt af ny sårbarhed

- , indsendt af arne_v

Anslået over én milliard android-enheder er ramt af nyfunden sårbarhed.

Det er en sårbarhed i DSP-kredsløbet (digital signal processor), der er en del af telefonernes integrerede chips, som der denne gang gør telefoner og tablets sårbare.

“Achilles”, som sårbarheden er døbt, findes kun i telefoner med Qualcomms Snapdragon-chipsæt – men de står alligevel samlet set for en stor andel af telefoner.

Sikkerhedsbristen skulle angiveligt gøre det muligt at installere malware på telefonen og formentlig derigennem overtage telefonens funktioner.

I alt fandt forskerne bag “Achilles”, 400 stykker kode i Qualcomms DSP, der er sårbare for angreb.

Det er godt og vel 40% af alle android-telefoner der er udsat for “Achilles” – fra producenter som Google, Samsung, LG og OnePlus.





Gå til bund
Gravatar #1 - Claus Jørgensen
13. aug. 2020 19:25
Kan i huske dengang hvor alle sagde at der ikke var nogle sårbarheder i Linux?

r/agedlikemilk lulz
Gravatar #2 - AppleSheep
13. aug. 2020 19:42
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?
Gravatar #3 - wendelboe
13. aug. 2020 21:45
Gætter på man så nu skal være processor kritisk omkring sin mobil ? ^^
Lidt ligesom en intel vs amd battle, bare med mobile units
Gravatar #4 - ToFFo
14. aug. 2020 08:35
Fedt, så er jeg ikke så bitter over min Galaxy S20 kom med Samsungs sub-par Exynos processor alligevel :D
Gravatar #5 - linos
14. aug. 2020 08:58
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.

Gravatar #6 - brostenen
14. aug. 2020 09:53
Claus Jørgensen (1) skrev:
Kan i huske dengang hvor alle sagde at der ikke var nogle sårbarheder i Linux?

r/agedlikemilk lulz


Hmmm... Og jeg som gik og troede det handlede om et brist i hardwaren og ikke styresystemet.
Gravatar #7 - Claus Jørgensen
14. aug. 2020 11:56
#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.
Gravatar #8 - brostenen
14. aug. 2020 12:14
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.
Gravatar #9 - xxanna69x
14. aug. 2020 12:28
[Indlæg er markeret som spam]
Gravatar #10 - larsp
14. aug. 2020 12:30
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.
Gravatar #11 - larsp
14. aug. 2020 12:33
brostenen (8) skrev:
Der er altid fejl i alt indenfor IT teknologi.

Jeg har engang skrevet et program uden fejl.

Tag den.
Gravatar #12 - arne_v
14. aug. 2020 12:48
#11

Hvor mange linier?
Gravatar #13 - larsp
14. aug. 2020 13:02
arne_v (12) skrev:
#11

Hvor mange linier?

Flere end 0. Så, nok til at modbevise #8 ;)
Gravatar #14 - CBM
14. aug. 2020 15:12
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
Gravatar #15 - CBM
14. aug. 2020 15:18
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
Gravatar #16 - Skak2000
14. aug. 2020 15:52
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)
Gravatar #17 - Claus Jørgensen
14. aug. 2020 16:47
#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 Store
Kun 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.
Gravatar #18 - wikiu
14. aug. 2020 21:05
[Indlæg er markeret som spam]
Gravatar #19 - linos
15. aug. 2020 07:29
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 Store
Kun 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.
Gravatar #20 - linos
15. aug. 2020 07:30
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 Store
Kun 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.
Gravatar #21 - linos
15. aug. 2020 07:33
Forsøgte at redigere, men siden lavede dobbeltpost i stedet.
Gravatar #22 - Hack4Crack
15. aug. 2020 21:26
De amerikanske chip producenter er ved at få et dårligt ry... Først Intel og nu Qualcomm
Gravatar #23 - Claus Jørgensen
16. aug. 2020 00:38
#19

Du ved intet om open source hvis du tror at det ikke er 99.99% de samme der skriver koden

Linux og Windows er stort set identisk, bortset fra at det er folk fra 20 forskellige virksomheder, så der er mindre koordinering
Gravatar #24 - linos
16. aug. 2020 18:58
#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?
Gravatar #25 - Claus Jørgensen
16. aug. 2020 21:30
#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

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.
Gravatar #26 - Claus Jørgensen
16. aug. 2020 21:40
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.
Gravatar #27 - CBM
17. aug. 2020 03:29
#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?
Gravatar #28 - Claus Jørgensen
17. aug. 2020 07:47
#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.
Gravatar #29 - larsp
17. aug. 2020 08:01
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.
Gravatar #30 - Claus Jørgensen
17. aug. 2020 08:06
#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.
Gravatar #31 - larsp
17. aug. 2020 08:17
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?
Gravatar #32 - Claus Jørgensen
17. aug. 2020 09:31
#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)
Gravatar #33 - CBM
17. aug. 2020 12:00
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
Gravatar #34 - Claus Jørgensen
17. aug. 2020 12:02
#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.

Gravatar #35 - CBM
17. aug. 2020 12:04
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)
Gravatar #36 - Claus Jørgensen
17. aug. 2020 12:08
#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
Gravatar #37 - CBM
17. aug. 2020 12:11
#36

closed source kan være et nødvendigt onde

jeg er den primære udvikler på 2 produkter

et af dem er til logistik og det andet er til medico

begge er desktop applikationer og begge har et team af udviklere tilknyttet
Gravatar #38 - larsp
17. aug. 2020 12:31
#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.
Gravatar #39 - Claus Jørgensen
17. aug. 2020 12:49
#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.
Gravatar #40 - CBM
17. aug. 2020 13:23
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
Gravatar #41 - CBM
17. aug. 2020 13:32
#39

men ellers er jeg ret enig i de ting du skriver i #39
Gravatar #42 - brostenen
17. aug. 2020 15:16
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?
Gravatar #43 - larsp
17. aug. 2020 19:59
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.
Gravatar #44 - Claus Jørgensen
17. aug. 2020 20:14
#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.

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
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.

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.
Gravatar #45 - brostenen
17. aug. 2020 23:44
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.
Gravatar #46 - arne_v
18. aug. 2020 00:36
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]
Gravatar #47 - arne_v
18. aug. 2020 00:56
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.
Gravatar #48 - arne_v
18. aug. 2020 01:00
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.
Gravatar #49 - arne_v
18. aug. 2020 01:10
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.
Gravatar #50 - arne_v
18. aug. 2020 01:14
#49

Jeg betragter iøvrigt code review af alt kode som en forældet teknik idag.

Static code analysis tool er langt mere effektive.

Og så kan man supplere med code review af særligt udvalgt kode (kritisk kode, bug fixes og lignende).
Gå til top

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.

Opret Bruger Login