Bedrijf claimt dat Tizen duizenden programmeerfouten bevat

De maker van software voor bug-detectie claimt in een klein deel van de code van Samsungs Tizen 900 programmeerfouten gevonden te hebben. Het bedrijf voorspelt dat het uiteindelijke aantal bugs in de software ongeveer 27.000 bedraagt.

Het gehele Tizen-project met libraries van derde partijen beslaat 72.500.000 regels C- en C++-code dus Andrey Karpov, oprichter van het bedrijf Program Verification Systems, besloot willekeurig enkele dozijnen projecten uit te kiezen om te analyseren met zijn product PVS-Studio. De bug-detectietool vond 913 fouten in 2.400.000 regels code. Aangezien hij slechts 3,3 procent van het totaal een check heeft gegeven, komt Karpov na extrapolatie op een totaal van ongeveer 27.000 bugs die in code zitten.

Karpov heeft niet de waarschuwingen van PVS-studio geteld, maar daadwerkelijke errors die volgens hem verholpen zouden moeten worden. Karpov classificeert de bugs op basis van de Common Weakness Enumeration, maar doet geen uitspraken over eventuele kwetsbaarheden die tot misbruik kunnen leiden.

Karpov besloot Tizen onder de loep te nemen na het lezen van een bericht van Tizen Experts dat Samsung 10 miljoen dollar investeert in het gebruik van de Security Vulnerabilities and Critical Errors Detector van het Institute for System Programming of the Russian Academy of Sciences. Samsung hoopt hiermee de weeffouten uit Tizen OS te halen en de kwaliteit en stabiliteit van de software te vergroten. Karpov probeerde PVS-Studio te slijten bij Samsung, maar die weigerde met de mededeling al static analysis tools te gebruiken en te weten dat andere tools andere defecten kunnen vinden. Het bedrijf weerspreekt dat er 27.000 bugs in de code kunnen zitten en claimt dat veel meldingen onbelangrijke issues betreffen.

Samsung hoopt Tizen in steeds meer apparaten in te kunnen zetten. Het gebruikt de software onder andere voor smartwatches, tv's, koelkasten en airconditioners, maar wil de software ook voor internet-of-things-toepassingen inzetten. Het is niet de eerste keer dat gewezen wordt op weeffouten in Tizen. In april noemde een beveiligingsonderzoeker Tizen de 'slechtste code die ik ooit heb gezien'. Hij vond veertig zeroday-lekken in het besturingssysteem.

Reacties (100)

[DonJunior]

Karpov probeerde PVS-Studio te slijten bij Samsung, maar die weigerde..

Wat ik lees uit dit bericht is dus simpelweg dat meneer Karpov zijn zin niet kreeg en dan maar Samsung gaat proberen zwart te maken. Meneer heeft 3% code bekeken en op basis daarvan bepaald dat er dan 2700 bugs in moeten zitten. Juist ja. Ik vind het maar sneu klinken zo eigenlijk.

[mmjjb]

27.000 bugs is de aanname van meneer Karpov
Toch zal het mij niet verbazen als dit klopt

Onlangs hadden we in het nieuws:
-Onderzoeker stelt dat Samsungs besturingssysteem Tizen veertig zero-days bevat

Quotes:
Volgens onderzoeker Amihai Neiderman kunnen kwaadwillenden hiermee eenvoudig op afstand apparaten hacken die op Tizen draaien, zonder dat er daarbij fysieke toegang tot de apparaten nodig is. Volgens hem heeft niemand met verstand van beveiliging naar de code gekeken of geholpen eraan mee te schrijven. In een gesprek met Motherboard noemt Neiderman Tizen "misschien wel de slechtste code die ik ooit heb gezien".

Een voorbeeld van een andere kwetsbaarheid is de 'strcpy()-functie', waarmee data naar het geheugen kan worden geschreven. Daarbij wordt er echter niet gecontroleerd of er wel genoeg opslagruimte beschikbaar is om de data te kunnen schrijven. Dit kan een bufferoverloop veroorzaken wat aanvallers eenvoudig zouden kunnen misbruiken. Volgens Neiderman maakt vandaag de dag geen enkele programmeur nog gebruik van deze functie, terwijl de programmeurs van Samsung het "overal gebruiken".


Het zou mij niet verbazen als er toch wel erg veel mis is met de Samsung code

Verder lezen we een reactie van @Stukfruit
"EFL is onder de motorkap altijd een brak stukje werk geweest en dit is waar Tizen op gebaseerd zou zijn." "In de documentatie van Tizen's framework gebruikt men trouwens ook vrolijk strcmp ipv strncmp link"

Na even terug lezen in het nieuwsartikel krijg ik toch redelijk de indruk dat Tizen zo lek is als een mandje. Dat ze slechte exception handeling gebruiken. Dat de code extreem slecht geschreven is.

Toevoeging:
Interessant artikel over EFL (Enlightenment Foundation Libraries) waar Tizen gebruik van maakt Enlightened

Het legt uit waarom en hoe EFL/Tizen problemen heeft... pagina 1 zegt al genoeg...

[Reactie gewijzigd door mmjjb op 24 juli 2024 13:10]

[MSalters]

"Een voorbeeld van een andere kwetsbaarheid is de 'strcpy()-functie', waarmee data naar het geheugen kan worden geschreven"
Het zou mij niet verbazen als er toch wel erg veel mis is met de Samsung code

Eh, nee, dan heb je duidelijk geen ervaring met serieus code schrijven. strcpy is een standaard functie. Juist als je zelf het wiel gaat uitvinden loop je een hoger risico op fouten.

Het verhaal dat je een buffer overflow kan krijgen is theoretisch - elke junior programmeur weet dat strcpy veilig is als en alleen als de buffer één langer is dan de oorspronkelijke string. (Want C strings zijn zero-terminated).

Om die reden is strncpy GEEN oplossing. Dat produceert geen C strings, als er te weinig ruimte is voor de zero termination. Het gevolg is dat je bug uitgesteld is tot het eerste gebruik - en dus alleen maar lastiger te vinden voor testers. "Crash early" is goed.

[Reactie gewijzigd door MSalters op 24 juli 2024 13:10]

[mmjjb]

Heb inderdaad geen ervaring met C en vind het daarom mooi dat je een toelichting geeft.

Kun je nog wat meer informatie kwijt? Over bijv EFL en de functies "strcmp ipv strncmp" welke ik in mijn post citeer? Is Tizen werkelijk slecht geprogrammeerd of zijn die aantijgingen uit de lucht gegrepen?

[MSalters]

Even gecheckt - beide argumenten van strcmp() lijken me daar veilig. Een tool die daarover zeurt krijgt gauw een schop van mij. Maar ik weet dat het veilig is, omdat ik doorgeklikt heb op de functie die het eerste argument ophaalt en de documentatie heb gelezen. Dat kan een tool niet.

Dat gezegd hebbende, de documentatie kán beter. Dit is nog niet op het nivo van MSDN, en dan noem ik acceptabel.

[freaq]

een wel aardige rant over strcpy vs strncpy
https://blog.liw.fi/posts/strncpy/

[Verwijderd]

Daarom was de standaard werkwijze bij sommige projecten waar ik op gezeten heb:

strncpy(buffer, aFileName, buffSize - 1);
buffer[buffSize] = 0;

Zit je altijd goed.

[Zoijar]

Ja, altijd goed, behalve als je een miljoen van een rekening moet halen en je schrijft "... withdraw 100000\0" Je gaat nu stilletjes je data corrupten om een "bug" te fixen. Wat je wel bv kan doen is

if length(file) >= length(buffer) throw error (and controlled crash)

[Reactie gewijzigd door Zoijar op 24 juli 2024 13:10]

[Verwijderd]

Dat soort checks kwamen daarvoor. Deze code voorkwam in elk geval dat er buffer overflows optraden.

[analog_]

lelijk.

[BugBoy]

Euh... Dat is dus volgens mij dus altijd fout. Als je een buffer hebt van 8 bytes (buffSize=8), dan is buffer[buffSize] dus precies de byte na je buffer.

[Verwijderd]

Eh, nee, dan heb je duidelijk geen ervaring met serieus code schrijven. strcpy is een standaard functie. Juist als je zelf het wiel gaat uitvinden loop je een hoger risico op fouten.

https://linux.die.net/man/3/strlcpy

[Verwijderd]

En Windows bevat dat een paar honderdduizend bugs (als ik reken naar regels code).

[BasilFX]

Met ongeveer 0,38 bugs per 1000 regels code doet Tizen het beter dan 'industry average' van 15 - 50 bugs per 1000 regels: https://www.mayerdan.com/...gs-per-line-of-code-ratio. Dan vind ik de extrapolatie nogal laag ingeschat.

[Reactie gewijzigd door BasilFX op 24 juli 2024 13:10]

[Verwijderd]

Ik denk dat je niet per se een goede vergelijking maakt: 0,38 bugs per 1000 regels is wat PVS studio vond. 15-50 bugs is wat er geschat wordt in industry average code te zitten. Uiteraard vond PVS maar een fractie van de bugs...

[PPie]

Uiteraard vond PVS maar een fractie van de bugs...

Dan lijkt PVS geen goed tool. Als het 0,38 van de 15-50 bugs per 1000 regels vindt, is het redelijk waardeloos...

[CyBeR]

Nee, zo werkt dat niet. Die tool kijkt alleen maar naar wat objectief gezien een bug te noemen is. Ik heb die tool niet gecheckt maar denk aan bijvoorbeeld mogelijkheden om reeds gefree()ed geheugen nog eens te free()en, pointers die gebruikt kunnen worden terwijl ze nog NULL zijn (maar dat niet moeten zijn), buffer overruns, etc. Bij die andere definitie van bugs zitten ook gevallen waar software dat eigenlijk niet kan detecteren, omdat 't gaat om code die wel correct draait maar niet doet wat verwacht wordt. Dat is iets heel anders.

[PPie]

Dat is iets heel anders.

Natuurlijk. Maar ik geloof niet dat code die gereleased is (en dus waarschijnlijk gereviewed en getest) zo'n enorm verschil in aantal heeft tussen de problemen die je noemt die 'eenvoudig' door een tool te checken zijn en 'code die wel correct draait maar niet doet wat verwacht wordt'.
Tussen 0,38 en 15-50 is een factor 40 tot 130. Dat enorme verschil geeft mij het gevoel dat dit tool dan weinig bijdraagt.

[etix111]

zijn toch 0,38 bugs minder

Een ontwikkelaar heeft altijd een heel arsenaal aan tooltjes om dit soort 'makkelijke' bugs, zoals ik ze graag noem, eruit te halen. Om er nog een paar toe tevoegen aan het rijtje van CyBeR:
- SQL Injecties
- XSS vulnerabilities
- ID's omwisselen in auth proces
etc...

Dit verschilt per taal natuurlijk, maar dit soort tooltjes zijn foutjes die er bijna gegarandeerd uit zijn en dus de kwaliteit hebben verhoogd. Dus hoewel het absoluut gezien heel weinig lijkt is dit toch wenselijk. Verder moet je rekening houden met bugs die (bijna) nooit gevonden worden; hoe kun je iets detecteren wat zich nog nooit heeft voorgedaan?

[PPie]

Helemaal eens om meerdere tools te gebruiken.
Daarom gooi ik mijn code ook door meerdere compilers, omdat ze andere warnings geven.
clang -Weverything is erg leuk...
Maar de ophef die Andrey Karpov maakt is wat veel voor die 0,38 bugs minder...
Zo'n fantastisch tool lijkt het dus niet t ezijn...

[sygys]

Is er een schatting hoeveel fouten er bijvoorbeeld in een windows 10 zitten? Ben eigenlijk wel benieuwd.

[ReneX]

Klopt, je mag (en kan) hieruit niet concluderen dat het aantals bugs 0.38 per 1000 regels is. Static code checking vangt een deel van de ellende, maar is zeker geen 100% bug vanger.

Ik weet dat Samsung in het verleden Coverity gebruikte voor andere projecten. Nu dekt niet elk tool hetzelfde af, maar als er nog zo veel in zit dan lijkt het er niet op alsof static code checking structureel wordt ingezet (en er ook iets met de output is gedaan).

[SuperDre]

Maarja, wat wordt er dan als bug gezien? vaak genoeg dat men iets maakt en dan bewust bepaalde dingen achterwege laat omdat het meer tijd kost om het 'goed' te doen terwijl je weet dat die situatie niet voor komt. Gaat de tool dat dan als bug tellen terwijl het geen bug is?

[supersnathan94]

"Weten dat een situatie niet voorkomt" is juist de grootste fout die je kunt maken bij software op die schaal. Dat het normaal niet voorkomt betekent niet altijd dat je het niet kunt forceren namelijk.

[laptopleon]

Het probleem is, dat het domweg onmogelijk is om software te schrijven die overal op voorbereid is. Daarvoor zijn er bij zoiets complex als een operating system veel te veel variabelen (als in mogelijkheden, combinaties van mogelijkheden waarin het terecht kan komen).

Er zal dus altijd een afweging moeten worden gemaakt van.. daar en daar houden we rekening mee en dat en dat gaan we daadwerkelijk testen.. maar het houdt een keer op.

Ik kan me heel goed voorstellen dat er bijvoorbeeld niet getest is hoe de 'dock' (zal ik het maar noemen, de balk met apps onderin je TV) eruit ziet als er een negatief aantal apps in staan, want dat komt nooit voor. ALS dat al voor zou komen, is er dus iets anders mis gegaan (en kun je dus beter daar je tests op richten).

[supersnathan94]

Als je in die dock een negatief aantal apps kan hebben, dan heb je een signed integer gebruikt en dat is al niet handig Daar moet je uiteraard een uint voor gebruiken zodat het getal niet negatief kan zijn.


Maar dat maakt verder niet uit. De fouten die tools zoals bovenstaande aangeven zijn vaak ontzettend simpel om te verhelpen en het is absoluut geen slecht plan om ze 1 voor 1 langs te lopen in een paar weken. Hierdoor krijg je veel betere code kwaliteit. Bij javaprojecten heb ik ook bij iedere check-in gekeken naar findbugs en PMD waarschuwingen. Als ze er waren direct fiksen. chteraf is onbegonnen werk.

[MeMoRy]

Ook met een uint kan je 0-1 doen. De - operator checkt niet vanzelf op overflow. Er is meer nodig dan simpel een type wijzigen.

[supersnathan94]

Ja ik weet niet precies hoe het in C of derivaten daarvan werkt maar ik kan me voorstellen dat je dan een error opgooit omdat de situatie niet kan. Of je pakt de absolute waarde ofzo. Weet ik veel.

Het gaat erom dat je zorgt dat een situatie niet voor kan komen. Ook al weet je dat het normaal gesproken niet gebeurt. Aannemen dat het nooit voorkomt is niet goed.

[laptopleon]

Mijn punt is: Er kunnen nooit minder dan nul apps in de dock staan, dus het is vrij zinloos om energie te steken in het (proberen) testen van die situatie.

[supersnathan94]

Absoluut niet. Testen is niet nodig, maar goed kijken of je die validatiestap maakt (dat het niet kan) is een ander verhaal.

Zoals ik al zei is weten dat iets niet voor zal komen iets anders dan zorgen dat het ook daadwerkelijk niet kan.

[ManIkWeet]

Maak geen code waarvan je denkt dat het in de toekomst gebruikt gaat worden...

Vaak zit je er dan ontzettend naast en ben je alleen maar tijd kwijt.

[SubSpace]

In dit geval zit jij er ontzettend naast

Het soort bugs dat door dit soort tools gevonden wordt, moet over het algemeen wel serieus genomen worden, zeker voor een operating system. Je hebt te maken met derde partijen die je code op allerlei manieren kunnen gebruiken/misbruiken; dat is heel wat anders dan applicatiecode die niet van buitenaf aangeroepen wordt en waarvan je misschien nog enigzins kunt aannemen dat een situatie niet voor zal komen.

[mae-t.net]

Ik weet niet of je nou het tegenovergestelde van supersnathan94 probeert te beweren, maar dat doe je in elk geval niet dus misschien begrijp ik je bedoeling verkeerd.

Code die situaties die toch nooit voorkomen niet netjes afwikkelt, is code die gebruik in de toekomst probeert te voorspellen en dus ook volgens jou gewoon hardstikke fout.

[BeosBeing]

Een situatie die niet voorkomt is ook de oorzaak geweest van de crash van de eerste lancering van de Ariane 5. Het lanceerprogramma ving een situatie niet af die in een Ariane 4 niet voorkwam, maar toen werd het programma ongewijzigd toegepast in de Ariane 5 en daar kwam die situatie wel voor. Vervolgens blies een veiligheidsroutine de raket op. Anders had de schade nog veel groter kunnen zijn.

[hiostu]

15-50 bugs per kloc is te hoog. Ik heb tijdens mijn afstuderen onderzoek gedaan naar industriestandaarden voor software metrics en de getallen zijn lager als je kijkt naar veel onderzoeken. 3-4 per kloc voor een goede programmeur en 5-10 voor een gemiddelde programmeur. Ik heb helaas mijn bronnen niet bij de hand. Overigens is dat wat een programmeur maakt, niet wat er in het endproduct zit. Daar moeten de verschillende testen namelijk nog overheen.

[kalikatief]

Wanneer je het over zo'n getal hebt, wat telt hier voor? Echte logica fouten die het programma het verkeerde laten doen zoals copy-paste muk waar je een x-je vergeet in een y-tje te veranderen? Beveiligingskwetsbaarheden zoals een double free of een DOS waar een memery allocation niet goed wordt geclampt naar redelijke waarden? En hoe zit het met undefined behaviour waar bv the C-familie talen vol mee zit; iets dat vaak toevallig 'goed' werkt?

Afhankelijk van de taal en van de klassen 'bugs' die zo een getal beslaat kan ik mij inbeelden dat het een best redelijk getal is. Niet om te zeggen dat ze mogen bestaan, maar niet om het als een gigantische olifant in een porseleinkast op te gaan blazen.

[MSalters]

De meeste software is vrij saai - formpje hier, dialoogje. De meeste software heeft weinig gebruikers. Ook dat is weer een "long tail" effect.

In kritiische veel gebruikte software is het aantal fouten veel kleiner. Microsoft zit zo rond de 0.5 bugs per 1000 regels. Dat is dus dezelfde orde als de 0.38 die hier aangehaald wordt. Nu moet erbij worden gezegd dat Tizen veel minder serieus is, dus het zal eerder op de 3-4 bugs liggen, maar 15+ lijkt me onwaarschijnlijk.

[Verwijderd]

Ik zou de "bugs" ook wel eens willen zien dan. Anders blijft het niets anders dan een ongefundeerde beschuldiging.

Daarnaast denk ik dat closed-source het zeker niet beter doet, eerder veel slechter.

[RIVDSL]

Dit is het betreffende blog artikel
https://www.viva64.com/en/b/0519/

[Verwijderd]

Hmmm, er zitten toch wel veel knullige fouten in moet ik zeggen. Duidelijk geschreven door mensen die niet weten waar ze mee bezig zijn of in ieder geval zeer onervaren in C / C++.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 13:10]

[mbb]

Als dit net zon soort tool als Coverity is, zit bijvoordbeelde een project als LibreOffice onder de 0.01% -maar komt voor het hele project dus op op zon 23000 34 bugs.
https://blog.documentfoun.../road-to-libreoffice-5-3/
Fiefox zit op 0.34, oftewel 26.000 open
https://scan.coverity.com/projects/firefox


What types of issues does Coverity Quality Advisor find?
Some examples of defects and vulnerabilities found by Coverity Quality Advisor include:
https://scan.coverity.com/faq#what-types-of-issues-tool-find

resources leaks
dereferences of NULL pointers
incorrect usage of APIs
use of uninitialized data
memory corruptions
buffer overruns
control flow issues
error handling issues
incorrect expressions
concurrency issues
insecure data handling
unsafe use of signed values
use of resources that have been freed

[Reactie gewijzigd door mbb op 24 juli 2024 13:10]

[AlphaRomeo]

27000 maar sowieso 913 confirmed.

[Cave_Boy]

Die zijn hoe ik het lees alleen door de persoon zelf confirmed en niet door een onafhankelijk bedrijf of door Samsung zelf. Ik verwacht dat binnenkort hier meer informatie over komt.

[Gomez12]

Ik verwacht dat je er zometeen gewoon niets meer over hoort. Dit is geen serieus onderzoek geweest.

Dit is gewoon een verkoopactie geweest. Als jij een bughunting tool wil verkopen kan je niet aankomen met dat jouw tool in de code van tizen 0 fouten gevonden heeft, oftewel je knalt elke setting aan hoe onnozel ook om het foutenaantal maar omhoog te stuwen.

En dan ga je naar het management van Samsung en zeg je (onder enkele voorbehouden) dat je 913 bugs hebt gevonden en dat je dat extrapoleert naar 27.000 bugs over de hele code en dat ze met jouw product die 27.000 dingen zo opgelost hebben.

[kiang]

De voorbeelden die hij aanhaalt zijn dingen zoals 'return A < A', en dus echt wel erg duidelijke fouten in de code.

[jeanj]

waarom zou dit een fout zijn, misschien moet er altijd false worden gereturned.
Dat het beter kan met de code return false (of hoe je dat maar juist in C neerzet), maar fout hoeft het niet te zijn, dan moet je meer weten wat de code moet doen.
Dus dit is wel vreemd en een reden voor inspectie en mogelijk refectoring maar niet zonder meer een bug

[Reactie gewijzigd door jeanj op 24 juli 2024 13:10]

[vSchooten]

een leuker voorbeeld:
-----------------------------------
typedef int gint;
typedef gint gboolean;

#define BT_REQUEST_ID_RANGE_MAX 245

static gboolean req_id_used[BT_REQUEST_ID_RANGE_MAX];

void _bt_init_request_id(void)
{
assigned_id = 0;
memset(req_id_used, 0x00, BT_REQUEST_ID_RANGE_MAX);
}
---------------------------
hier wordt memory gezet met formaat 245 terwijl het eigenlijk dit moet zijn:
memset(req_id_used, 0x00, sizeof(req_id_used));

[Verwijderd]

De gevonden fouten leken mij wel correct geidentificeerd. Ik vraag mij af of die Russische tool dat ook vind. Ik verwacht eigenlijk van wel.

[Richh]

Daarbij maakt hij nergens concreet om wat voor soort bugs het gaat. Sowieso, wanneer is iets een 'programmeerfout'?

Karpov had een punt gehad als hij 27.000 kwetsbaarheden had blootgesteld die in potentie tot een lek kunnen leiden. Hell, al had hij één zero-day gemeld, dan had dat nog meer waarde gehad dan dit.
In plaats daarvan komt hij met een (in mijn ogen) redelijk nikszeggend getal...

[DrClaw]

in een eerdere post hier heeft RIVDSL de volgende link gepost: https://www.viva64.com/en/b/0519/#ID0EBZDK

Dit is de blogpost die uitgebreid ingaat op de gevonden errors. Ik heb een stuk van zijn blogpost gelezen, en alhoewel niet alles tot een crash zou leiden zitten er wel degelijk fouten, en soms grote fouten, in.

Dus, alhoewel de blogpost een grote reclame voor zijn eigen product is heeft hij wel degelijk een punt over de slordigheid van de programmeur, en het nut van static analyzers op code.

[MSalters]

Op zich is PVS Studio een lang bestaand, serieus product. Carmack himself was er behoorlijk positief over.

[elmuerte]

Epic Games en PVS hebben ook al een lange tijd een goede relatie: https://www.unrealengine....is-as-part-of-the-process

Epic is geen zacht eitje als het over kwaliteit gaat. Natuurlijk zal statische code analyse false positives, maar over het algemeen zijn het echte foute of potentiële fouten. In beide gevallen wil je ze niet hebben.

[xiphoid]

Yep, dit is dus gewoon geen nieuws eigenlijk .. next.

[totaalgeenhard]

Wat ik lees is dat Samsung een heel groot probleem heeft omdat Karpov, vrienden van Karpov en de rest van de wereld actief Rizen gaan onderzoeken en fouten om wat voor reden dan ook gaan zitten vinden....

SAMSUNG had beter Karpov buiten publiciteit kunnen houden en op basis per fix 10 euro ofzo kunnen geven. Hebben ze meteen een win/win situatie.

Voormij geen Tizen inside product voorlopig.

[Verwijderd]

Als je een Samsung TV of camera koopt krijg je er helaas Tizen bij, want alle producten van Samsung (behalve smartphones) draaien op Tizen.

Ik ben in ieder geval blij dat Samsung het probleem onderkent en er wat aan gaat doen. Dat is al een begin.

[totaalgeenhard]

Er iets aan gaat doen?

Uit artikel blijkt dat iemand (onethisch overigens) bij ze aanklopt en ipv dat serieus te nemen die figuur afwijst.

En dankzij publicatie zal elke goed/kwaadwillende weten dat succesvol iets vinden makkelijk is bij Tizen.

Het bewijst ook meteen dat ze geen goed doordacht security beleid hebben. Anders was dit nooit in de publiciteit gekomen.

NDA regelen is zo gedaan.

[Reactie gewijzigd door totaalgeenhard op 24 juli 2024 13:10]

[mae-t.net]

Dat lees jij, maar waarom lees je niet dat hij op deze manier simpelweg het nut van zijn software probeert te demonstreren? Dat staat er net zo goed.

[DutchKevv]

Tsja.. Klinkt als veel maar het zou interessanter zijn als er een error rapport van b.v. Android naast gelegd werd.

[FreezeXJ]

Tja, en dan? Ongeveer elk project heeft fouten, en een beetje softwarebedrijf gooit bijvoorbeeld Sonar over zijn code, en fikst dan de ergste problemen. 9 van de 10 gevonden punten is totaal niet misbruikbaar, en je daar zorgen over maken is gewoon verspilde moeite.

Dat wil niet zeggen dat je niets aan code-kwaliteit hoeft te doen, maar weet dan wel waar je naar kijkt. Zomaar een getal roepen is niet interessant, zelfs niet om te vergelijken.

(Bij ons wordt het als bug aangemerkt als je in een logger %s gebruikt in plaats van {}. Tuurlijk, het is niet de bedoeling, maar gevaarlijk? Nah. Maar je hebt wel opeens 36 bugs in je stuk code...)

[DutchKevv]

Zodat het bericht enige nieuwswaarde heeft.

Tizen word vooral als Android killer neergezet en het geeft gewoon een kleine 'quality check'. Al zeggen 100 mini bugs minder dan 1 showstopper bug uiteraard.

[SuperDre]

kom ik dan wel met een heel lomp punt, 'code-kwaliteit' is toch wel ook een groot deel 'in the eye of the beholder'. Het is net zoals je zelf al aangeeft ook afhankelijk van hoe de regels van de controle zijn ingesteld, waarbij dus %s als bug wordt gezien (ik ben zelf niet op de hoogte van wat nu het verschil is tussen %s en {}, ik gebruik op dit moment geen taal waar dat van toepassing is, maar ik ken wel dat 'men' regels stelt voor controle hoe code opgebouwd moet zijn maar dat die regels vaak op basis van de 'smaak' van de betreffende programmeerteam is.)

[Gomez12]

Het is net zoals je zelf al aangeeft ook afhankelijk van hoe de regels van de controle zijn ingesteld, waarbij dus %s als bug wordt gezien

Kom op, de beste man probeerde een product te verkopen. Dat gaat nu eenmaal makkelijker met de melding dat je 27.000 bugs hebt gevonden dan dat je er 27 hebt gevonden, oftewel de settings gaan voor een verkoopactie naar ludicrous oid.

[pizzafried]

27.000 bugs, dan hoef ik het product niet. maar heb je ze allemaal gefixed. dan wil ik het product misschien wel.

[SuperDre]

27.000 bugs, maar als het pakket gewoon draait zonder dat je er last van hebt dan is er geen problem dat er 27.000 bugs in zouden zitten. En de vraag is dus ook, wat voor 'bugs' gaat het om, want dat vertelt de betreffende man niet.

[pizzafried]

Je gaat mij niet zeggen dat een pakket met 27.000 bugs zonder problemen draait. Op mijn werk hebben we ook bugs, maar dat zijn nooit bugs waarvan je zegt: goh, fijn dat de klant er in ieder geval geen last van heeft. En wat voor soort bugs is al helemaal de vraag. UI? of datalek? De eerste heel erg irritant voor mij als klant, de tweede is schadelijk voor mij! In beide gevallen zou ik, als betalende klant, het bouwsel vaarwel zeggen...

[Verwijderd]

Ik vond de gevonden fouten in Tizen echt wel knullig vaak (links en rechts dezelfde expressie). Dat vind ik een heel slecht teken.

[rmulder]

Zon tool doet mij denken aan de code analyser tools in Android Studio. Die kan van alles van serieuze code problemen tot code stijl adviezen geven. Je kan je daar ook rot schikken van het aantal 'problemen' wat gevonden wordt. Maar als je er in duikt dan gaan er een hoop meldingen over stijl adviezen zoals je kunt deze regel code ook korter zo noteren. Dat is dan vaak een stuk persoonlijke voorkeur en heeft niet met code kwaliteit te maken.
Als ik het verhaal hierboven lees krijg ik daar een beetje een gevoel bij dat er is gekozen voor de analyse methode waarbij er zoveel mogelijk meldingen gegenereerd worden. Hoeveel er daarvan met beveiliging te maken hebben is dan maar de vraag.

[SuperDre]

Dat is dan vaak een stuk persoonlijke voorkeur en heeft niet met code kwaliteit te maken.

Juist, want ik heb wel vaker dat juist het korter schrijven van code het er veel onduidelijker op maakt, en dat is juist iets dat je niet wilt hebben, daarom heb ik ook een hekel aan code waar constant lambda expressions ge/misbruikt worden omdat ze te lam zijn om gewoon fatsoenlijke functies te schrijven (ho hu halt, voordat je gat piepen, ik zeg dus niet dat je ze niet moet gebruiken).
En ik denk ook dat je gelijk hebt wat betreft de methode die meneer gekozen heeft voor de analyse, zeker omdat men niet voor zijn software heeft gekozen.

[Gomez12]

[...]
Juist, want ik heb wel vaker dat juist het korter schrijven van code het er veel onduidelijker op maakt, en dat is juist iets dat je niet wilt hebben

Het probleem met statistische code analysis is dat die puur volgens regeltjes werkt terwijl mijn brein niet volgens regeltjes werkt.

Sommige dingen moet je imho altijd korter schrijven omdat het gewoon leesbaarder is korter, mits je binnen bepaalde grenzen blijft, ga je zo'n grens over dan moet je opeens ook alles wat eerst kort moest nu compleet uitschrijven.

[vman128]

Maar zijn dit nu veel meer bugs ,of een beetje meer dan "anders" ?
En hoeveel fouten zullen er in de software van de bug-detectie zitten?
Lastig te bevatten....

[SG]

Het mooie van C en C++ dat legale code ook show stopper kan zijn.Gaat om de context. Men gaat daar van uit dat de programmer weet wat hij doet. En de middel C /C++ krachtig is. Maar de risico van " Shoot in your own foot" is groot met deze low level talen en eigen memory management beheer.

waarschuwingen kunnen belangrijk zijn. Behalve als geavanceerde C++ toepast en bewust C++ misbruikt voor specifiek trucje toepassing. Het geeft hogere verantwoordelijkheid aan de programmer.

Met C++ 14 kan je op de gewenste moderne manier C++ toepassen maar je Legacy code c++98 compileert meestal ook.
Maar wat toen gangbaar is is tegenwoordig not done.
Global en Singleton wordt gezien als "codesmell"
Je zou voor Singleton en Global waarschuwing kunnen geven.
En variable met enkele letter als naam in veel grotere scoop ook
in prof software vaak toch bewust toegepast.
Clean code. Code moet zich zelf goed verklaren. Begint al met naamgeving aan variabelen.
Constness belangrijk als het geeft duidelijk aan deze waarde mag niet veranderd worden.

Recent ook met Swift bezig. daar is het 'let" ipv "const"
Swift is soort van "clean slate" tov Objective-C
D is dat voor C++ maar in die branch is Legacy er belangrijk dus C++ is blijvertje.

Ja bugs er zijn er nogal veel van maar show stoppers wil nul van hebben , minor bugs is kwestie van tijd en resources om dat allemaal weg te werken.

Daarnaast zonder andere soortgelijke toepassing en kwa grote codebase als referentie heb ik ook niet zo een idee of Tizen zo slecht is.

[SuperDre]

"Clean code", blijft toch zo'n mooie term.... is namelijk toch behoorlijk 'in the eye of the beholder'. Voor velen is Hungarian notation bv echt een nono, maar om eerlijk te zijn kan ik met Hungarian notation wel sneller code doorspitten zonder dat ik de moderne functionaliteiten van de IDE hoef te gebruiken, en dan zeggen ze nee, dat mag je niet meer gebruiken maar ondertussen dan wel camelcasing gebruiken, IMHO moet je dat dan OOK niet gebruiken.. En nee ik zeg niet dat Hungarian notation een goede techniek is, (of slechte), ik geef alleen aan dat ik het vaak duidelijker vind.
En 'mooie' syntax is ook natuurlijk in the eye of the beholder. De 1 vindt taal A fijn lezen en de ander vindt het bagger, en andersom..

[Verwijderd]

Volgens mij is dit FUD van disgrunted employees. Tizen is op linux gebaseerd, en als je doorleest zit daar bovenop een toolset van Samsung, maar bv. ook Intel werkt er aan mee. Zijn toch geen kleine partijen.

Verder: wat is een bug? Als ik de linux kernel bv. door een standaard SonarQube installatie heentrek, komt daar ook een getal boven de 100k 'bevindingen' uit. Wat, op een standaard sonar, allemaal bullshitdingen zijn die met de code zelf niet veel te maken hebbeb, meer kwaliteitsissues als niet consequent een bepaalde codestijl aanhouden. Dat kan door sonar zelfs 'kritieke bug' genoemd worden, terwijl het niets voorstelt.

Ipv er over te zeiken, kan men beter dankbaar zijn dat er tenminste voor een groot deel open source gewerkt wordt. Dat is heel wat vriendelijker dan closed-source meuk van Apple (telefoons) of bv. Sony (televisies).

[Ventieldopje]

Waarom noem je dit zeiken? Juist omdat een groot deel open source is kunnen dit soort mensen audits uitvoeren en mensen wijzen op punten. Dat het bedrijf gene kleine partji is zegt natuurlijk helemaal niks.

Kortom, je reactie is nogal wat kort door de bocht.

[terentius]

Niet zo heel lang geleden was er ook het volgende tweakers bericht.

https://tweakers.net/nieuws/123099/onderzoeker-stelt-dat-samsungs-besturingssysteem-tizen-veertig-zero-days-bevat.html

Hier zou Samsung nu dus met de onderzoeker samenwerken om dit op te lossen. Wellicht dat de onderzoeker die deze fouten heeft gevonden ook al heeft deze maar een deel bekeken Samsung hier ook op kan wijzen hoe het het beter zou kunnen, indien hij dat al niet gedaan heeft.

[Reactie gewijzigd door terentius op 24 juli 2024 13:10]

[Verwijderd]

Is Tizen niet van The Linux Foundation?

[boudewijnrempt]

Tizen is gebaseerd op EFL -- Enlightenment Foundation Libraries. Van Rasterman. De code is een soort van poging om TCL te schrijven in C. Iedere vorm van typering wordt de nek om gedraaid in een poging om alles met strings te omschrijven. Het is echt gewoon complete nachtmerrie code.

Zie https://what.thedailywtf.com/topic/15001/enlightened voor meer heerlijke spine-chilling gruwelen. Of https://arstechnica.com/g...aws-amateurishly-written/ -- dit is gewoon geen nieuws.

Het is om te rillen zo eng, gelukkig dat het nooit echt in productie zal gaan. Wel knap, trouwens, van Rasterman dat hij _hier_ zijn brood mee kan verdienen.

[Verwijderd]

Ik snap echt niet waarom ze nog alles in C willen schrijven. Het is toch al lang bewezen dat C++ veel veiliger is en vrijwel net zo snel?

Een programma gemaakt met een library zoals QT of wxWidgets is vele malen veiliger dan alles wat ze maken in C, daar blijf je gewoon problemen mee houden, zeker als het geschreven is door mensen die de taal maar matig beheersen.

[Av-]

Tja, wat wordt er precies bedoelt met een bug... Ik programmeer in PHP op een manier die, mocht display_errors volledig aanstaan, een hoop "notices" zou veroorzaken (undefined variable / index etc.). Doet verder geen afbreuk aan de functionaliteit of veiligheid, afgezien dat sommige dit slordig zullen vinden, maar wordt dit dan ook gezien als "bug"?

[hackerhater]

Dat is een bug ja, en terecht.
Je kan rare effecten krijgen als je zo programmeerd.
Als je zo'n code aflevered hier wordt resoluut de code review geweigerd.

[calvinturbo]

Dat is toch niet helemaal netjes, waarom zou je die undefined niet vermijden met gebruik van empty()?

[pizzafried]

Kunnen ze ook even de apps van Ziggo en Videoland even doorlichten? vermoed dat daar ook nog e.a. uit komt...