routinator
routinator copied to clipboard
NLnetLabs
Consider updating bundled TALs.
New versions of Routinator often come with updated versions of the bundled TAL files. However, Routinator will not use those unless routinator init is run again for the updated version. This means that many people won’t get the updated version.
The question is: is this okay or should we provide a means to detect and/or automatically update installed outdated TALs.
Things to consider here:
- There should be no surprises to the user.
- Updating TALs on disk may not be possible due to permissions.
- Might a user may want to keep the old TAL for some reason?
- Interaction with alternative means of installing TALs such as via the system’s package management.
So, consider whether to provide such a means and, if so, how it should work.
This is a sensible summary of the issues.
things like apt update do $(mv thing, thing.orig) and like models
I would really like to hear other people's opinions, and especially users wrt their expectations.
That said I would propose:
- do not change TALs on disk
- instead keep a mapping to new URIs for known outdated TALs (matching known file hash) in routinator
- do NOT map to new keys, ever
- do NOT map for TALs that are still current (i.e. hash does not match known outdated)
- do NOT map for TALs where the URIs have been tweaked by the user (i.e. hash does not match known outdated)
The main point then is, that if e.g. a user accepted the original TAL for apnic and we know that new URIs are applicable, it is safe to assume that the user would want to use them.
But this is really just my 2cts. I want to put this out here though to hear if others would agree or have different suggestions.
@timbru I definitely agree with not changing TALs on disk. Even if this would be possible, configuration management would replace old TALs in some setup and restart routinator afterwards. Even though it's an application private directory, it ends up being managed by CMS because it was the only way to configure TALs.
Another point to consider is the principle of least astonishment. As a user, I would generally expect my configuration on disk to match the configuration that is actually applied. Because only a minority of users probably wants this behaviour and opt-out through configuration feels like the way to go.
Another point to consider is the principle of least astonishment. As a user, I would generally expect my configuration on disk to match the configuration that is actually applied. Because only a minority of users probably wants this behaviour and opt-out through configuration feels like the way to go.
Well.. what is least astonishment? If I configured a TAL once I may expect it to just keep working. So you could also argue that least astonishment would be to try known locations for a known TAL file*. Most users would not even notice, because your RP software needs to be allowed to make https and rsync connections to anywhere anyhow.
I find it hard to assume what a majority or minority of users would want here.
*: if only there were a standards way of communicating updated TALs to users.. ;)
In this discussion we should perhaps also consider the existence of solutions like https://tracker.debian.org/pkg/rpki-trust-anchors
Re-reading this discussion – thank you, everone! – it looks to me like we should just not change anything in code but rather leave it to package management to do in whatever way is correct for them.