Overheid maakt broncode van DigiD-app openbaar - update
Overheidsinstantie Logius heeft de broncode van de DigiD-app openbaar gemaakt, zodat het mogelijk is om de code van de app te bekijken. Vorig jaar meldde Security.NL al dat de overheid het openbaar maken van de broncode onderzocht. Destijds liet staatssecretaris Van Huffelen van Digitalisering weten dat de openbaarmaking van de broncode het risico met zich meebrengt dat de app kan worden gekloond om via die weg gegevens van gebruikers te stelen.
"De publicatie is in lijn met het kabinetsbeleid om een transparante overheid te bevorderen. Het gebruik van DigiD blijft voor iedereen veilig en betrouwbaar", zo laat Logius, de overheidsinstantie die voor DigiD verantwoordelijk is, vandaag weten. Na een verzoek op de Wet Open Overheid (Woo) is Logius gestart met onderzoek naar de openbaarmaking van de broncode van DigiD.
Als eerste is nu besloten om een snapshot van de broncode van de DigiD-app openbaar te maken. In een volgende fase wordt onderzocht of ook de DigiD-software die bij Logius draait kan worden vrijgegeven. Hergebruik van de broncode is toegestaan onder de EUPL-licentie, met uitzondering van broncode waarvoor een andere licentie is aangegeven. Wie kwetsbaarheden in de broncode vindt kan die rapporteren bij het Nationaal Cyber Security Centrum (NCSC).
"Je vindt de broncode nu nog als ‘foto’, maar Logius wil de broncode op termijn als ‘film’ kunnen publiceren. Dan worden ook nieuwe versies steeds openbaar gemaakt", zo laat Digitale Overheid weten. Daarvoor zijn volgens Logius drie redenen. De software moet hiervoor geschikt gemaakt worden. Daarnaast moet ook de organisatie klaar zijn om deze andere manier van werken te ondersteunen. En kost het tijd om dit zorgvuldig te kunnen doen.
Beveiligingsrisico
In een Kamerbrief over de openbaarmaking van de broncode laat staatssecretaris Van Huffelen weten dat enkele fragmenten in de broncode een beveiligingsrisico voor de continuïteit van DigiD kunnen opleveren. Het gaat dan bijvoorbeeld om informatie over de infrastructuur waar DigiD op draait. Deze fragmenten zijn in de gepubliceerde broncode vervangen door de letter ‘S’ (‘security’). Daarnaast zijn fragmenten waaruit persoonsgegevens van ontwikkelaars te herleiden zijn vervangen door de letter ‘P’ (‘privacy’).
Reacties (26)
De hamvraag blijft welke data er nu precies met Google gedeeld wordt en wat zij daar precies mee doen. Logius weet het zelf helaas niet.
Vertaling 'foto' en 'film' :
Uit de URL :
De broncode van de app is nu nog gepubliceerd als een momentopname; een ‘foto’ van de broncode op een bepaald moment in de tijd.
Waarschijnlijk nu dus een snapshot van een bepaalde versie (tarball) , en later een git of ander version control archief ?
Of standaard snapshots van een release-versie .
Ik verwacht er weinig spannends van , maar het moet gezegd worden : het _is_ een nette actie .
Ik vrees dat het best wat dev tijd kost met naar verhouding erg weinig technisch rendement .
(Nee - niet om "de backdoors te verstoppen" , maar ik denk dat ze allerlei comments op 'incorrect taalgebruik' moeten schonen , want anders heb je weer van die zeikjournalisten die daarop mieren .)
Uit de URL :
De broncode van de app is nu nog gepubliceerd als een momentopname; een ‘foto’ van de broncode op een bepaald moment in de tijd.
Je vindt de broncode nu nog als ‘foto’, maar Logius wil de broncode op termijn als ‘film’ kunnen publiceren. Dan worden ook nieuwe versies steeds openbaar gemaakt. Dat kan nu nog niet, meldt Logius desgevraagd.
Waarschijnlijk nu dus een snapshot van een bepaalde versie (tarball) , en later een git of ander version control archief ?
Of standaard snapshots van een release-versie .
Ik verwacht er weinig spannends van , maar het moet gezegd worden : het _is_ een nette actie .
Ik vrees dat het best wat dev tijd kost met naar verhouding erg weinig technisch rendement .
(Nee - niet om "de backdoors te verstoppen" , maar ik denk dat ze allerlei comments op 'incorrect taalgebruik' moeten schonen , want anders heb je weer van die zeikjournalisten die daarop mieren .)
Ik hoop dat, als straks de meest recente broncode vrij wordt gegeven, het mogelijk wordt om een DigID applicatie voor andere operating systemen te ontwikkelen, zoals bijvoorbeeld SailfishOS.
Door Anoniem: Ik hoop dat, als straks de meest recente broncode vrij wordt gegeven, het mogelijk wordt om een DigID applicatie voor andere operating systemen te ontwikkelen, zoals bijvoorbeeld SailfishOS.
Ja zoiets hoop ik ook. Zodat je gewoon een .apk kan downloaden vanuit bijvoorbeeld f-droid store
16-01-2023, 16:42 door
spatieman
dit kan nooit goed gaan...
Heeft al iemand gekeken of je kan zien welke data er door de Google en Microsoft trackers wordt verzameld? https://reports.exodus-privacy.eu.org/en/reports/nl.rijksoverheid.digid.pub/latest/
"https://github.com/MinBZK/woo-besluit-broncode-digid-app/blob/master/azure-pipelines.yml" dus de NL authenticatie app wordt ontwikkeld in een USA cloud omgeving, dan wordt het eindelijk opensource, wordt er weer voor datzelfde USA cloud bedrijf gekozen voor het publiceren van de broncode..... Gaat goed met de soevereiniteit van ons land :(
Door Anoniem: Vertaling 'foto' en 'film' :
Uit de URL :
De broncode van de app is nu nog gepubliceerd als een momentopname; een ‘foto’ van de broncode op een bepaald moment in de tijd.
Waarschijnlijk nu dus een snapshot van een bepaalde versie (tarball) , en later een git of ander version control archief ?
Of standaard snapshots van een release-versie .
Ik verwacht er weinig spannends van , maar het moet gezegd worden : het _is_ een nette actie .
Ik vrees dat het best wat dev tijd kost met naar verhouding erg weinig technisch rendement .
(Nee - niet om "de backdoors te verstoppen" , maar ik denk dat ze allerlei comments op 'incorrect taalgebruik' moeten schonen , want anders heb je weer van die zeikjournalisten die daarop mieren .)
Uit de URL :
De broncode van de app is nu nog gepubliceerd als een momentopname; een ‘foto’ van de broncode op een bepaald moment in de tijd.
Je vindt de broncode nu nog als ‘foto’, maar Logius wil de broncode op termijn als ‘film’ kunnen publiceren. Dan worden ook nieuwe versies steeds openbaar gemaakt. Dat kan nu nog niet, meldt Logius desgevraagd.
Waarschijnlijk nu dus een snapshot van een bepaalde versie (tarball) , en later een git of ander version control archief ?
Of standaard snapshots van een release-versie .
Ik verwacht er weinig spannends van , maar het moet gezegd worden : het _is_ een nette actie .
Ik vrees dat het best wat dev tijd kost met naar verhouding erg weinig technisch rendement .
(Nee - niet om "de backdoors te verstoppen" , maar ik denk dat ze allerlei comments op 'incorrect taalgebruik' moeten schonen , want anders heb je weer van die zeikjournalisten die daarop mieren .)
self update :
Ah - tikje verder lezen : ook de identiteiten van de devs, en dingen waaruit informatie over de backend servers te herleiden is.
Op zich wel logisch .
Afhankelijk van hoeveel de API geschoond wordt is de app dan mogelijk niet functioneel compileerbeer.
Wat is het nut hier precies van?
Je kunt als gebruiker toch nooit controleren of de app die je uit de store download gecompileerd is van de sourcecode
die ze beschikbaar stellen...
En dan nog, wat er in de lokale app gebeurt is als het goed is niet spannend. Geven ze ook de sourcecode van de backend?
Je kunt als gebruiker toch nooit controleren of de app die je uit de store download gecompileerd is van de sourcecode
die ze beschikbaar stellen...
En dan nog, wat er in de lokale app gebeurt is als het goed is niet spannend. Geven ze ook de sourcecode van de backend?
Wat kan die broncode nou boeie?
Je kan er niks mee.
Je kan alleen zien hoe het programma werkt. Hehe
Je kan er niks mee.
Je kan alleen zien hoe het programma werkt. Hehe
Nou kunnen we dan die trackers er uitslopen in een fork?
Zodra de server online is gaan we WebAuthn maar eens toevoegen.
Zodra de server online is gaan we WebAuthn maar eens toevoegen.
17-01-2023, 08:50 door
_R0N_
Door Anoniem: Wat is het nut hier precies van?
Je kunt als gebruiker toch nooit controleren of de app die je uit de store download gecompileerd is van de sourcecode
die ze beschikbaar stellen...
En dan nog, wat er in de lokale app gebeurt is als het goed is niet spannend. Geven ze ook de sourcecode van de backend?
Je kunt als gebruiker toch nooit controleren of de app die je uit de store download gecompileerd is van de sourcecode
die ze beschikbaar stellen...
En dan nog, wat er in de lokale app gebeurt is als het goed is niet spannend. Geven ze ook de sourcecode van de backend?
Je kunt als gebruiker ook niet weten of je Ubuntu packages van dezelfde sources zijn gecompileerd als die je kunt downloaden.
Het is natuurlijk makkelijk altijd wat te vinden om over te zeiken.
Door Anoniem:
self update :
Ah - tikje verder lezen : ook de identiteiten van de devs, en dingen waaruit informatie over de backend servers te herleiden is.
Op zich wel logisch .
Afhankelijk van hoeveel de API geschoond wordt is de app dan mogelijk niet functioneel compileerbeer.
Wat is dat nou weer voor een onzinactie om "vertrouwelijke zaken" weg te lakken. Als er echt zaken in die code zitten die niet openbaar mogen worden dan is het design fout. Ik mag toch aannemen dat er geen passwords, (private) keys of iets dergelijks in de code zitten: dat zou een major security issue betekenen. Met een tool als JADX haal je die info gewoon uit de APK zoals die voor Android te downloaden is, dus weglakken maakt het alleen heel iets lastiger om dit te achterhalen.Door Anoniem: Vertaling 'foto' en 'film' :
Uit de URL :
De broncode van de app is nu nog gepubliceerd als een momentopname; een ‘foto’ van de broncode op een bepaald moment in de tijd.
Waarschijnlijk nu dus een snapshot van een bepaalde versie (tarball) , en later een git of ander version control archief ?
Of standaard snapshots van een release-versie .
Ik verwacht er weinig spannends van , maar het moet gezegd worden : het _is_ een nette actie .
Ik vrees dat het best wat dev tijd kost met naar verhouding erg weinig technisch rendement .
(Nee - niet om "de backdoors te verstoppen" , maar ik denk dat ze allerlei comments op 'incorrect taalgebruik' moeten schonen , want anders heb je weer van die zeikjournalisten die daarop mieren .)
Uit de URL :
De broncode van de app is nu nog gepubliceerd als een momentopname; een ‘foto’ van de broncode op een bepaald moment in de tijd.
Je vindt de broncode nu nog als ‘foto’, maar Logius wil de broncode op termijn als ‘film’ kunnen publiceren. Dan worden ook nieuwe versies steeds openbaar gemaakt. Dat kan nu nog niet, meldt Logius desgevraagd.
Waarschijnlijk nu dus een snapshot van een bepaalde versie (tarball) , en later een git of ander version control archief ?
Of standaard snapshots van een release-versie .
Ik verwacht er weinig spannends van , maar het moet gezegd worden : het _is_ een nette actie .
Ik vrees dat het best wat dev tijd kost met naar verhouding erg weinig technisch rendement .
(Nee - niet om "de backdoors te verstoppen" , maar ik denk dat ze allerlei comments op 'incorrect taalgebruik' moeten schonen , want anders heb je weer van die zeikjournalisten die daarop mieren .)
self update :
Ah - tikje verder lezen : ook de identiteiten van de devs, en dingen waaruit informatie over de backend servers te herleiden is.
Op zich wel logisch .
Afhankelijk van hoeveel de API geschoond wordt is de app dan mogelijk niet functioneel compileerbeer.
Door _R0N_:
Je kunt als gebruiker ook niet weten of je Ubuntu packages van dezelfde sources zijn gecompileerd als die je kunt downloaden.
Het is natuurlijk makkelijk altijd wat te vinden om over te zeiken.
Dat kan je wel maar wat heeft in gods naam Ubuntu met dit topic te maken?Door Anoniem: Wat is het nut hier precies van?
Je kunt als gebruiker toch nooit controleren of de app die je uit de store download gecompileerd is van de sourcecode
die ze beschikbaar stellen...
En dan nog, wat er in de lokale app gebeurt is als het goed is niet spannend. Geven ze ook de sourcecode van de backend?
Je kunt als gebruiker toch nooit controleren of de app die je uit de store download gecompileerd is van de sourcecode
die ze beschikbaar stellen...
En dan nog, wat er in de lokale app gebeurt is als het goed is niet spannend. Geven ze ook de sourcecode van de backend?
Je kunt als gebruiker ook niet weten of je Ubuntu packages van dezelfde sources zijn gecompileerd als die je kunt downloaden.
Het is natuurlijk makkelijk altijd wat te vinden om over te zeiken.
B.t.w. onze lieve heer kan je ook niet controleren.
Door Anoniem: Wat kan die broncode nou boeie?
Je kan er niks mee.
Je kan alleen zien hoe het programma werkt. Hehe
Je kan er niks mee.
Je kan alleen zien hoe het programma werkt. Hehe
Het voordeel van open bron code is dat er veel meer controle is op wat de applicatie kan en doet.
Daarnaast worden eventuele lekken/bugs eerder opgespoord en gemeld, hierdoor wordt de software veiliger.
Dus jij kunt er misschien niets mee, maar gelukkig veel developers wel.
Door majortom:
Door Anoniem:
self update :
Ah - tikje verder lezen : ook de identiteiten van de devs, en dingen waaruit informatie over de backend servers te herleiden is.
Op zich wel logisch .
Afhankelijk van hoeveel de API geschoond wordt is de app dan mogelijk niet functioneel compileerbeer.
Wat is dat nou weer voor een onzinactie om "vertrouwelijke zaken" weg te lakken. Als er echt zaken in die code zitten die niet openbaar mogen worden dan is het design fout. Ik mag toch aannemen dat er geen passwords, (private) keys of iets dergelijks in de code zitten: dat zou een major security issue betekenen. Met een tool als JADX haal je die info gewoon uit de APK zoals die voor Android te downloaden is, dus weglakken maakt het alleen heel iets lastiger om dit te achterhalen.Door Anoniem: Vertaling 'foto' en 'film' :
Uit de URL :
De broncode van de app is nu nog gepubliceerd als een momentopname; een ‘foto’ van de broncode op een bepaald moment in de tijd.
Waarschijnlijk nu dus een snapshot van een bepaalde versie (tarball) , en later een git of ander version control archief ?
Of standaard snapshots van een release-versie .
Ik verwacht er weinig spannends van , maar het moet gezegd worden : het _is_ een nette actie .
Ik vrees dat het best wat dev tijd kost met naar verhouding erg weinig technisch rendement .
(Nee - niet om "de backdoors te verstoppen" , maar ik denk dat ze allerlei comments op 'incorrect taalgebruik' moeten schonen , want anders heb je weer van die zeikjournalisten die daarop mieren .)
Uit de URL :
De broncode van de app is nu nog gepubliceerd als een momentopname; een ‘foto’ van de broncode op een bepaald moment in de tijd.
Je vindt de broncode nu nog als ‘foto’, maar Logius wil de broncode op termijn als ‘film’ kunnen publiceren. Dan worden ook nieuwe versies steeds openbaar gemaakt. Dat kan nu nog niet, meldt Logius desgevraagd.
Waarschijnlijk nu dus een snapshot van een bepaalde versie (tarball) , en later een git of ander version control archief ?
Of standaard snapshots van een release-versie .
Ik verwacht er weinig spannends van , maar het moet gezegd worden : het _is_ een nette actie .
Ik vrees dat het best wat dev tijd kost met naar verhouding erg weinig technisch rendement .
(Nee - niet om "de backdoors te verstoppen" , maar ik denk dat ze allerlei comments op 'incorrect taalgebruik' moeten schonen , want anders heb je weer van die zeikjournalisten die daarop mieren .)
self update :
Ah - tikje verder lezen : ook de identiteiten van de devs, en dingen waaruit informatie over de backend servers te herleiden is.
Op zich wel logisch .
Afhankelijk van hoeveel de API geschoond wordt is de app dan mogelijk niet functioneel compileerbeer.
Niet al te basaal denken, majoor .
Het is -als pentester - best erg nuttig om dingen te leren over de opzet en structuur van de backend die niet alleen maar de credentials zijn .
Nog meer als DDoSer, trouwens .
Door Anoniem:
Door _R0N_:
Je kunt als gebruiker ook niet weten of je Ubuntu packages van dezelfde sources zijn gecompileerd als die je kunt downloaden.
Het is natuurlijk makkelijk altijd wat te vinden om over te zeiken.
Dat kan je wel maar wat heeft in gods naam Ubuntu met dit topic te maken?Door Anoniem: Wat is het nut hier precies van?
Je kunt als gebruiker toch nooit controleren of de app die je uit de store download gecompileerd is van de sourcecode
die ze beschikbaar stellen...
En dan nog, wat er in de lokale app gebeurt is als het goed is niet spannend. Geven ze ook de sourcecode van de backend?
Je kunt als gebruiker toch nooit controleren of de app die je uit de store download gecompileerd is van de sourcecode
die ze beschikbaar stellen...
En dan nog, wat er in de lokale app gebeurt is als het goed is niet spannend. Geven ze ook de sourcecode van de backend?
Je kunt als gebruiker ook niet weten of je Ubuntu packages van dezelfde sources zijn gecompileerd als die je kunt downloaden.
Het is natuurlijk makkelijk altijd wat te vinden om over te zeiken.
Gewoon, dat hetzelfde probleem - valideer dat de source bij de binary hoort - ook bij heilige open source speelt .
Maar ik hoor graag van jou *hoe* je precies controleert dat de Ubuntu bin's van exact de sources gecompileerd zijn die in de source packages zitten .
Als je denk "gewoon dat source package builden" - moet je doen . Echt . En dan gaan leren waarom het resultaat niet op dezelfde hash uitkomt.
B.t.w. onze lieve heer kan je ook niet controleren.
In God we trust. All others pay cash^H^H^H show source.
Door Anoniem:
Niet al te basaal denken, majoor .
Het is -als pentester - best erg nuttig om dingen te leren over de opzet en structuur van de backend die niet alleen maar de credentials zijn .
Nog meer als DDoSer, trouwens .
Mijn stelling was dat het weglakken geen zin heeft omdat diezelfde pentester gewoon alle info uit de reguliere APK kan halen. De credentials waren alleen bedoeld als voorbeeld.Door majortom:
Door Anoniem:
self update :
Ah - tikje verder lezen : ook de identiteiten van de devs, en dingen waaruit informatie over de backend servers te herleiden is.
Op zich wel logisch .
Afhankelijk van hoeveel de API geschoond wordt is de app dan mogelijk niet functioneel compileerbeer.
Wat is dat nou weer voor een onzinactie om "vertrouwelijke zaken" weg te lakken. Als er echt zaken in die code zitten die niet openbaar mogen worden dan is het design fout. Ik mag toch aannemen dat er geen passwords, (private) keys of iets dergelijks in de code zitten: dat zou een major security issue betekenen. Met een tool als JADX haal je die info gewoon uit de APK zoals die voor Android te downloaden is, dus weglakken maakt het alleen heel iets lastiger om dit te achterhalen.Door Anoniem: Vertaling 'foto' en 'film' :
Uit de URL :
De broncode van de app is nu nog gepubliceerd als een momentopname; een ‘foto’ van de broncode op een bepaald moment in de tijd.
Waarschijnlijk nu dus een snapshot van een bepaalde versie (tarball) , en later een git of ander version control archief ?
Of standaard snapshots van een release-versie .
Ik verwacht er weinig spannends van , maar het moet gezegd worden : het _is_ een nette actie .
Ik vrees dat het best wat dev tijd kost met naar verhouding erg weinig technisch rendement .
(Nee - niet om "de backdoors te verstoppen" , maar ik denk dat ze allerlei comments op 'incorrect taalgebruik' moeten schonen , want anders heb je weer van die zeikjournalisten die daarop mieren .)
Uit de URL :
De broncode van de app is nu nog gepubliceerd als een momentopname; een ‘foto’ van de broncode op een bepaald moment in de tijd.
Je vindt de broncode nu nog als ‘foto’, maar Logius wil de broncode op termijn als ‘film’ kunnen publiceren. Dan worden ook nieuwe versies steeds openbaar gemaakt. Dat kan nu nog niet, meldt Logius desgevraagd.
Waarschijnlijk nu dus een snapshot van een bepaalde versie (tarball) , en later een git of ander version control archief ?
Of standaard snapshots van een release-versie .
Ik verwacht er weinig spannends van , maar het moet gezegd worden : het _is_ een nette actie .
Ik vrees dat het best wat dev tijd kost met naar verhouding erg weinig technisch rendement .
(Nee - niet om "de backdoors te verstoppen" , maar ik denk dat ze allerlei comments op 'incorrect taalgebruik' moeten schonen , want anders heb je weer van die zeikjournalisten die daarop mieren .)
self update :
Ah - tikje verder lezen : ook de identiteiten van de devs, en dingen waaruit informatie over de backend servers te herleiden is.
Op zich wel logisch .
Afhankelijk van hoeveel de API geschoond wordt is de app dan mogelijk niet functioneel compileerbeer.
Niet al te basaal denken, majoor .
Het is -als pentester - best erg nuttig om dingen te leren over de opzet en structuur van de backend die niet alleen maar de credentials zijn .
Nog meer als DDoSer, trouwens .
Door majortom:
Mijn stelling was dat het weglakken geen zin heeft omdat diezelfde pentester gewoon alle info uit de reguliere APK kan halen. De credentials waren alleen bedoeld als voorbeeld.
Mijn stelling was dat het weglakken geen zin heeft omdat diezelfde pentester gewoon alle info uit de reguliere APK kan halen. De credentials waren alleen bedoeld als voorbeeld.
Uiteindelijk wel - zo blijkt uit het vinden van allerlei zero days in closed source.
Maar becommentarieerde source scheelt toch een bak werk.
Ze zullen bij Logius ongetwijfeld een heleboel meetings gehad hebben over deze hete aardappel .
(iemand die graag laat zien waar z'n kostbaarheden liggen, wat z'n adres is, wanneer hij op vakantie is maar *alleen* de huissleutel erg goed bewaard ? )
17-01-2023, 14:59 door
Joep Lunaar
Door _R0N_:
Je kunt als gebruiker ook niet weten of je Ubuntu packages van dezelfde sources zijn gecompileerd als die je kunt downloaden.
Het is natuurlijk makkelijk altijd wat te vinden om over te zeiken.
A) Publicatie van broncodes is een principiële kwestie, dus kritische opmerkingen zijn in de regel geen gezeik.Door Anoniem: Wat is het nut hier precies van?
Je kunt als gebruiker toch nooit controleren of de app die je uit de store download gecompileerd is van de sourcecode
die ze beschikbaar stellen...
En dan nog, wat er in de lokale app gebeurt is als het goed is niet spannend. Geven ze ook de sourcecode van de backend?
Je kunt als gebruiker toch nooit controleren of de app die je uit de store download gecompileerd is van de sourcecode
die ze beschikbaar stellen...
En dan nog, wat er in de lokale app gebeurt is als het goed is niet spannend. Geven ze ook de sourcecode van de backend?
Je kunt als gebruiker ook niet weten of je Ubuntu packages van dezelfde sources zijn gecompileerd als die je kunt downloaden.
Het is natuurlijk makkelijk altijd wat te vinden om over te zeiken.
B) Distributies als Ubuntu volgen grotendeels Debian. Deze laatste heeft een soort sociaal contract dat zeer stringente eisen stelt aan de toelating van patches in de "main" repository onder volledige openbaarheid. Verder voldoet Debian momenteel aan de vereisten voor reproducible builds van vrijwel alle pakketten in de main repository waardoor wel vaststelbaar is dat een binary daaruit op de code en niets anders dan die code is gebaseerd (even los van de discussie of compilers wel deugen, zie http://cm.bell-labs.com/who/ken/trust.html).
Zie ook https://reproducible-builds.org/who/projects/ en https://wiki.debian.org/ReproducibleBuilds
De distributie door Ubuntu kent ook de nodige waarborgen
Door Joep Lunaar:
B) Distributies als Ubuntu volgen grotendeels Debian. Deze laatste heeft een soort sociaal contract dat zeer stringente eisen stelt aan de toelating van patches in de "main" repository onder volledige openbaarheid. Verder voldoet Debian momenteel aan de vereisten voor reproducible builds van vrijwel alle pakketten in de main repository waardoor wel vaststelbaar is dat een binary daaruit op de code en niets anders dan die code is gebaseerd (even los van de discussie of compilers wel deugen, zie http://cm.bell-labs.com/who/ken/trust.html).
Door _R0N_:
Je kunt als gebruiker ook niet weten of je Ubuntu packages van dezelfde sources zijn gecompileerd als die je kunt downloaden.
Het is natuurlijk makkelijk altijd wat te vinden om over te zeiken.
A) Publicatie van broncodes is een principiële kwestie, dus kritische opmerkingen zijn in de regel geen gezeik.Door Anoniem: Wat is het nut hier precies van?
Je kunt als gebruiker toch nooit controleren of de app die je uit de store download gecompileerd is van de sourcecode
die ze beschikbaar stellen...
En dan nog, wat er in de lokale app gebeurt is als het goed is niet spannend. Geven ze ook de sourcecode van de backend?
Je kunt als gebruiker toch nooit controleren of de app die je uit de store download gecompileerd is van de sourcecode
die ze beschikbaar stellen...
En dan nog, wat er in de lokale app gebeurt is als het goed is niet spannend. Geven ze ook de sourcecode van de backend?
Je kunt als gebruiker ook niet weten of je Ubuntu packages van dezelfde sources zijn gecompileerd als die je kunt downloaden.
Het is natuurlijk makkelijk altijd wat te vinden om over te zeiken.
B) Distributies als Ubuntu volgen grotendeels Debian. Deze laatste heeft een soort sociaal contract dat zeer stringente eisen stelt aan de toelating van patches in de "main" repository onder volledige openbaarheid. Verder voldoet Debian momenteel aan de vereisten voor reproducible builds van vrijwel alle pakketten in de main repository waardoor wel vaststelbaar is dat een binary daaruit op de code en niets anders dan die code is gebaseerd (even los van de discussie of compilers wel deugen, zie http://cm.bell-labs.com/who/ken/trust.html).
Het vergt een zeker werk _om_ builds reproducible te maken , en (zelfs) Debian , is, zoals je schrijft , niet met alles klaar.
(Niet hoopgevend dat de wiki https://wiki.debian.org/ReproducibleBuilds als status van 2018 geeft dat 1250 unreproducible packages nog in buster zitten . De oranje en rood delen van de graph zijn ook weer niet heel klein .)
Het is leerzaam om te lezen van welke factoren het uiteindelijke resultaat allemaal afhankelijk is .
Ubuntu staat niet op de lijst van projecten die reproducible zijn . Dat het "in principe" veelal debian gebaseerd is, is mooi - maar de vraag is hoeveel van de ubuntu-eigen saus de reproducibility om zeep geholpen heeft.
Zie ook https://reproducible-builds.org/who/projects/ en https://wiki.debian.org/ReproducibleBuilds
De distributie door Ubuntu kent ook de nodige waarborgen
Ik denk dat poster 17 jan 10:28 die botweg stelde dat je Ubuntu source-dist kunt controleren geen flauw benul had van hoeveel werk het is om een reproducible build te maken , en zeker niet dat Ubuntu daarin niet echt voorop loopt .
Welke waarborgen doel je op qua 'distributie door Ubuntu' ?
Waarborgen dat je ongewijzigde distro's of updates download klopt wel .
Maar bij de vraag of de binary van iets nou wel bij de gepubliceerde source hoort - waarin je dus de oprechtheid (of competentie) van je leverancier in twijfel ben ik benieuwd welke waarborgen je daar krijgt van Ubuntu .
Het werk van reproducible builds is IMO erg belangrijk om een stuk van het vertrouwen dat je typisch hebt in "open source" ook echt te onderbouwen . En ze zijn er nog lang niet.
Door Anoniem:
Het vergt een zeker werk _om_ builds reproducible te maken , en (zelfs) Debian , is, zoals je schrijft , niet met alles klaar.
(Niet hoopgevend dat de wiki https://wiki.debian.org/ReproducibleBuilds als status van 2018 geeft dat 1250 unreproducible packages nog in buster zitten . De oranje en rood delen van de graph zijn ook weer niet heel klein .)
Het is leerzaam om te lezen van welke factoren het uiteindelijke resultaat allemaal afhankelijk is .
Ubuntu staat niet op de lijst van projecten die reproducible zijn . Dat het "in principe" veelal debian gebaseerd is, is mooi - maar de vraag is hoeveel van de ubuntu-eigen saus de reproducibility om zeep geholpen heeft.
Zie ook https://reproducible-builds.org/who/projects/ en https://wiki.debian.org/ReproducibleBuilds
De distributie door Ubuntu kent ook de nodige waarborgen
Ik denk dat poster 17 jan 10:28 die botweg stelde dat je Ubuntu source-dist kunt controleren geen flauw benul had van hoeveel werk het is om een reproducible build te maken , en zeker niet dat Ubuntu daarin niet echt voorop loopt .
Welke waarborgen doel je op qua 'distributie door Ubuntu' ?
Waarborgen dat je ongewijzigde distro's of updates download klopt wel .
Maar bij de vraag of de binary van iets nou wel bij de gepubliceerde source hoort - waarin je dus de oprechtheid (of competentie) van je leverancier in twijfel ben ik benieuwd welke waarborgen je daar krijgt van Ubuntu .
Het werk van reproducible builds is IMO erg belangrijk om een stuk van het vertrouwen dat je typisch hebt in "open source" ook echt te onderbouwen . En ze zijn er nog lang niet.
Ik heb veel meer vertrouwen in de Ubuntu/Debian maintainers dan Microsoft. Dat de gesigneerde binaries gebouwd zijn vanaf de gepubliceerde sources heb ik het volste vertrouwen in, gezien de openheid waarmee dit gebeurd. Het thema is trouwens dat een snapshot van de broncode van de DigiD-app openbaar wordt gemaakt. Dat is een mooi begin. Ubuntu/Debian is alleen maar een mooi voorbeeld hoe het kan. Dat het uiteraard misschien nog beter kan is in deze context gezeik.Door Joep Lunaar:
B) Distributies als Ubuntu volgen grotendeels Debian. Deze laatste heeft een soort sociaal contract dat zeer stringente eisen stelt aan de toelating van patches in de "main" repository onder volledige openbaarheid. Verder voldoet Debian momenteel aan de vereisten voor reproducible builds van vrijwel alle pakketten in de main repository waardoor wel vaststelbaar is dat een binary daaruit op de code en niets anders dan die code is gebaseerd (even los van de discussie of compilers wel deugen, zie http://cm.bell-labs.com/who/ken/trust.html).
Door _R0N_:
Je kunt als gebruiker ook niet weten of je Ubuntu packages van dezelfde sources zijn gecompileerd als die je kunt downloaden.
Het is natuurlijk makkelijk altijd wat te vinden om over te zeiken.
A) Publicatie van broncodes is een principiële kwestie, dus kritische opmerkingen zijn in de regel geen gezeik.Door Anoniem: Wat is het nut hier precies van?
Je kunt als gebruiker toch nooit controleren of de app die je uit de store download gecompileerd is van de sourcecode
die ze beschikbaar stellen...
En dan nog, wat er in de lokale app gebeurt is als het goed is niet spannend. Geven ze ook de sourcecode van de backend?
Je kunt als gebruiker toch nooit controleren of de app die je uit de store download gecompileerd is van de sourcecode
die ze beschikbaar stellen...
En dan nog, wat er in de lokale app gebeurt is als het goed is niet spannend. Geven ze ook de sourcecode van de backend?
Je kunt als gebruiker ook niet weten of je Ubuntu packages van dezelfde sources zijn gecompileerd als die je kunt downloaden.
Het is natuurlijk makkelijk altijd wat te vinden om over te zeiken.
B) Distributies als Ubuntu volgen grotendeels Debian. Deze laatste heeft een soort sociaal contract dat zeer stringente eisen stelt aan de toelating van patches in de "main" repository onder volledige openbaarheid. Verder voldoet Debian momenteel aan de vereisten voor reproducible builds van vrijwel alle pakketten in de main repository waardoor wel vaststelbaar is dat een binary daaruit op de code en niets anders dan die code is gebaseerd (even los van de discussie of compilers wel deugen, zie http://cm.bell-labs.com/who/ken/trust.html).
Het vergt een zeker werk _om_ builds reproducible te maken , en (zelfs) Debian , is, zoals je schrijft , niet met alles klaar.
(Niet hoopgevend dat de wiki https://wiki.debian.org/ReproducibleBuilds als status van 2018 geeft dat 1250 unreproducible packages nog in buster zitten . De oranje en rood delen van de graph zijn ook weer niet heel klein .)
Het is leerzaam om te lezen van welke factoren het uiteindelijke resultaat allemaal afhankelijk is .
Ubuntu staat niet op de lijst van projecten die reproducible zijn . Dat het "in principe" veelal debian gebaseerd is, is mooi - maar de vraag is hoeveel van de ubuntu-eigen saus de reproducibility om zeep geholpen heeft.
Zie ook https://reproducible-builds.org/who/projects/ en https://wiki.debian.org/ReproducibleBuilds
De distributie door Ubuntu kent ook de nodige waarborgen
Ik denk dat poster 17 jan 10:28 die botweg stelde dat je Ubuntu source-dist kunt controleren geen flauw benul had van hoeveel werk het is om een reproducible build te maken , en zeker niet dat Ubuntu daarin niet echt voorop loopt .
Welke waarborgen doel je op qua 'distributie door Ubuntu' ?
Waarborgen dat je ongewijzigde distro's of updates download klopt wel .
Maar bij de vraag of de binary van iets nou wel bij de gepubliceerde source hoort - waarin je dus de oprechtheid (of competentie) van je leverancier in twijfel ben ik benieuwd welke waarborgen je daar krijgt van Ubuntu .
Het werk van reproducible builds is IMO erg belangrijk om een stuk van het vertrouwen dat je typisch hebt in "open source" ook echt te onderbouwen . En ze zijn er nog lang niet.
Als je op Android draait - dan heb je google play store nodig voor het barcode scannen. Adios Lineage, GrapheneOS, E/OS ... zoveel voor "Privacy" ... treurig te zien dat wij als een van het innovatiefste landen ter wereld niet eens een simpele barcode scanner zonder Google in een software kunnen plakken.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Information Security Officer (2fte)
Een uitdagende rol waarbij jij, op basis van security, de vertaalslag maakt tussen business en IT en direct bijdraagt aan de veiligheid van informatie binnen de gemeente Almere. Dat is in een notendop waar jij als Information Security Officer mee bezig bent. Interesse gewekt? Door groei van de organisatie zijn we op zoek naar twee nieuwe collega’s.
Specialiseer je in Forensisch ICT
Online informatieavond 19 november
Wil jij je specialiseren in digitaal forensisch onderzoek? Je kennis verbreden en tech-nische vaardigheden ontwikkelen? Ontdek de cursus- en opleidingsmogelijkheden van Hogeschool Leiden:
- Bachelor Informatica Forensisch ICT (deeltijd)
- Master Digital Forensics (vol- en deeltijd)
- Module Mobile Forensics
- Module Data Analytics
Interesse? Meld je aan!
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
