From he at uninett.no Mon May 6 07:43:40 2024 From: he at uninett.no (Havard Eidnes) Date: Mon, 06 May 2024 09:43:40 +0200 (CEST) Subject: [RPKI] routinator download-during-build Message-ID: <20240506.094340.746754757783685711.he@uninett.no> Hi, I'm the maintainer of the pkgsrc package for routinator, ref. https://github.com/NetBSD/pkgsrc/tree/trunk/net/routinator In pkgsrc we have code to extract cargo dependencies, to download them in a separate "fetch" phase, checksum all the constituent components and verify that none of the components have changed since the program was packaged. As part of this there has always been an implicit policy to disallow "downloads" during the "build" phase, for several reasons: * Components may change in unverified manners * The build system may be offline * The build may produce different results compared to what it did when the program was packaged and recently constructs were added to pkgsrc to enforce this "no downloads during the build phase" by setting a proxy URL with a non-resolvable host name during that phase. And ... of course, routinator trips up over this check. The build.rs program in the routinator-ui crate has explicit code to itself download routinator-ui-build.tar.gz from github, and this would then constitute a violation of the above rules. I guess there are "reasons" why this code is there, and the routinator-ui-build.tar.gz contents can't be referred to by an entry in a Cargo.toml file? It is however annoying if not to say disconcerning that we can't verify all the constituent components. Can anything be done to routinator to not violate the "no download during build phase" rule? Best regards, - H?vard From martin at nlnetlabs.nl Mon May 6 08:36:03 2024 From: martin at nlnetlabs.nl (Martin Hoffmann) Date: Mon, 6 May 2024 10:36:03 +0200 Subject: [RPKI] routinator download-during-build In-Reply-To: <20240506.094340.746754757783685711.he@uninett.no> References: <20240506.094340.746754757783685711.he@uninett.no> Message-ID: <20240506103604.64383cc8@glaurung.nlnetlabs.nl> Hi H?vard, Havard Eidnes via RPKI wrote: > > Can anything be done to routinator to not violate the "no > download during build phase" rule? Yes! We recently rebuilt the UI from scratch and as part of that we also changed how it is integrated into Routinator. Last week we merged that PR (https://github.com/NLnetLabs/routinator/pull/952). The UI?s assets are now included in the regular Routinator repository and routinator-ui will be deprecated. I have a few smaller items left that I want to include in the 0.14.0 release, but I hope to get the the RC out very soon. -- Martin From martin at nlnetlabs.nl Wed May 29 14:31:01 2024 From: martin at nlnetlabs.nl (Martin Hoffmann) Date: Wed, 29 May 2024 16:31:01 +0200 Subject: [RPKI] RTRTR 0.3.0-rc1 released Message-ID: <20240529163101.4b16e802@glaurung.nlnetlabs.nl> Hello! We have just published the first release candidate of the upcoming version 0.3.0 of RTRTR. Perhaps the most important new feature is the merge unit which merges the data from all its configured sources. The RTR target has gained a number of useful metrics similar to what Routinator already has. Under the hood, there were a number of improvements to how units communicate that should races during start-up where RTRTR sometimes missed the first update. If you want to test this release candidate, you can install it via cargo by running cargo install -f --version 0.3.0-rc1 --locked rtrtr Binary packages are available via the -proposed channels. On behalf of the NLnet Labs Routing Team, Martin From tomh at apnic.net Wed May 29 23:30:03 2024 From: tomh at apnic.net (Tom Harrison) Date: Thu, 30 May 2024 09:30:03 +1000 Subject: [RPKI] BPKI TA expiry handling Message-ID: Hi, At APNIC, we are currently testing how Krill handles the expiry of BPKI TA material (i.e. RFC 8183's parent_response.parent_bpki_ta and repository_response.repository_bpki_ta CA certificates). It appears that Krill will not accept either a parent_response or a repository_response if the CA certificate in that response is expired, which makes sense. However, if the CA certificate expires later, it appears that Krill will continue to successfully make use of the relevant service notwithstanding the expiry. Assuming that's correct, is this behaviour that we can rely on into the future, or is there a chance that this will change such that the expiry of the CA certificate causes subsequent service interactions to fail? Separately, it is not clear how a delegated CA operator should update its repository details to account for the BPKI TA expiry event. On calling "krillc repo configure" with updated repository_response XML, Krill prints the error "CA '...' already uses this repository". (The corresponding "krillc parents add" update operation works as expected, though.) What does a delegated CA operator need to do (if anything) to handle the expiry of the repository_response BPKI TA? -Tom