Type "s" for security audit, or "h" for health audit.
We don't add it to the option prompt to not clutter the menu flow.
This is mostly for debug and development purposes.
I see no easy way to untangle this for now. At least make sure
the user is asked for the defaults to be restored making this
a little better than before.
When there are a lot of interfaces, these calls consume quite some time and eventually the output of legacy_interfaces_details() is what matters to all of them.
Some back and forth between explicit and implicit requires while here.
The code is helplessly glued together and no plugin facility to get
data from a function call currently exists.
product_flavour is embedded in the release package but the
package itself does not insist on a particular flavour other
than having knowledge about the flavour the package was
built for originally. This is ok and direct crypto deps
seem to have failed to produce reliable upgrade / sidegrade
results in recent tests anyway.
Long story short: find out the real crypto flavour installed
from the OpenSSL binary or fall back to the metadata if said
binary cannot be found.
Now that we have metadata injection at build time read it instead
of its auxiliary files. Allow live-mount to snoop the metadata and
afterwards we can start to marry the version and firmware-product
file.
Last puzzle piece will be a tool called "opnsense-version" to read
the JSON metadata and return it in a piecemeal fashion of a part
of the system requires that info, especially from the shell.
This is only an improvement and unification of
`src/opnsense/scripts/shell/banner.php`.
Using `openssh_enabled()` both times in this file is preferred over one
time using `isset($config['system']['ssh']['enabled'])` and the other
time using `openssh_enabled()`.
Updates: 00f9b21cb78d9f76a8f94e8e62cbcefad65b7d99
Updates: 81e50abd0afba2d58ce487cdad60c7aedf899bbf
Updates: https://github.com/opnsense/core/pull/2481
Example output:
```
$ /usr/local/etc/rc.initial.banner
*** test-fw.localdomain: OPNsense 18.1.10 (amd64/OpenSSL) ***
WAN (vtnet0) -> v4/DHCP4: 172.30.23.2/24
SSH: 256 SHA256:fcMIAgT/vZR/TWP0j8AFROTNnudkU1tP9sRhbsIa8vM (ECDSA)
SSH: 256 SHA256:lDenOc5wy2WU0e6sSz2hR9nEFnMqx5c3u1F/pHxgJlY (ED25519)
SSH: 2048 SHA256:dsw9srlQHL0hPJlEdR9rL769N30BTZgXG9gXbdZGOkU (RSA)
HTTPS X.509 cert: SHA256 Fingerprint=F0:E6:EB:31:E8:87:AF:52:16:4E:84:05:3B:6C:03:2C:C1:DF:5A:E7:36:F4:32:44:3B:B5:57:63:97:45:C3:77
```
The list of fingerprints is appended after the interface list because
the interface list might be pretty long and thus would move the
fingerprints out of the screen which we don’t want.
Previously (#2427) I suggested to extract the X.509 certificate from the
xml config but the difficult part for me who is not so familiar with the
implementation of OPNsense is to find the certificate which is actually
used by the local web server. I found that `/var/etc/cert.pem` is used
in the configuration of the local web server and assume that this is the
easier way to implement this in the expectation that the file name does
not change without being also changed in this script and that the file
exists. If it does not exist, OpenSSL would complain with a useful error
message.
This commit is one piece to make fully trusted bootstrapping easier.
Related to: https://github.com/opnsense/core/issues/2427
Tested on: OPNsense 18.1.10-amd64
