Add --http.proxy

Attempt to fix #160.

Protocolary updates for release 1.6.6

Increase http.max-file-size's default

We got a 530 mB snapshot nowadays. Since these tend to double during
key rollover, the old default of 1 gB no longer makes sense.

RRDP: Mirror rsync extension filters

We've agreed extension filters are useful, and the manifest code no
longer drops RPPs due to unknown file-not-founds.

So prevent unknown file extensions from contaminating the RRDP side of
the cache as well.

Complements #155.

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:

> rsync (...) --include=*.cer --include=*.crl --include=*.gbr \
> --include=*.mft --include=*.roa --exclude=* (...)

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.

Fixes #155.

Name CVE-2024-56375

Add new CVE sketch

Protocolary updates for release 1.6.5

Check manifest fileList emptiness before shuffling

Prevents the loop iterating indefinitely trying to shuffle an array
that's not actually there.

Fixes #154 and new CVE.

Name CVE-2024-56169 and CVE-2024-56170

Add new CVE sketches

Name CVE-2024-48943

Enclose each test sandbox in a dedicated directory

Prevents them from interfering with each other.

Fixes #148.

Update Docker

Add 1.6.4 CVE

Protocolary updates for release 1.6.4

Misc log review

- Print dependency versions during startup
- Print date ranges for certificates and CRLs

Fix default values in the documentation

The retry counts and intervals were wrong.

Merge branch 'job-rsync_timeout_poll'

Add more unit tests to the rsync timeout

Aight, think I'm done testing this.

Exhaust rsync's stderr and stdout at the same time

I'm assuming this consumes less RAM, as stdout no longer has to buffer
completely until stderr is done.

Refactor exhaust_read_fd()'s return value

Allows the unit test to tell the difference between timeout and error.

Separate POLLERR and POLLNVAL for rsync poll

POLLERR must induce close(), POLLNVAL must not.

Rename the exhaust stream functions, simplify arg list

Update timeout during every rsync poll

Ensures the timeout is absolute even when poll() returns repeatedly.

Introduce a rsync transfer timeout

Default set to 900 (same as rpki-client)

Fixes https://github.com/NICMx/FORT-validator/issues/74

Fill up CVE numbers in documentation

Merge branch 'job-pr146'

Merge branch 'job-pr144'

Improve Key Usage validation more

- Was not checking the decipherOnly bit
- Was not using the buffer meant to ease checking the decipherOnly bit

Again, thanks to Niklas Vogel and Haya Schulmann for reporting this.

Set default HTTP transfer timeout to 900

Credit Haya Schulmann for her contributions to the CVEs

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.