Skip to content

Releases: skx/overseer

release-1.13

22 May 08:10
@skx skx
0955bdd
Compare
Choose a tag to compare

release-1.13

This release updates the SSL-expiration test, to provide clarity when an SSL certificate is close to expiry the CommonName of the certificate will be reported. This allows a user to see if it is actually their certificate which is close to expiration, or any intermediary certificate. This was reported in #49, and closed in #50.

Some dockerfiles were also added to the repository, but these are primarily for the author's benefit at the moment.

release-1.12

04 Feb 18:36
@skx skx
Compare
Choose a tag to compare

release-1.12

This release updates the processing of tests in the event of a DNS-failure.

Since we're multi-protocol (supporting both IPv4 and IPv6) whenever we encounter a test we must result the names involved, to discover the target host(s) which should be probed. It is possible a user might say "Ignore IPv4", or "Ignore IPv6", so we need this step before we actually carry out the test.

For example given the following input we must lookup the IP addresses of mail.example.com (both A and AAAA records) to know what target(s) we must run our test against:

mail.example.com must run imaps on 587 with username 'bob' with password 'hello.world'

Once we have identified the IP address(es) to probe we then run the test:

  • If the test-passes, because an IMAP login with TLS succeeds, we write the result to redis.
    • We censor the password from this result before inserting the result.
  • If the test-fails, because the login fails, the system is unreachable, or SSL validation fails, etc, we write a failure-result to redis
    • We censor the password from this result before inserting the result.

There was one case not considered; if the initial DNS lookup fails we would record that in redis without censoring the password. That's a rare case, in practice, but it would have caused a minor leak of credentials. We've never explicitly defined a threat-model, or promised security in this case, so I think it's tolerable, but still not ideal.

This release fixes the issue anyway, which was logged as #47

release-1.11

27 Nov 09:41
@skx skx
Compare
Choose a tag to compare

release-1.11

This release updates our code by "stealing" inspiration from one of our more advanced forces, as per #46

  • We now setup an explicit (5second) timeout for our redis connections.
  • We now allow multiple HTTP-status-codes to be regarded as a pass.
    • For example "https://steve.fi/ must run http with status 200,301,302".
    • I don't have a particular use-case for this, but it seems like a good improvement regardless.

release-1.10

07 Nov 18:40
@skx skx
6128410
Compare
Choose a tag to compare

release-1.10

This release allows the number of members in a given redis set, or list, to be tested and an alert triggered if that number is above a particular threshold. This was implemented in #44

We also updated our release process as part of #42 to improve our CI tests, which should ensure regressions are easily found.

release-1.9

14 Aug 06:05
@skx skx
Compare
Choose a tag to compare

This release contains two changes from @cmaster11 :

  • Allow running tests from STDIN
  • Allow a test to have a custome number of retries.

Otherwise I've updated the github actions to the new syntax, although due to github oddities this did not complete successfully.

release-1.8

24 Feb 15:27
@skx skx
Compare
Choose a tag to compare

This release is being made solely to transition the testing and release process from TravisCI to github actions:

release-1.7

22 Feb 18:41
@skx skx
Compare
Choose a tag to compare

This release was made solely to publish (trusted) binary releases for the ARM platform, something I find myself using more nowadays.

There are only minor changes compared to the previous one:

  • #37 - Contributed by @pbeckmann
  • Minor comment updates in various files.

release-1.6

27 Jul 09:02
@skx skx
Compare
Choose a tag to compare

This release makes a couple of minor internal cleanups to fix go lint and go vet warnings.

The only new feature is the ability to apply a tag to all result-objects, which are stored in our redis-queue. Simply add -tag=$(hostname) to your worker invokation and you can determine whether a failure is local or global by comparing against other hosts. (Assuming you have N-workers all on different hosts.)

release-1.5

26 Jun 08:53
@skx skx
Compare
Choose a tag to compare

This release improves the handling of the IMAP & IMAPS probes, to ensure that once a login-test has been made a logout operation also occurs. This was a grievous omission which caused false-failures when probing remote dovecot servers.

Assuming a test every minute then after ten minutes the probe would start failing with this error message:

  • Maximum number of connections from user+IP exceeded (mail_max_userip_connections=10)

Adding the logout operation, and ensuring that the connection is closed properly removes this false-positive.

release-1.4

26 Jun 07:56
@skx skx
Compare
Choose a tag to compare

This release updates the SMTP-probe, such that it now supports optional username & password arguments, for example:

 mail.example.com must run smtp with port 587 \
     with username '[email protected]' \
     with password 's3cr3t'

If a username and password are specified then a login attempt will be made to the remote SMTP-server.

NOTE: To avoid submitting login-credentials in plaintext the login attempt mandates the use of STARTTLS. If your TLS setup is self-signed, or otherwise mismatches the hostname used then errors can be ignored via with tls insecure:

 mail.example.com must run smtp with port 587 \
     with username '[email protected]' \
     with password 's3cr3t' \
     with tls insecure