Als beheerder van een standaard wil ik dat de referentie implementaties up to date gehouden worden
Opened this issue · 2 comments
...zodat deze voldoen aan alle veiligheidseisen en er geen onnodige risico's gelopen worden door gebruikers.
NB. Dit gaat niet alleen over het uitrollen van nieuwe versies, ook fixes in de omgevingen (programmeertaal, framework, ?) waarin de RI's gemaakt zijn moeten worden uitgerold.
De RI moet dus opnieuw gecompileerd (waar van toepassing) en in een docker container ingepakt worden om vervolgens gedeployed te worden op de omgeving waar deze komt te draaien.
Dit is denk ik wel een argument om niet teveel verschillende programmeeromgevingen te willen ondersteunen in een RI, bij voorkeur slechts één. Hoe meer verschillende omgevingen/tooling we hebben hoe meer werk dit is.
Om een voorbeeld te noemen:
We krijgen als GitHub beheerder regelmatig mailtjes met daarin security meldingen die in de diverse GitHub repositories optreden. Dat kan gaan om aangetroffen gaten in gebruikte libraries.
Deze gaten moeten gedicht worden door updates uit te voeren.
Aangezien API Beheer (vooralsnog) niet zelf wijzigingen gaat aanbrengen in de software van de RI's zullen ook deze wijzigingen aangebracht moeten worden door de partij waaraan de bouw is uitbesteed maar wel onder Regie van API Beheer. De opdracht daartoe zullen wij uit moeten zetten.
Als we dit soort wijzigingen in de toekomst inderdaad allemaal zelf willen kunnen uitvoeren dan is het n.m.m. inderdaad een argument om het aantal talen zo minimaal mogelijk te houden.
Enkele vragen die dan bij mij boven komen:
- Is een opnieuw gebouwde referentie implementatie die mogelijk ander gedrag kan vertonen ook meteen een nieuwe versie van de standaard?
- Kan dit bij de leverancier die de referentie implementatie gebouwd heeft belegd worden? Valt dit onder regulier onderhoud?
- wat zijn de risico's die we lopen? Kan een RI gebruikt worden voor het verspreiden van virussen/malware of in een cyber aanval?