Improve compliance with RFC 9589

As of 9589, the CMS SigningTime attribute is mandatory and the
CMS BinarySigningTime attribute is forbidden.

Update Docker

Add CVE "reference" sketch

Protocolary updates for release 1.6.3

Review of #includes

Now featuring local includes too.

Remove redundant forward declarations in ASN1

Prevent crash on BER-encoded signedAttrs

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.

Thanks to Niklas Vogel for reporting this.

Prevent crash on missing eContent

Applies to the RouteOriginAttestation and Manifest octet strings.

Thanks to Niklas Vogel for reporting this.

Prevent crash on missing signedAttrs

Though RPKI enforces the presence of this field, it is very much
optional in CMS.
Also adds missing validation messages in relevant error paths.

Thanks to Niklas Vogel for reporting this.

Prevent crash on missing Authority Key Identifier

Another missing NULL check.

Thanks to Niklas Vogel for reporting this.

Prevent crash on malformed Key Usage

Key Usage bit strings longer than 2 bytes were inducing buffer overflow.

Thanks to Niklas Vogel for reporting this.

Prevent crash on malformed subjectPublicKey

A malformed subjectPublicKey causes X509_PUBKEY_get0() to return NULL.
Fort wasn't catching this when linked specifically to OpenSSL < 3.

Thanks to Niklas Vogel for reporting this.

Use HTTP compressed encoding when available

This reduces network traffic by about 50%.

Clarify why CRL Number extensions do not need to be processed

rand_r(): Separate seed and random number

Enforces originally intended usage of rand_r()'s API.
Mostly just paranoia, maybe.

Use thread-safe PRNG

rand() isn't thread-safe on all platforms (musl libc for example)
use rand_r() instead

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

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

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.

With help from Theo Buehler and Claudio Jeker

Fix relax_ng_log_str_err() signature for old libxml2 versions

Pull request #137 fixes relax_ng_log_str_err()'s argument list for
libxml2 2.12 and above, but breaks it for libxml2 2.11 and below.

Simplify XML reader error handler

No need to check if ptr[strlen(ptr) - 1] is '\n' because because C
strings always end with a null-byte.

Fix build failure with GCC 14 due to -Wincompatible-pointer-types

Reported downstream at https://bugs.gentoo.org/928331

Update APNIC TALs

Their "current" TALs are not the ideal ones. Switch to the ones that
feature HTTP.

Spawned by #133.

Update Docker

Final protocolary updates for release 1.6.2

Fix unit tests

Restore the "now you can connect your routers" WRN

Requested by #133. Temporal fix.

Fix most of the -Wnon-pointer-null violations

The cgcc review no longer needs -Wno-non-pointer-null.

Mirror 1165270e73508b9fb3dfdc0294a5926d56679c75 in other d2i's

Also, fix memory leak in signed_data.c.

Add documentation for --mode=print

Change --server.address default

The old default had been causing mayhem on Linux since
202e0fe34dc3c8dcb1a0ad12faa7f4d5a7c91b2d.

The new default is OS-sensitive, and binds the socket to all available
IPv4 and IPv6 addresses.

Stop using BIO_read_ex()

It's not LibreSSL-compatible.

Straighten up #includes

Also, remove cyclical #includes, to further automate this.

Add roadmap to the site

Still not referenced by the index; needs discussion still.

Merge branch 'carlosm3011-main'

Merge some duplicate code

New rule: BIOs no longer allowed in ASN1 JSON functions outside of
libcrypto_util.c.

FIX TODO: not validating @alg

False alarm; the getter was just redundant. @alg was beind validated at
validate_certificate_public_key_algorithm().

Fix TODO: Use extension_metadata.destructor more

This frees the extension callbacks from having to decode and free the
extensions themselves.

Fix TODO: Choose a X509V3_EXT_print() flag

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:

        0:d=0  hl=2 l=  82 cons: SEQUENCE
        2:d=1  hl=2 l=  80 cons: SEQUENCE
        4:d=2  hl=2 l=   8 prim: OBJECT            :CA Issuers
       14:d=2  hl=2 l=  68 prim: cont [ 6 ]

This is how X509V3_EXT_print() prints the same AIA, as an unknown
extension, X509V3_EXT_DUMP_UNKNOWN enabled:

    0000 - 30 52 30 50 06 08 2b 06-01 05 05 07 30 02 86 44   0R0P..+.....0..D
    0010 - 72 73 79 6e 63 3a 2f 2f-72 70 6b 69 2e 72 69 70   rsync://rpki.rip
    0020 - 65 2e 6e 65 74 2f 72 65-70 6f 73 69 74 6f 72 79   e.net/repository
    0030 - 2f 61 63 61 2f 4b 70 53-6f 33 56 56 4b 35 77 45   /aca/KpSo3VVK5wE
    0040 - 48 49 4a 6e 48 43 32 51-48 56 56 33 64 35 6d 6b   HIJnHC2QHVV3d5mk
    0050 - 2e 63 65 72                                       .cer

Eh. These are good and all, but they mess up the JSON, so I decided to
dump these as octet strings instead:

        3052305006082b0601050507300286447273796e633a2f2f72706b692e726970
        652e6e65742f7265706f7369746f72792f6163612f4b70536f3356564b357745
        48494a6e484332514856563364356d6b2e636572

Merge some duplicate code

Privatize the asn_codec_ctx_t into the ASN.1 code

Fort has `--asn1-decode-max-stack`, a global configuration option for
the maximum stack usage. So there's no need to pass this as an argument.

Remove the DER validator

rfc6488#3.1.l states we need to check "the signed object is DER
encoded." But that's not what this code was doing.

First, the validation was only kicking in specifically during the
decoding of the ContentInfo, which is just the outermost layer of the
signed object.

Second, the validation was incorrect. This seems to be the intended
algorithm in pseudocode:

boolean is_der_encoded(original_bytes):
der_bytes = der_encode(ber_decode(original_bytes));
return (original_bytes equal der_bytes);

This is what the code was actually doing:

boolean is_der_encoded(original_bytes):
der_bytes = der_encode(ber_decode(original_bytes));
return (original_bytes.length equals der_bytes.length);

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.

General pre-release review and testing

- 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.

Spread error messages in --mode=print's failure paths

They're probably not very helpful themselves, but the stack traces
might serve as an admittedly inelegant way to infer the xpath to the
problem.

Otherwise, this could only be fixed by switching to a different JSON
library. But that's a problem for another decade.

Automatically download if file is an rsync URL

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,
...

Patch TODO: Stop accessing GENERAL_NAME attributes directly

Patch TODO: Always release decoded BER, even on error

Reindent

Reduce 80 column limit violations in the ASN1 code.

Patch bad array indexing

Review jsonification

They want Fort to jsonify more faithfully to the ASN1 grammar,
rather than human-friendlier.

A --human-readable flag wouldn't go amiss, but I should probably waint
until someone requests it.

Add sequence BIO

It's a BIO that concatenates two other BIOs when reading.
Needed so the file parser can read the file header twice, without using
rewind(3).

(Which can't be used while piping, as it turns out.)

This allows printing a subfile from a delta or snapshot:

$ xmlstarlet sel -t -v "//_:publish[2]" delta.xml |
base64 --decode |
fort --mode=print

Patch memory leaks and bad memory accesses

Allow --mode=print to read file from stdin

Either works:

$ fort --mode=print   < cert.cer
$ fort --mode=print - < cert.cer

Progress for #122.

Fix compilation in OpenSSL < 3 and LibreSSL

Purge early output files writability validations

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.

Adjacent progress for #124.

Remove file mode hardcode from file_write

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.

Add --file-type

Allows the user to bypass the file type guesser. For example, to force
the ROA parser:

$ fort --mode=print --file-type roa abcd.bin

Progress for #122.

Improve the file type detector for --mode=print

Guesses the file type from the ASN1 shape.

Progress for #122.

Add CRLs and their extensions to --mode=print

Progress for #122.

Add certificate extensions to --mode=print

Hmm. I think this bumps the minimum required LibreSSL to v3.5.0.

Progress for #122.

Add certificates to --mode=print

This includes .cer files, as well as "certificates" signed object
fields.

Known caveat: The .SignedData.certificates[*].tbsCertificate.extensions
are pretty ugly still.

Progress for #122.

Add --mode=print

Prints an RPKI file in standard output. Only the asn1c signed objects
(ROAs, Manifests and Ghostbusters) are implemented right now.

In particular, it doesn't jsonify certificates nor CRLs yet, which
includes the "certificate" field of the signed objects.

Progress for #122.

ASN.1: Remove random_fills

Unused code. Don't know what it's for.

ASN.1: Remove C++ glue

I might regret this one day.

ASN.1: Remove the XER decoder

Unused code. Been wanting to do this for years.

ASN.1: Remove the OER and PER encoders and decoders

Unused code. Been wanting to do this for years.

agregada rtrlib en la imagen de docker

Fix date parsing from TAL cachefiles

The code was writing dates in Zulu format, which was fine. But then, to
read them back, it was loading them with mktime(), which is a local
timezone function. The effects of this bug depend on the time zone.
Files would expire from the cache up to 12 hours too early (UTC+) or
late (UTC-), or be updated up to 12 hours late (UTC-). (There's no such
thing as "updating too early" in this context, since Fort cannot refresh
before the present.)

I fixed this by swapping mktime() for timegm(), which is not great,
because the latter is still a nonstandard function. But it'll have to
do, because the other options are worse.

Below is my thought process on timegm() and the other options:

==================================================

Problem:

1. I want to store timestamps as human-readable strings.
2. Converting a timestamp to Zulu string is trivial: time_t ->
   gmtime_r() -> struct tm (GMT) -> strftime() -> char*.
3. But converting a string to timestamp relies on timegm(), which is
   nonstandard: char* -> strptime() -> struct tm (GMT) -> timegm() ->
   time_t.

Brainstorm:

1. Store the dates in local time.

Hideous option, but not ENTIRELY insane.

Storing in local time will render the dates up to 24 hours off, I think.
But this only happens when the cache changes timezone, which isn't
really often.

But it's still pretty clumsy, and also not future-proof, as new date
fields would have to be constrained by the same limitation.

2/10 at best.

2. Ditch time_t, use struct tm in UTC for everything.

So I would rely on gmtime_r() only to get out of time_t, and never need
timegm() for anything.

Comparing field by field would be a pain, but it's interesting to note
that Fort is actually already doing it somewhere: tm_cmp(). I guess I
have to admire the audaciousness of past me.

What mainly scares me is that mktime() seems to be the only standard
function that is contractually obligated to normalize the tm, which
means I would have to keep mktime()ing every time I need to compare
them.

And mktime() is... a local time function. Probably wouldn't actually
work.

4/10. I hate this API.

3. Bite the bullet: Go modern POSIX; assume time_t is integer seconds
   since the 1970 epoch.

I'm fantasizing about an early environment assertion that checks the
gmtime_r() for a known time_t, that shows people the door if the
implementation isn't sane. Would work even in POSIX-adjacent systems
like most Linuxes.

This would have other benefits, like the ability to ditch difftime(),
and perform arithmetic operations on time_t's.

All the officially supported platforms get this aspect of POSIX right,
so what's stopping me?

Well, it would mean I would have to store the date as a seconds-since-
epoch integer, which is not as human-friendly and defeats the whole
point of the JSON format.

And yet... this feels so right, I might end up doing it even regardless
of the JSON data type and timegm().

But not today. 7/10.

4. Bite the bullet: Use timegm().

Interesting. timegm() might be added to C23:

> Changes integrated into the latest working draft of C23 are listed
> below.
> (...)
> - Add timegm() function in <time.h> to convert time structure into
> calendar time value - similar to function in glibc and musl libraries.

https://en.wikipedia.org/wiki/C23_(C_standard_revision)

So this has some probability of not needing future tweaking. Also, it's
very clean. (Except for the feature test macros.)

8/10.

Fix bad usage of strtol()

Someone didn't RTFM.

1. Error code wasn't being catched.
2. Second argument was NULL, so the caller had no way of knowing
   whether the string was fully consumed.
2. The code wasn't making sure the input was a clean hex string.
3. The input string wasn't NULL-terminated.

In the end, I ditched strtol(). It's too dangerous and cluttered for
this purpose.

Merge branch 'job-main'

Update comment

At this point in time I'm not aware of specific differences between
LibreSSL and OpenSSL in relationship to RFC 6487.

Update comment

Warn if server.address has more than one wildcard

Consider the following three definitions of server.address:

[a] "address": [ "0.0.0.0" ]
[b] "address": [ "::" ]
[c] "address": [ "0.0.0.0", "::" ]

We expect [a] to bind the socket to any IPv4 address,
[b] to bind the socket to any IPv6 address,
and [c] to bind the socket to any IPv4 and IPv6 address.

Right? The BSDs work that way.

But Linux doesn't. For Linux,

[a] binds to any IPv4 address,
[b] binds to any IPv4 and IPv6 address,
and [c] is an error.

But I don't want to override the behavior because some admins are
probably used to it:

linux$ nc -6lknv :: 7890
Listening on :: 7890
Connection received on ::1 52814
Hello from IPv6!
Connection received on ::ffff:127.0.0.1 55456
Hello from IPv4!

Instead, let's print a warning.

Thanks to Benjamim Pinheiro for reporting this quirk.

RTR server bind review

- Hint SOCK_STREAM on getaddrinfo(), not on socket().
  I guess this means it was attempting some redundant binds on failure?
- Print the "Attempting to bind socket to address '%s', port '%s'"
  message in every addrinfo, not just the first one. (Improves log
  legibility.)
- Improve the algorithm that produces the printable version of the
  address (used to dereference ai_addr->sa_data like the previous
  commit), and fall back to whatever the user provided if it fails.
- Weird inconsistency: Most errors used to cause create_server_socket()
  to try the next addrinfo candidate, but getsockname() and listen()
  induced immediate abortion. I've no idea what that was about;
  getsockname() isn't even a mandatory step.
- Attempt to bind all addrinfo candidates; they must all succeed.
  (It used to stop on the first success.)

I'm conflicted with the last point. The old behavior appears to have
been inherited from the Linux manual page example, but doesn't make any
sense from where I'm standing.

If `/etc/hosts` defines

127.0.0.1    localhost
::1          localhost

And server.address is "localhost", shouldn't we attempt to bind to both
addresses?

Remove > 65535 validation from --server.port

While trying to implement the upcoming patch, I found myself trying to
refactor this validation. The implementation was awkward; instead of
ntohs'ing sockaddr_in.sin_port, it extracted the bytes manually:

port = (unsigned char)((*result)->ai_addr->sa_data[0]) << 8;
port += (unsigned char)((*result)->ai_addr->sa_data[1]);

But on second thought, I'm not seeing this validation eye to eye.
It's intended to prevent `getaddrinfo()` from parsing
`--server.port=120000` like `--server.port=54464` (120000 % 65536) on
Linux, but... thing is, this "port out of bounds" quirk looks like an
everyday Linux idiosyncrasy.

Linux being Linux:

$ nc -lv 127.0.0.1 120000
Listening on localhost 54464

It's weird but seems inoffensive, and some beardos might even expect it.

`getaddrinfo()` returns proper errors in the BSDs, so the validation is
redundant there.

s/fort-validator@nic.mx/validadorfort@fortproject.net/g

Curious. It looks like we've had both aliases since forever, and they
have the same purpose.

They both work, but I don't have any control over the former anymore.
So let's phase it out.

Make sure d2i_X509() consumed all data

An artefact of d2i_*() functions is that once they're satisfied,
there still might be trailing garbage in the field that's being
decoded.

Callers of d2i_*() functions generally should conform that all
data has been consumed.

Treat X509_ALGOR as opaque structure

Unfortunately, X509_ALGOR is still a public struct, and it only has the
slightly awkward accessor X509_ALGOR_get0(), already used elsewhere in
FORT. This converts two codepaths that reach into the struct to using
X509_ALGOR_get0() so that X509_ALGOR can be made opaque in the future.

Fix header version for Code 4 Error PDUs

Fixes #106.

Update Docker

Protocolary updates for release 1.6.1

Create tmp/ before CACHEDIR.TAG

tmp/'s creation is (C's equivalent of) a `mkdir -p`. It ensures the
cache directory exists by the time Fort attempts to create CACHEDIR.TAG.

Improve HTTP info logging

Before:

  Downloading 'https://test.rpki/notification.xml'.
  HTTP GET: https://test.rpki/notification.xml -> cache/tmp/1

The first line was redundant, and the target wasn't very helpful.

Now:

  HTTP GET: https://test.rpki/notification.xml -> cache/test.tal/https/test.rpki/notification.xml

Merge branch 'job-main'

Disable normal error messages during tests

These error messages weren't showing up because of failing assertions;
it was because the tests were checking error pipelines.

Hide them by default. They can be restored in a pinch by compiling with
-DPRINT_PRS ("-D print prints"):

CFLAGS=-DPRINT_PRS make check

Pending work from #101.

Create CACHEDIR.TAG during cache initialization

To hint backup software not to copy the cache.
https://bford.info/cachedir/

Fixes #104.

Empty cache whenever Fort's version changes

Because people might have missed the release notes, and also because I
expect to keep improving the cache code, possibly in ways that are not
backwards compatible.

Case in point: I already had to tweak the TAL metadata file in the
previous commit.

I will probably downgrade this to something less aggressive later.

Stop trying to cage non-notification URLs during cleanup

Fixes the new issue reported in #103.

Stop printing logging severity in syslog

Second half of #103.

Remove the log switching cacophony on startup

Resolves the first complaint of #103:

> I believe that if syslog output is enabled on the command line then
> fort should be able to not report these useless messages about
> switching the output back and forward.
>
> Also, there is no point in reporting in syslog that messages are
> being sent to syslog and on the console that messages are being sent
> to the console because this is self-evident.

Looking back at the history, it seems these messages were born because
a long time ago, sys-logging was hardcoded to "server" mode, while
console "logging" was tied to "standalone" mode. Default was "server,"
which meant a newcomer who managed to kickstart Fort in the foreground
with minimal arguments ended up with a validator that, on account of
looking silent, seemed to be doing absolutely nothing.

Given than logmode and runmode are completely independent now, and log
output defaults to "console," it would appear that these messages are,
as a matter of fact, completely useless.

Stop dropping old deltas when there are no new deltas

__vrps_update() wasn't properly differentiating between a validation
cycle that errored from one that generated no deltas. Both were being
handled as failure.

Therefore, Fort might have been inducing more RTR Cache Resets than it
was supposed to. Although, iterations in which no deltas are generated
seem to be rare.

The removal of surplus error propagation in the previous commit
revealed that compute_deltas() cannot actually fail, which made
the solution here trivial.

Fix compilation on Mac OS

Not really trying to add formal support for Mac OS at the moment;
this is just to be able to debug a little more efficiently in this
laptop I'm stuck with right now.

Take advantage of autotools in BSD environments

Taken from https://github.com/bgp/bgpq4/blob/main/bootstrap

Fix default rsync arguments in the documentation

Looks like these got messed up during the merge.

Remove usage of newer check API

The distant virtual machine I used to replicate #101 had what I assume
is an older version of check, so I had to tweak some validations.

Looks like I have to expand my VM repertoire.

Improve portability of timestamps in JSON

It looks like %F, %T and %z are not portable conversion specification
characters for strptime() and strftime(). Therefore, change date format
from "%FT%T%z" to "%Y-%m-%dT%H:%M:%SZ".

This means the JSON now employs Zulu, which also fixes a unit test that
used to be hardcoded to my own timezone. Yaay.

Fixes #101.

Update Docker

Alpine no longer supports libexecinfo...

Protocolary updates for release 1.6.0

Allow some nulls in the configuration JSON

While playing with the configuration sample, I found out that setting
a `null` slurm property in the JSON was rejected, even though the SLURM
file itself is not mandatory.

So rethink this, and for a few other fields as well.

Fix unit tests in the BSDs

...Except for the __VA_ARGS__ warning. That can wait.