depcomp
install-sh
missing
+src/configure_ac.h
+src/stamp-h1
# Packaging
*.7z
# Checks for programs.
AC_PROG_CC
+# Create src/configure_ac.h, put some useful macros there.
+AC_CONFIG_HEADERS([src/configure_ac.h])
+
# Checks for header files.
AC_CHECK_HEADERS([netinet/in.h stdlib.h string.h unistd.h])
</header>
<section class="site-section">
- <div class="container alerta">
- <blockquote><strong>
- <img src="../img/warn.svg" alt="WARNING"/> Warning: This documentation is still under construction. It's too
- succint for comfort still.
- </strong></blockquote>
- </div>
<div class="container">
{{ content }}
</header>
<section class="site-section">
- <div class="container alerta">
- <blockquote><strong>
- <img src="./img/warn.svg" alt="WARNING"/> Warning: This documentation is still under construction. It's too
- succint for comfort still.
- </strong></blockquote>
- </div>
<div class="container">
{{ content }}
## Introduction
-The RPKI RFCs define fairly strict profiles for RPKI objects, and are unequivocal in stating that incorrectly-formed objects are supposed to be rejected by Relying Party validation. In practice, however, this does not stop a significant amount of Certificate Authorities from issuing incorrect objects.
+The RPKI RFCs define fairly strict profiles for RPKI objects, and are unequivocal in stating that incorrectly-formed objects are supposed to be rejected by Relying Party validation. In practice, however, this does not prevent a significant amount of Certificate Authorities from issuing incorrect objects.
By default, Fort is as pedantic as it can possibly be. The `incidence` section of its configuration file is a means to modify its behavior upon encountering profile violations that, from experience, are often overlooked.
sudo apt install ./libcmscodec1_0.0.1-1_amd64.deb ./fort_0.0.1-1_amd64.deb
{% endhighlight %}
-Aside from the `fort` binary documented elsewhere in this documentation, the Debian package also ships with a systemd service, which you can [configure](usage.html#--configuration-file) at `/etc/fort/config.json`.
+Aside from the `fort` binary documented elsewhere in this documentation, the Debian package also ships with a systemd service, which is just the binary ran as a daemon. You can [configure](usage.html#--configuration-file) it at `/etc/fort/config.json`.
{% highlight bash %}
sudo service fort start
## TO-DO
-- Reach full 100% RFC compliance.
-- Maybe a few optimizations, marked as `TODO` in the code.
+- Reach 100% RFC compliance
+- Multithreading
+- Daemon quirks (stuff like "send self to background automatically"), maybe
+- More languages?
{% highlight bash %}
$ {{ page.command }} --version
-0.0.1-beta
+fort 0.0.1
{% endhighlight %}
### `--tal`
The reason why you provide locators instead of anchors is to allow the latter to be officially updated without the need to awkwardly redistribute them.
-Whichever registry serves as root of the tree you want to validate is responsible for providing you with its TAL. For convenience, Fort currently ships with the TALs of four of the five RIRs. (The exception is ARIN's, since you need to read and accept an [agreement](https://www.arin.net/resources/manage/rpki/tal/) before you can use it.) If you are paranoid, however, you'd be advised to get your own.
+Whichever registry serves as root of the tree you want to validate is responsible for providing you with its TAL. For convenience, Fort currently ships with the TALs of four of the five RIRs. (The exception is ARIN's, since you need to read and accept an [agreement](https://www.arin.net/resources/manage/rpki/tal/) before you can use it.) If you installed the Debian package, they can be found at `/etc/fort/tal/`, otherwise it the `tal/` directory of whatever release tarball you downloaded.
+
+If you are paranoid, however, you'd be advised to get your own TALs.
The TAL file format has been standardized in [RFC 7730](https://tools.ietf.org/html/rfc7730). It is a text file that contains a list of URLs (which serve as alternate access methods for the TA), followed by a blank line, followed by the Base64-encoded public key of the TA.
Path to the directory where Fort will store a local cache of the repository.
-Right now, Fort accesses RPKI repositories by way of [rsync](https://en.wikipedia.org/wiki/Rsync). (The alternate protocol [RRDP](https://tools.ietf.org/html/rfc8182) is in the road map.) During each validation cycle, Fort will literally invoke an `rsync` command (see [`rsync.program`](#rsyncprogram) and [`rsync.arguments-recursive`](#rsyncarguments-recursive)), which will download the files into `--local-repository`. Fort's validation operates on the resulting copy.
+Right now, Fort accesses RPKI repositories by way of [rsync](https://en.wikipedia.org/wiki/Rsync). (The alternate protocol [RRDP](https://tools.ietf.org/html/rfc8182) is in the road map.) During each validation cycle, Fort will literally invoke an `rsync` command (see [`rsync.program`](#rsyncprogram) and [`rsync.arguments-recursive`](#rsyncarguments-recursive)), which will download the files into `--local-repository`. Fort's entire validation process operates on the resulting copy.
Because rsync uses delta encoding, you're advised to keep this cache around. It significantly speeds up subsequent validation cycles.
Disable the RTR server.
-If the flag is set, the server is disabled, the rest of the `server.*` arguments are discarded, and Fort performs an in-place standalone RPKI validation.
+If the flag is set, the server is disabled, the rest of the `server.*` arguments are ignored, and Fort performs an in-place standalone RPKI validation.
### `--server.address`
TCP port or service the server will be bound to.
-This is a string because a service alias can be used as a valid value. The alias are commonly located at `/etc/services`. (See '`$ man services`'.)
+This is a string because a service alias can be used as a valid value. The available aliases are commonly located at `/etc/services`. (See '`$ man services`'.)
>  The default port is privileged. To improve security, either change or jail it.
- **Default:** [`SOMAXCONN`](http://pubs.opengroup.org/onlinepubs/9699919799.2008edition/basedefs/sys_socket.h.html)
- **Range:** 1--`SOMAXCONN`
-RTR server's listen queue length. It's the second argument of [`listen()`](http://pubs.opengroup.org/onlinepubs/9699919799.2008edition/functions/listen.html):
+RTR server's listen queue length. It is the second argument of [`listen()`](http://pubs.opengroup.org/onlinepubs/9699919799.2008edition/functions/listen.html):
> The backlog argument provides a hint to the implementation which the implementation shall use to limit the number of outstanding connections in the socket's listen queue. Implementations may impose a limit on backlog and silently reduce the specified value. Normally, a larger backlog argument value shall result in a larger or equal length of the listen queue. Implementations shall support values of backlog up to SOMAXCONN, defined in <sys/socket.h>.
## Status
-The first release of Fort is planned to be released later this month.
+Fort is currently in beta. Testing is underway.
#include <sys/socket.h>
#include "common.h"
+#include "configure_ac.h"
#include "json_handler.h"
#include "log.h"
#include "config/boolean.h"
static int
handle_version(struct option_field const *field, char *arg)
{
- printf("0.0.1-beta\n");
+ printf(PACKAGE_STRING "\n");
exit(0);
}
int
config_get_server_queue(void)
{
- /*
- * The range of this is 1-<small number>, so adding signedness is safe.
- */
+ /* The range of this is 1-<small number>, so adding sign is safe. */
return rpki_config.server.backlog;
}
vrp.max_prefix_length);
}
- pr_crit("Unkown addr family type: %u", vrp.addr_fam);
+ pr_crit("Unknown addr family type: %u", vrp.addr_fam);
}
static int
projects / thirdparty / FORT-validator.git / commitdiff
