Open-sourcing of the RIPE NCC’s RPKI core software
Dear colleagues, We are pleased to announce that we have published the source code used by the RIPE NCC for the RPKI back-end (the RPKI core) under the 3-Clause BSD licence on Github: https://github.com/RIPE-NCC/rpki-core <https://github.com/RIPE-NCC/rpki-core> The RPKI core is the RIPE NCC's software for creating and maintaining RPKI objects based on the registry's current status and publishing these in the repositories. The RIPE NCC hosts the authoritative repository internally. We use the repository on Github to publish the source code externally. The first commit is identical to the source code in the RIPE NCC's internal repository at the time of that commit. The changes between releases are squashed and published to this repository on deployment, and the `main` branch reflects the code used by the production CA. We encountered several challenges while preparing this project for an open-source release. The main challenges were that the system uses proprietary elements that were part of the revision history and cannot be made public. Furthermore, it was not possible to review all historic commits. We plan to present our challenges while open-sourcing this project at RIPE 84. If you have any questions about this change, please contact the RIPE NCC's RPKI team at rpki@ripe.net <mailto:rpki@ripe.net>. Kind Regards, Bart Bakker Senior Software Engineer RIPE NCC
Dear RIPE NCC RPKI team, On Wed, Feb 09, 2022 at 10:26:14AM +0100, Bart Bakker wrote:
We are pleased to announce that we have published the source code used by the RIPE NCC for the RPKI back-end (the RPKI core) under the 3-Clause BSD licence on Github: https://github.com/RIPE-NCC/rpki-core The RPKI core is the RIPE NCC's software for creating and maintaining RPKI objects based on the registry's current status and publishing these in the repositories.
Congratulations on this accomplishment and achieving this milestone! https://sobornost.net/~job/clap.gif :-) In the realm of cryptography, full transparency - unlimited and unrestricted access to source code is a critical cornerstone for building systems that can be relied upon.
The RIPE NCC hosts the authoritative repository internally. We use the repository on Github to publish the source code externally. The first commit is identical to the source code in the RIPE NCC's internal repository at the time of that commit. The changes between releases are squashed and published to this repository on deployment, and the `main` branch reflects the code used by the production CA.
Am I right in assuming that - going forward - commits won't be squashed (more than needed)? I imagine it'll be educational for the community to be able to follow the train of thought and storyline of future developments.
We encountered several challenges while preparing this project for an open-source release. The main challenges were that the system uses proprietary elements that were part of the revision history and cannot be made public. Furthermore, it was not possible to review all historic commits. We plan to present our challenges while open-sourcing this project at RIPE 84.
I look forward to the stories. Kind regards, Job
Dear Job,
On 9 Feb 2022, at 10:45, Job Snijders via routing-wg <routing-wg@ripe.net> wrote:
Congratulations on this accomplishment and achieving this milestone!
Thank you.
Am I right in assuming that - going forward - commits won't be squashed (more than needed)? I imagine it'll be educational for the community to be able to follow the train of thought and storyline of future developments.
We have chosen to squash our internal commits on publication. The main reason for doing this is that the public repository is a completely different tree from our internal code tree. While we could transplant (rebase) individual commits to the new tree, we cannot transplant merge commits. Hence we would risk losing changes in merge commits (often resolution to merge conflicts) and break the published code. We do see value in giving the community access to the code as well as the commits that lead to it. Therefore we add the titles and internal refs of all included commits in the body of the squashed commit. An example of this is in [1]. We do release frequently. Therefore most patches between releases are small and contain a limited number of changes. These patches are often incremental and show the direction we are following with development. We hope this helps build an understanding of why we choose this publication scheme. [1] - https://github.com/RIPE-NCC/rpki-core/commit/2d83b6aa197cffe7974391dbafb439e... Kind regards, Bart Bakker RIPE NCC
Bart & Team, Thanks, awesome that you are able to push this public. Indeed, it is not easy to open closed software after the fact, keeping separate repos often helps in clearly keeping the code separate with minimal interaction with proprietary code. Please do PGP-sign each commit, so that people can verify that the code is authentic and published by the correct source. Greets, Jeroen
Bart, On 09/02/2022 10.26, Bart Bakker wrote:
We are pleased to announce that we have published the source code used by the RIPE NCC for the RPKI back-end (the RPKI core) under the 3-Clause BSD licence on Github: https://github.com/RIPE-NCC/rpki-core <https://github.com/RIPE-NCC/rpki-core>
Wow that's awesome! Having this open source is definitely a good thing, and I realize it must have been a lot of work. The documentation seems clear, and I love design notes. 😆 I'm a little disappointed that you didn't choose a copyleft style license, like with the RIPE Atlas Software Probe, which uses GPLv3. That would help ensure that the work of the RIPE NCC employees is not used by a proprietary product or service by a company unwilling or unable to share their changes. Probably in the presentation at RIPE 84 there will be a bit of explanation about the choice of using a license so easy to convert back to closed source. 😉 Cheers, -- Shane
Hi, On Thu, Feb 10, 2022 at 06:35:35PM +0100, Shane Kerr wrote:
I'm a little disappointed that you didn't choose a copyleft style license, like with the RIPE Atlas Software Probe, which uses GPLv3. That would help ensure that the work of the RIPE NCC employees is not used by a proprietary product or service by a company unwilling or unable to share their changes. Probably in the presentation at RIPE 84 there will be a bit of explanation about the choice of using a license so easy to convert back to closed source. ????
Just to express a contrapoint - I'm happy that it's not GPLv3, as that license is really intent on getting in the way of getting stuff done. So if someone wants to set up a high-quality RPKI registry with that code base, why shouldn't they? It's not like the NCC is a poor enthusisist that will lose the fruit of years of work to evil companies - and the market for "we will turn this into a highly successful product, stealing all the NCC's work" is not exactly large either. So, MIT is fine with me, and if someone wants to build a commercial RPKI product based on quality source, even better. (I've dealt with MIT and GPLv3 source in the past, and contributed to projects under various licenses, and the only ones that always create friction is the GPL camp. Like "no, you cannot link your GPLv3 program with a library that is Apache licensed") Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi, On Thu, Feb 10, 2022 at 6:35 PM Shane Kerr <shane@time-travellers.org> wrote:
I'm a little disappointed that you didn't choose a copyleft style license, like with the RIPE Atlas Software Probe, which uses GPLv3. That would help ensure that the work of the RIPE NCC employees is not used by a proprietary product or service by a company unwilling or unable to share their changes. Probably in the presentation at RIPE 84 there will be a bit of explanation about the choice of using a license so easy to convert back to closed source. 😉
There are issues regardless of what license you pick and remember that there are proprietary HSM dependencies used, which could potentially cause issues with GPLv3 for the NCC itself as far as I understand it. -Cynthia
participants (6)
-
Bart Bakker -
Cynthia Revström -
Gert Doering -
Jeroen Massar -
Job Snijders -
Shane Kerr