In general, the openmetrics Content-Type is preferred. The code makes
an exception out of browsers, however.
The full logic is
- If the request has no Accept header, Content-Type will be openmetrics
1.0.0.
- If the Accept header expects neither openmetrics nor plaintext,
Content-Type will be plaintext 0.0.4.
This is because the client is usually a browser (which seem to typically
lack Openmetrics handlers) or a generic HTTP client like curl (which
don't really care about Content-Type).
- Otherwise Fort will decide between openmetrics 1.0.0 or plaintext
0.0.4, depending on q-values. (Requested version will be ignored,
because only one is supported for each.) If their q is the same,
openmetrics will be preferred.
fort_valid_vrps_total{ta="<TA>",proto="ipv<IP>"}
Total VRPs generated from TA <TA> (and the given
protocol) during the previous cycle.
"<TA>" is inferred from the TAL's file name.
fort_rtr_current_connections
Number of active RTR clients.
To activate the server, set --mode=server and --prometheus.port to an
allowed and available port number.
Stop rejecting RPPs if unrecognizable absent files are fileListed
RFC 9286:
> The RP MUST acquire all of the files enumerated in the manifest
> (fileList) from the publication point. If there are files listed in
> the manifest that cannot be retrieved from the publication point,
> the RP MUST treat this as a failed fetch.
This was clashing with Fort's default rsync filters because they were
preventing unknown extensions from being downloaded:
Which will be a problem whenever the IETF defines new legal repository
extensions, such as .asa.
Therefore, ignore unknown manifest fileList extensions. This technically
violates RFC 9286, but it's necessary evil given that we can't trust
repositories to always only serve proper RPKI content.
The code was assuming the object was DER-encoded, and the relevant
integer was therefore in short form.
Because I postponed the DER enforcement in deef7b7823f21914b17838f152a8bd510a348f54, the code should not make
reckless assumptions about the signedAttrs encoding.
Job Snijders [Tue, 25 Jun 2024 05:21:39 +0000 (05:21 +0000)]
Generate all permutations of the list with equal probability
@botovq was kind enough to point out that although my earlier
implementation produced random-ish ordering, it strictly speaking
wasn't Fisher-Yates.
We need to ensure `j` is a random number between `i` and `list.count`
see the second example in the 'Modern Algorithm'
https://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle
Job Snijders [Thu, 13 Jun 2024 18:21:36 +0000 (18:21 +0000)]
Shuffle the order in which Manifest entries are processed
Previously work items were enqueued in the order the CA intended them
to appear on a Manifest. However, there is no obvious benefit to letting
third parties decide the order in which objects are processed.
Instead, randomize the list of FileAndHashes, its ordering has no meaning
anyway. As they say, a fox is not taken twice in the same snare
Job Snijders [Fri, 7 Jun 2024 17:09:44 +0000 (17:09 +0000)]
Verify the signature on a self-signed TA cert against it's own pubkey
X509_verify_cert() doesn't check the purported root certificate itself
unless X509_V_FLAG_CHECK_SS_SIGNATURE is set.
The pubkey was compared against the TAL, so check that the signature is
right as required by RFC 6487, section 7, additional condition 1,
applied to self-issued certs.
The error check looks weird, but OpenSSL 3 broke yet another API.
X509V3_EXT_print() was being summoned to print extensions unrelated to
RPKI. The TODO wanted me to pick a suitable flag for extensions unknown
even to libcrypto.
For reference, this is how X509V3_EXT_print() prints an AIA, as a known
extension:
CA Issuers - URI:rsync://rpki.ripe.net/repository/aca/KpSo3VVK5wEHIJnHC2QHVV3d5mk.cer
This is how X509V3_EXT_print() prints the same AIA, as an unknown
extension, X509V3_EXT_PARSE_UNKNOWN enabled:
These two quirks made the validation mostly a no-op.
There's also the issue that this implementation seems inefficient,
especially since Fort doesn't need to DER-encode anywhere else. By
checking the encoding while parsing, I would save a lot of memory
in addition to being able to delete that mess of encoding functions.
But I'm going to have to push that to the future. This is growing more
ambitious than I can afford during a release review, and given that the
code wasn't really doing anything productive in the first place, I'm not
losing much by simply axing it for now.
- Employ libssl's OID parsing rather than implement it from scratch.
- Rename `struct signed_object_args` to `struct ee_cert`, since it's
just a bunch of EE certificate data.
- Remove `struct signed_data`, because it wasn't actually contributing
anything.
rsync cannot download into standard output... which means rsync'd files
cannot be elegantly piped as standard output to --mode=print. So either
the rsync has to be done manually by the user... or --mode=print has to
do it internally by itself.
And looking at the code that resulted... I now wish I had gone with the
former option. Because of the long overdue cache refactors, the user
needs to include --tal for this rsync to be compatible with the cache.
This sucks.
As a workaround, Fort will rsync into /tmp if --tal and/or --local-cache
aren't supplied:
$ fort --mode=print \
--validation-log.enabled \
--validation-log.level debug \
rsync://a.b.c/d/CRL.crl
...
May 10 13:32:44 DBG [Validation]: Executing rsync:
May 10 13:32:44 DBG [Validation]: rsync
May 10 13:32:44 DBG [Validation]: ...
May 10 13:32:44 DBG [Validation]: rsync://a.b.c/d/CRL.crl
May 10 13:32:44 DBG [Validation]: /tmp/fort-Q7tMhz/CRL.crl
...
{
"tbsCertList": {
"version": 1,
...
Fort used to clear the --output.roa and --output.bgpsec files to make
sure they were writable, during early validations.
So this is why the files spent so much time being empty! This was not
acceptable. It didn't even guarantee the files would still remain
writable by the time Fort needed to properly populate them.
This function was always including the binary flag ("b") during
fopen(2), which seems to be inappropriate for the --output.roa and
--output.bgpsec files.
Well, the Unixes don't do anything with this flag, so this is more of a
semantic fine-tune than a bugfix.