ISRG gaat C-componenten van Apache-httpd vervangen door Rust vanwege veiligheid

De Internet Security Research Group gaat componenten van Apache HTTP Server-implementatie httpd vervangen om de webserver veiliger te maken. De code gaat van C naar Rust om zo geheugenbugs tegen te gaan.

Het project wordt gefinancierd door Google en geleid door de ISRG, dezelfde organisatie achter de ssl-certificaten van Let's Encrypt. Het project is bedoeld om httpd veiliger te maken door belangrijke componenten stuk voor stuk over te zetten van C naar Rust, schrijft de organisatie. De eerste stap is een nieuwe module genaamd mod_tls, die het huidige mod_ssl moet vervangen. Dat is de standaard in httpd. De nieuwe module is gebouwd met de Rustls-library voor tls, in plaats van OpenSSL. "We hopen dat mod_tls ooit mod_ssl gaat vervangen", schrijven de ontwikkelaars.

In de toekomst moeten ook andere modules worden vervangen door modules die in Rust zijn geschreven. Een specifieke tijdlijn is daar nog niet voor bekend. Volgens de organisatie is C als ontwikkeltaal onveilig op geheugengebied. De ontwikkelaars verwijzen naar een lijst met bugs in Apache, waar geheugenbugs veel op voorkomen.

Rust, de taal die door Mozilla is ontworpen, zou daar veel beter geschikt voor zijn. Het probleem is wel dat Apache inmiddels al 26 jaar oud is en daarom veel oude componenten gebruikt. "Het is erg moeilijk om httpd in een keer helemaal om te zetten naar Rust. Gelukkig kunnen we het beveiligingsprobleem in httpd-geheugen incrementeel oplossen", schrijft de ISRG.

Reacties (59)

[Woefdramcx]

Het probleem is wel dat Apache inmiddels al 26 jaar oud is en daarom veel oude componenten gebruikt.

Dat is zelfs de reden voor de naam. Omdat het begonnen is op basis van de NCSA-server, aangevuld en verbeterd, werd de naam "a patchy server" bedacht: Apache.

[mkools24]

Ik snap niet dat Apache nog zoveel wordt gebruikt. NGINX en OpenLitespeed zijn toch betere keuzes vandaag de dag.

[batjes]

Omdat de support voor Apache veel groter is en elke vorm van webspul altijd rekening houd met Apache. Andere httpd's heb ik wel eens geprobeerd, maar zelf liep ik toch vaak tegen dingen aan die in Apache vanzelfsprekend zijn en je bij anderen zelf moet uitvogelen, totaal anders aangepakt wordt of de functionaliteit gewoon ontbreekt.

Performance is ook niet echt een reden, dat is meestal toch marginaal (je kan apache goed tweaken).

Geef mij Apache maar, lekker vertrouwt, ondersteund praktisch alles wat je ooit voor een webserver nodig gaat hebben en als je tegen problemen aanloopt is de support die je kan vinden veruit het grootst. Waarom zou ik voor Linux een andere httpd gebruiken?

[Niosus]

Performance is ook niet echt een reden, dat is meestal toch marginaal (je kan apache goed tweaken).

Is dit dan significant veranderd de laatste ~10 jaar? Want ik weet nog heel goed dat ik een kleine 10 jaar geleden echt moeite had met een LAMP applicatie online te houden omdat de overhead bij Apache voor static content te serven gewoon gigantisch was. Dat was toen echt een hoop geknoei met een reverse-proxy cache om dat eindelijk onder controle te krijgen.

Een beetje later ben ik dan uiteindelijk overgestapt op Nginx, en dat was gewoon verschillende grootteorders sneller in mijn ervaring. Bij Nginx heb ik nog nooit zelfs overwogen om er nog iets voor te draaien om de load te verminderen, omdat het (in mijn setup) gewoon nooit de bottleneck is.

Ik zal waarschijnlijk wel iets mis gedaan hebben toen (ik wist er toen nóg minder van dan nu), maar ik weet gewoon dat destijds het out-of-the-box een gigantisch verschil was.

[Gomez12]

[...]
Is dit dan significant veranderd de laatste ~10 jaar? Want ik weet nog heel goed dat ik een kleine 10 jaar geleden echt moeite had met een LAMP applicatie online te houden omdat de overhead bij Apache voor static content te serven gewoon gigantisch was. Dat was toen echt een hoop geknoei met een reverse-proxy cache om dat eindelijk onder controle te krijgen.

Niet echt, maar of je had gewoon een extreem foute setup of je had gewoon een 0,000001% soort site.

Bij een normale site loop je echt niet tegen de static-content limieten voor apache aan. Ik bedoel die stond altijd by default op 160 requests per seconde (static of niet).
Natuurlijk zijn er use-cases te verzinnen waarin je tegen die limiet aan gaat lopen, maar alsnog heb je dan wel een zeer succesvolle site nodig om het uberhaupt met dat soort use-cases te halen.

Ik bedoel 160 requests per seconde = 13.824.000 requests per dag als je het gelijkmatig verdeeld.
En dat is met default, je kan het rustig veel en veel hoger krijgen door even te gaan kijken naar je config.

[_JGC_]

De laatste jaren is er nogal wat veranderd in Apache. De worker MPM was een verbetering tov prefork, maar Apache kwam pas van de grond met de Event MPM. Daar hebben de eerste 20 releases ook nog heel wat bugs in gezeten.
Vervolgens kwam mod_h2 voor HTTP/2. Als er 1 reden is waarom ik naar nginx ben overgestapt is het vanwege bugs in die module.

Moet zeggen dat Apache tegenwoordig wel redelijk stabiel en snel draait, maar 10 jaar terug was het nog vrij dramatisch.

[Niosus]

Kan foute setup zijn geweest, maar er ging op piekmomenten echt wel wat traffic over die server. De piek was ~1000 gelijktijdige bezoekers volgens Google Analytics, met als resultaat echt wel ettelijke duizenden requests per minuut. Dat ging allemaal goed, tot de server even een momentje niet mee kon en al die workers vol geraakten waardoor er gewoon niets meer werkte. Dat was al met extra workers, maar het starten van die workers gaf gewoon echt te veel overhead (was mijn conclusie toen).

In hindsight had ik natuurlijk de static content vanaf een andere server moeten laten gaan, of een CDN gebruiken, etc. Mijn oplossing die ik toen gevonden heb was de hele zaak achter Varnish Cache te zetten. Die piek traffic was altijd maar op een handjevol pagina's die perfect gecached konden worden voor niet-ingelogde gebruikers. Met als gevolg dat 95%+ van de requests gewoon nooit meer tot bij Apache/Nginx geraakten.

[d3burt]

Als je appels met appels wilt vergelijken moet je de Apache Worker MPM vergelijken met nginx, en het opvragen van .htaccess uitzetten. Dan zijn nginx en Apache redelijk vergelijkbaar qua snelheid.

De reden dat veel providers met de prefork (of ITK) MPM werken is dat bij gebruik van de Worker MPM een bug in Apache meteen de hele server crasht, en het voor de meeste applicaties geen hout uitmaakt in performance. En heel veel spulletjes, met name PHP gebaseerd, vereisen .htaccess.

Ben knetterhard tegen de stabiliteit van nginx aan gelopen toen ik mod_security wilde gebruiken. Heb het na aan maand emmeren vervangen door Apache.

[MadEgg]

Dat zeg je wel heel stellig. Nginx is een prima alternatief. Lighttpd heb ik bijvoorbeeld ook goede / snelle ervaringen mee. Maar Apache doet ook zeer goed en snel wat het moet doen, en er is over het algemeen veel meer documentatie voor te vinden, meer modules voor. "Beter" is niet iets wat je op een eenvoudige schaal kunt afmeten, en elke oplossing heeft sterke en minder sterke punten. Marktadoptie is ook een belangrijke factor zoals we bij heel veel diensten in het dagelijks leven zien (*kuch* whatsapp *kuch*). Uiteindelijk kun je aan de populariteit van de oplossingen een goede indicatie zien wat in het totaalplaatje "het beste" is. Niet op een specifiek front natuurlijk, maar wel op het totaalplaatje. Anders was het niet het populairst namelijlk.

[Douweegbertje]

Als je naar modernere oplossingen kijkt; cloud, cloud native en het ecosysteem daar omheen, dan komt apache daar eigenlijk niet in terug. Idem richting de enterprise kant, met bijv. nginx plus. Begrijp mij niet verkeerd; ik heb ook altijd met Apache gewerkt en voor sommige toepassingen nog steeds. Alleen ik vind het httpd stukje toch enorm voorbij gestreefd door andere producten.

[MadEgg]

Wat ik in het cloud-gebeuren zie is juist meer een micro-service approach. Elk onderdeel draait zijn eigen API via een embedded webserver welke via een router/load-balancer achter een cloud-managed API Gateway gehangen wordt. Dan heb je inderdaad geen behoefte meer aan wat voor stand-alone HTTPD dan ook. Daar waar er grote statische websites geserveerd worden is het een ander verhaal. In shared hosting zie je toch echt nog heel veel Apache, met name omdat vrijwel alle populaire pakketten die je ervoor kunt dowloaden (Wordpress e.d.) er out-of-the-box goed mee werken.

Nogmaals: dat betekent niet dat andere oplossingen niet op bepaalde technische vlakken beter zijn, maar wel dat er meer factoren spelen dan alleen een paar technische criteria.

[Juice2000]

Ik denk dat Apache nog veel wordt gebruikt omdat:
a) het zich heeft bewezen, meer dan Nginx bijvoorbeeld. Je hebt daardoor grote zekerheid dat het werkt,
b) het voor veel systemen die goed werken ongelooflijk duur om over te gaan op een andere server, alleen al om de effort die dat kost,
c) het gewoonweg een goede keus is, ondanks dat er wellicht betere opties zijn. Voor veel mensen is Apache meer dan prima, en waarom zou je je dan gaan verdiepen in andere keuzes?

Mijn persoonlijke anecdote met Nginx: Ik heb eens voor een klant Apache gekozen omdat ik vast zat aan Windows Server 2012 (moest vd klant) en Nginx op Windows was gewoon niet stabiel. Het draaide wel, en prima ook wel verder, alleen tijdens het load- en stress-testen kwam naar boven dat onder heavy load ongeveer 0,1% van de requests een time-out opleverde. In plaats van een bug te melden en te hopen op een fix van het Nginx team heb ik gewoon Apache gebruikt, want dat werkte wel goed. En tsja, dat systeem blijft nu voor eeuwig Apache, want niemand gaat de migratie naar Nginx betalen als dat feitelijk niks oplevert, en onzeker is of het uberhaupt wel stabiel is.

[mkools24]

Nginx heeft een groter marktaandeel dan Apache. Het is ook niet een klein beetje sneller, maar belachelijk veel sneller. Dat merk je bij alles. Bovendien vind ik het een stuk simpeler te beheren. Die virtual hosts van Apache en die htaccess files op allerlei verschillende plaatsen vind ik echt een gedrocht om mee te werken.

Maarja als je nginx gaat proberen te draaien op Windows tja, laat ik daar maar geen mening over geven want die heb je zelf ook al wel zie ik.

Wat ook een nadeel van Apache is dat het heel makkelijk plat te krijgen is met slowloris aanvallen. Nginx heeft daar ook geen last van.

[Juice2000]

Tsja, ik heb geen htaccess files, geen enkele, en de configuratie was in dit geval met een paar domeinen en certs en wat api-passthrough vrij simpel. En tsja, "belachelijk veel sneller" is afhankelijk van je use-case natuurlijk. Sure, als ik het ga meten dan kan ik misschien wel tientallen procenten winnen op responsetijden als ik Nginx zou gebruiken, maar deze site staat al instant op je scherm, dus sneller kan het uit gebruikersoogpunt niet worden.

Zoals een user hieronder al zei:
"Apache is een prima keuze. De meeste sites krijgen niet zoveel bezoekers dat een paar procent performance winst, of zelfs tientallen procenten, ertoe doet. Je daar druk over maken is meestal gerommel in de marge."

Voor mij is er echt geen winst te behalen door op dit project een andere webserver in te zetten.

Overigens zou Nginx toch gewoon moeten werken op windows? Zeker, het heeft niet mijn voorkeur, maar ze releasen er binaries voor dus dan zou het moeten werken.

Ik zal me eens verdiepen in slowloris, maar ik ben er niet bang voor. Volledige bescherming tegen dat soort aanvallen of DDOS krijg je sowieso niet in een webserver, daar heb je andere systemen voor.

Niet dat ik negatief ben over Nginx overigens, integendeel, fijne webserver, werkt als een trein, ik gebruik het graag. Maar er is echt ook helemaal niks mis met Apache in 99% van de use cases.

[Reactie gewijzigd door Juice2000 op 1 augustus 2024 10:36]

[Olaf van der Spek]

In plaats van een bug te melden

Jammer...
Voor een andere webserver gaan begrijp ik dan, maar de bug niet melden is natuurlijk jammer.

[Juice2000]

Snap dat je dat jammer vindt, en over het algemeen meld ik bugs die ik vind in open source software die ik gebruik ook zeker.

Maar ja, ze hebben hun source niet op github staan, dus je kan niet even gemakkelijk nakijken of iemand anders niet tegen dezelfde dingen aan is gelopen en er al een (evt gerelateerde) melding is. En ik zat ook vast aan de installatie van Windows Server met serverbeheer dat niet bij mij lag, en om dan de hele stack te gaan zitten beschrijven voor een bug op een stuk software dat ik niet ga gebruiken, tsja, te veel effort.

[downtime]

Apache is een prima keuze. De meeste sites krijgen niet zoveel bezoekers dat een paar procent performance winst, of zelfs tientallen procenten, ertoe doet. Je daar druk over maken is meestal gerommel in de marge.

[Ed Vertijsment]

Als je zelf je server draait dan is dat inderdaad eigenlijk zo. Er zijn bepaalde use cases waar je Apache voor wilt maar over het algemeen kun je beter verder kijken.

Anders is het voor bijvoorbeeld shared hosting (LAMP). Die moeten gewoon .htaccess bestanden kunnen slikken.

[Verwijderd]

Wat je ook niet moet vergeten, is de hoeveelheid PHP-based websites die er thans draaien in de wereld. En operationeel gezien is het toch wel erg makkelijk om een httpd servertje met een PHP module te laten draaien, waarbij je met andere webservers (Nginx) weer een wat complexere opstelling nodig hebt i.c.m. een los PHP-FPM proces. Dan is Apache met mod_php gewoon echt de meest simpele oplossing die er is, tenzij je natuurlijk je gehele applicatie via fastCGI zou kunnen ontsluiten als je geen resources (css, javascript, etc) hoeft te serveren (bijvoorbeeld bij API's).

[Reactie gewijzigd door Verwijderd op 1 augustus 2024 10:36]

[mkools24]

Sorry hoor, apt install php-fpm.

Klaar.

[Ventieldopje]

Oef, PHP draaien als apache module is echt ontzettend traag. De enige reden waarom Apache vaak nog gebruikt wordt bij hosters (al dan niet deels) is omdat sites vaak nog htaccess gebruiken.

[Verwijderd]

Hier een interessant artikel over FastCGI + Nginx versus Apache + mod_php.

Onder de streep valt het "ontzettend traag" wel mee, zeker als je bedenkt dat Apache inmiddels bijna een antiek stukje software is.

[i-chat]

hoe wil je de die 2 vergelijken met apache,

voor zover mij bekend is nginx veel meer gericht op zaken als Distributed HTTPd's en reverse proxy's en is LightSpeed vooral een simpel (en kleinschalig) project om de meeste basis functies te vervullen.

Hoe zit het dan met alle (al dan niet legacy) support die Apache heeft zoals mod_sqlauth mod_tomcat (euh mod_jk) en de talloze andere integraties.

**disclaimer: dit is een oprechte vraag ***

[laptopleon]

De vraag die artikel bij mij oproept is eerder: Waarom wordt Apache / C niet gefixt?

Ja, ik begrijp dat het een hele onderneming zal zijn, maar andere oplossingen ook. Als je alles wat nu in C gebruikt wordt moet herschrijven in een andere taal lijkt me C updaten gemiddeld genomen een kortere route.

[TheNephilim]

Nog een reden om toch eens een projectje in Rust te schrijven. Wie weet is het over 5 á 10 jaar groter dan ik tot dan toe verwacht had.

Geen idee hoe het met de modules zit van httpd, maar gezien de leeftijd lijkt het me goed dat er eens wat vervangen wordt. Langzaam aan zullen er toch nieuwe/betere/snellere mogelijkheden zijn.

[Blokker_1999]

Dit voelt echt als geforceerd aan. Google betaald een derde partij om een herimplementatie van bestaande software te doen gewoon om de waarde van hun eigen programeertaal aan te tonen.

Gezien de leeftijd van vele modules kan je ook oordelen dat de grootste bugs er uit zijn en door ze van de grond af opnieuw te schrijven riskeer je nieuwe bugs te introduceren.

[alexiooo]

Tja, en toch was er semi recent het Heartbleed incident. Toen dacht ook iedereen dat OpenSSL inmiddels zo oud en door zo veel mensen bekeken was dat alle bugs er wel uit zouden zijn.

Volgens eenzelfde redenering kan je zeggen dat de bugs die er misschien in zitten al zo lang ongedetecteerd zijn dat je wel lets heel drastisch moet doen om ze toch nog te vinden.

[mocean]

Precies, wat dacht je van sudo ...

[alexiooo]

Die was ik helemaal vergeten. Bonuspunten omdat de sudo bug een buffer overflow was en dus onmogelijk in (safe) rust.

[mocean]

Ja, en ook hier: zo'n basic stukje software, niet al te complex, wat echt overal draait. Daar zitten vast geen bugs/issues in, zeker niet bij OS....

[Gomez12]

Ja, en ook hier: zo'n basic stukje software, niet al te complex, wat echt overal draait. Daar zitten vast geen bugs/issues in, zeker niet bij OS....

De realiteit is echter dat het geen basic stukje software is en dat het juist heel complex is. Daarom kijkt niemand ernaar.

Leuk voorbeeld is bijv X, dat wordt algemeen gezien als extreem smerige code wat echt op sommige punten de meest rare dingen doet, alleen het is zo complex dat niemand zijn handen eraan durft te branden zolang het werkt.

Dat heeft nu echt ongeveer de status van :
- Als het werkt gebruik het,
- Als het niet werkt en je moet iets toevoegen, start maar een nieuw project en ga niet klooien/forken in de huidige code

[djiwie]

Rust is niet van Google, je bent in de war met Go :-)

[TheNephilim]

Maar Rust is toch van Mozilla? Als het nou Go geweest was had ik het ook raar gevonden, maar Rust lijkt me prima in dat opzicht.

[rbroen]

Die stelling is volgens wikipedia niet (meer) juist:

In August 2020, Mozilla laid off 250 of its 1,000 employees worldwide as part of a corporate restructuring caused by the long-term impact of the COVID-19 pandemic.[42][43] Among those laid off were most of the Rust team,[44] while the Servo team was completely disbanded.[45] The event raised concerns about the future of Rust.[46]

In the following week, the Rust Core Team acknowledged the severe impact of the layoffs and announced that plans for a Rust foundation were underway. The first goal of the foundation would be taking ownership of all trademarks and domain names, and also take financial responsibility for their costs.[47]

In November 2020, Amazon Web Services announced its commitment to Rust's continuation by hiring some people who had a close relationship with the Rust language development. AWS claimed to be expanding the use of Rust in the development of its own products.[48]

[84hannes]

Ik vind ook dat

Rust, de taal die door Mozilla is ontworpen

een beetje kort door de bocht is. Ontwerpen is natuurlijk een proces dat nooit stopt zolang de ontwikkeling doorgaat.

• Rust is bedacht (begonnen) door Graydon Hoare, werknemer bij Mozilla, in 2006.
• In 2009 begon Mozilla het project te sponsoren.
• In 2020 werd gestart met het oprichten van een Rust Foundation, die onder meer steun van Amazon Web Services zal krijgen.

Het val niet mee dat in een enkele zin samen te vatten. Misschein had @TijsZonderH beter kunnen schrijven "Rust, de taal die door Mozilla ondergebracht wordt bij de Rust foundation".

[rbroen]

Feiten in het artikel reken ik al een tijd niet meer op, maar de onderwerpen zijn interessant.
De reacties zijn meer waard doordat die (vaak) zijn onderbouwd, wel moet je natuurlijk altijd alles controleren.

[Reddaks]

Rust is ook specifiek ontwikkeld als een moderne en veilige vervanger van C. Als er beslist wordt om een C project geleidelijk te herschrijven naar een andere taal lijkt Rust me zelfs de enige logische keuze.

[Cilph]

Google betaald een derde partij om een herimplementatie van bestaande software te doen gewoon om de waarde van hun eigen programeertaal aan te tonen.

Rust is niet van Google? En er worden nog steeds bugs gevonden in die modules hoor, en je kunt niet makkelijk bewijzen dat ze ook bugvrij zijn. Rust is een stap in die richting. Gezien waar Apache voor gebruikt wordt is het zeker de moeite waard.

[theguyofdoom]

Dat zou misschien steek houden als `mod_ssl` nooit meer gewijzigd zou worden, maar dat is óók niet waar. Die module heeft ook onderhoud nodig voor bijvoorbeeld nieuwe TLS-versies en HTTP-versies die steeds meer in elkaar over beginnen te lopen.

[MadEgg]

Er zijn dan ook talloze alternatieven in diverse programmeertalen die op zijn minst claimen nieuwer, beter, sneller, veiliger te zijn.

C is wat lastiger met geheugenbeheer. Security issues kunnen in elke taal voorkomen, en ook in managed talen kun je buffer overflows creëren al ligt het dan niet aan het geheugenbeheer maar aan bepaalde code paths. In C ben je doorgaans iets bewuster bezig met de grootte van strings en dergelijke waardoor dat soort fouten daar juist weer minder voorkomen, als het mis gaat loop je daar vaak eerder tegen de lamp. Overstappen van programmeertaal omwille van "veiligheid" vind ik toch wel sterk overkomen als een knap staaltje marketing. Waarom Google Rust zou willen marketen is mij nog niet helemaal duidelijk.

Ik heb helemaal niets tegen Rust overigens, maar ik vind het een bijzondere stap. C++ zou logischer zijn vanuit de heritage van Apache HTTPD. Of gewoon een nieuwe, concurrerende webserver van Apache HTTPD. Het is nou niet alsof Apache zo briljant is in alle opzichten dat het enige wat je eraan verbeteren kunt de programmeertaal is. Laat ze dan gewoon een nieuwe webserver in Rust gaan schrijven (wat waarschijnlijk iemand ook al gedaan heeft).

[Reactie gewijzigd door MadEgg op 1 augustus 2024 10:36]

[Olaf van der Spek]

en ook in managed talen kun je buffer overflows creëren al ligt het dan niet aan het geheugenbeheer maar aan bepaalde code paths.

Dat is simpelweg niet waar.. toch?
Anders zie ik graag een voorbeeldje.

Overstappen van programmeertaal omwille van "veiligheid" vind ik toch wel sterk overkomen als een knap staaltje marketing.

Waarom? Met C-style code en buffer / string handling heb je zoveel, onnodige, kans op security bugs..
Ik zou op zijn minst voor C++ gaan, maar ook daar kom je te veel memory gerelateerde security bugs tegen.

[Reactie gewijzigd door Olaf van der Spek op 1 augustus 2024 10:36]

[MadEgg]

[...]

Dat is simpelweg niet waar.. toch?
Anders zie ik graag een voorbeeldje.

Niet op de C-manier dat de boel segfault of je toegang krijgt tot geheugen dat niet van jou is. Wel dat je code bv (impliciet) verwacht dat een string nooit langer is dan 40 karakters en rare dingen doet als dat wel zo blijkt te zijn. Of een insert in een mysql database kolom van 32 karakters doet die dat dan vervolgens stilletjes afknipt.

Buffer overflows zoals we die in C kennen kunnen inderdaad niet voorkomen, bugs in de interpreter daargelaten (en die komen ook voor).

[Olaf van der Spek]

Wel dat je code bv (impliciet) verwacht dat een string nooit langer is dan 40 karakters en rare dingen doet als dat wel zo blijkt te zijn.

Wat voor rare dingen hebben we het dan over?

Of een insert in een mysql database kolom van 32 karakters doet die dat dan vervolgens stilletjes afknipt.

Tegenwoordig is ook dat een error (standaard), maar ook dat zou een bug van een andere klasse zijn IMO.

[MadEgg]

Wat voor rare dingen hebben we het dan over?

Je komt een hele hoop rare dingen tegen in het wild... Ik ben meerdere malen tegengekomen dat er gegevens in een Java byte-array ge-encodeerd worden. Een string-payload UTF-8 encoded aan het begin. Vanaf offset 128 kwam er dan een sloot aan meta-data. Maar ja, dan gaat het dus mis als de string langer is dan 128 karakters. Ik zeg niet dat het een goed ontwerp is, maar het punt is dat buffer overflows ook in managed talen voor kunnen komen. Je kunt het PEBKAC noemen en dat is het ook wel, maar tot op zekere hoogte is een buffer overflow met C-pointers dat ook natuurlijk.

Tegenwoordig is ook dat een error (standaard), maar ook dat zou een bug van een andere klasse zijn IMO.

Tja, het is een overflow van de buffer. Heeft MySQL Dat inmiddels gefikst? Dat is een van de (vele) redenen dat ik jaren geleden de deur heb dichtgeslagen voor MySQL en ben sindsdien zoveel mogelijk met PostgreSQL werk.

[Olaf van der Spek]

Tja, het is een overflow van de buffer.

Volgens mij gebruiken wij iets andere definities van buffer overflows dan. Truncation is toch iets anders dan een buffer overflow.

https://en.wikipedia.org/...he%20destination%20buffer.

[NoUser]

Nog een reden om toch eens een projectje in Rust te schrijven. Wie weet is het over 5 á 10 jaar groter dan ik tot dan toe verwacht had.

Had precies dezelfde gedachte.

[Mel33]

Is httpd, dan een stuk software dat de semi- onveilige (dat met de nu te oude programeer taal is gemaakt)Apache server, als enige gaat bereiken en afzoekt voor jou request?
Zie ik dit goed?

[Zezura]

C is helemaal niet TE oud, C heeft zich bewezen en is een van de talen waar je zon beetje alles mee kan doen wat je maar wil waarbij je niet onnodig tegen restricties loopt van een compiler of JIT, of waarbij achterlijke spaghetti code krijgt. Daarbij heeft C fantastische prestaties en prima taal om in te werken.
Ik raad het iedereen nog steeds aan (C)++.

C++ is veiliger dan C als je goed gebruikt maakt van de nieuwe feature-set.
Zoals SmartPointers etc.
Als je het niveau van C niet aan kan, dan kan je altijd naar C#.

!! En belangrijk als je niet weet wat je doet, dan maakt de taal niet uit dan maak je toch wel fouten die tot bugs of security vulnerabilities lijden. Dat maakt namelijk niet uit of je Rust of C++ of C of C# of javascript gebruikt. !!

[84hannes]

C is (...) een van de talen waar je (..) niet (...) spaghetti code krijgt.

Je zei heel veel in een enkele zin, dus ik moest even redigeren. Wil je beweren dat je met C geen spaghetticode kunt schrijven (zou heel gedurfd zijn), of bedoel je dat er ook talen zijn waarmee je alleen maar spaghetticode kunt schrijven?

[Niosus]

Ongeacht het antwoord van Zezura, kan ik alleen maar stellen dat C veel voordelen heeft, maar het inperken van spaghetti code is er toch niet één van.

Niet dat je geen propere code kunt schrijven in C, maar je moet toch echt wel extra moeite doen ervoor. Zeker als je multithreaded werkt moet je echt verdomd goed nadenken voor je iets bouwt, veel meer dan in veel andere talen...

De vastere structuur van andere talen kan tegenwerken als je iets heel specifiek en low-level probeert te maken, maar als je iets meer high-level en minder performance-critical code schrijft dan maakt die structuur je veel productiever. Waar ik in C een week over doe, kan ik waarschijnlijk met Java of Python in een halve dag...

[Reddaks]

!! En belangrijk als je niet weet wat je doet, dan maakt de taal niet uit dan maak je toch wel fouten die tot bugs of security vulnerabilities lijden. Dat maakt namelijk niet uit of je Rust of C++ of C of C# of javascript gebruikt. !!

Het klopt dat je in elke programmeertaal fouten kan maken, maar in C is het veel makkelijker om fouten te maken dan in Rust. Zeker wanneer het over memory management gaat.

[!GN!T!ON]

httpd is het process / daemon waar apache in draait. Die mod_x zijn modules / extensies die je kan inladen in het process. Je zet in je config file welke modules je wilt gebruiken op welke routes.

[Reddaks]

Niet helemaal correct. Apache, of voluit de Apache Software Fonduation, is de naam van de organisatie. HTTPD is een naam voor het HTTP Server project onder de Apache organisatie. In de volksmond wordt er vaak "Apache" gezegd om te verwijzen naar de webserver, maar dat is zoals "Mozilla" zeggen om te verwijzen naar de Firefox webbrowser. Apache beheert nog een hele lijst aan andere belangrijke projecten waaronder ActiveMQ, Hadoop, Cassandra, Kafka, Lucene, en Tomcat.

[!GN!T!ON]

Klopt! ik had beter Apache Webserver kunnen zeggen.

[Cilph]

Apache httpd is hetzelfde als de Apache webserver. Twee namen voor hetzelfde ding.

[TheAncientDovah]

Ik steun het idee om over te stappen op veiligere programmeertalen zoals Rust. Dit voorkomt mogelijk veel CVEs of bugs in de toekomst.

Ik vraag me wel af waarom men niet gewoon over stapt op een al bestaand alternatief in Rust zoals Sozu (https://github.com/sozu-proxy/sozu). Waarom moet je twee applicaties hebben die nagenoeg hetzelfde doen op een soortgelijke manier?

[SuperDre]

mwa, aan de andere kant, Rust is just another language....

[TheAncientDovah]

Rust is in tegenstelling tot C memory-safe. Je kan niet (in de regel) buiten je buffer schrijven. Al die exploits zoals buffer overflows zijn daarom vrijwel uitgesloten.

[Gropah]

Herschrijven kan heel zinvol zijn, maar ik vraag mij af of het aantal bugs wat ze proberen te voorkomen (memory bugs) minder gaat zijn dan het aantal nieuwe bugs wat geïntroduceerd word door het te herschrijven.