Statically typed error handling PoC

[Tehforsch]

This is a proposal for revamped error type structure and handling for NASL builtin functions as well as some minor changes to error handling in general.

Error type structure

The main type this refactoring is concerned with is FunctionErrorKind which has been renamed to FnError.

In this proposed new error structure, FnError is an actual type that contains metadata about the error (such as whether the error can be solved by retrying the operation that caused it and the return value given to the NASL caller), as well as its kind, described by the FnErrorKind enum. This enum corresponds to the previous FunctionErrorKind and is structured as follows:

pub enum FnErrorKind {
    Argument(ArgumentError),
    Internal(InternalError),
    Builtin(BuiltinError),
}

The variants represent three different kinds of errors: ArgumentError refers to errors caused by calling a function with the wrong arguments which typically reflect an error in the usage of the function by the script authors.

InternalError refers to any error caused by failure of an internal process of the scanner (such as the storage). This reflects a deeper problem and may mean we cannot simply proceed with execution of the scan.

Finally, BuiltinError represents any (more or less expected) error that occurred within a builtin function. This may include timeouts, authentication failures, etc..

Error handling

I think the exact rules for how we treat each error type are something that is still open to discussion, but I'll write down the rules for the implementation in this PR as a basis for this discussion.

As stated above, the metadata (return value, retryable) on how to handle a specific error are stored in a FnError (as opposed to deriving them by matching on the kind of the error). This means that in principle, we always have the option of explicitly overriding any defaults for any specific case. However, I hope that we rarely need this in practice because we can choose sane defaults that reflect what we want most of the time.

Return behavior

The return behavior of a given error specifies how an error should be handled during execution. This is specified by the following type:

enum ReturnBehavior {
    ExitScript,
    ReturnValue(NaslValue),
}

This type is equivalent to Option<NaslValue> but we decided that having a custom type here would make the intent clearer.
When the interpreter encounters an error with ReturnBehavior::ExitScript behavior, it will unsurprisingly exit the script. If it encounters an error with ReturnBehavior::ReturnValue(val), it will return val and continue execution. This behavior is effectively equivalent to the Diagnostic variant of FunctionErrorKind.

The Argument and Internal variants of FnError are automatically constructed with ReturnBehavior::ExitScript, meaning that they abort execution of the script. The Builtin variant is constructed with ReturnBehavior::ReturnValue(NaslValue::Null) by default, but this value can easily be overwritten when the error is created, for example:

HttpError::HandleIdNotFound(handle).with(ReturnValue(-1))

Retry behavior

Certain errors can be flagged as being solvable by retrying the operation that caused them. This is represented by a retryable boolean on FnError, which is false by default for all variants except for a specific internal error in the storage. However, this default behavior can be overwritten at error creation if needed, for example

HttpError::ConnectionFailed(...).with(Retryable)

I also added a small test to make sure that the interpreter does actually retry retryable errors.

Boilerplate / Cost

Since this was the main point of the discussion on implementation strategies for these errors, I figured I'd write down the amount of additional overhead for creating these custom error types that is currently needed when a new builtin module is created.

1. Add a custom error type for the builtin module. These can be of arbitrary form but a typical error type might look like

#[derive(Debug, Error)]
enum FooError {
    #[error("Bar occurred.")]
    Bar,
    #[error("Baz occurred. Here is some more data: {0}")]
    Baz(SomeData),
}

I personally like this approach anyways since it keeps error messages all in one place and makes it easy to get an overview of all the error messages and to keep them consistent.

2. Add this builtin error as a variant of the BuiltinError type described above. This is one line of code:

enum BuiltinError {
    ...
    Foo(FooError),
    ...
}

3. For convenience, some From impls and TryFrom impls can make the error type easier to use by enabling use of the question mark operator. I added a tiny macro that implements these traits (because the implementations are usually trivial), so this comes down to one line too:
   builtin_error_variant!(Foo, FooError);

This is all that is needed to make this error usable in NASL functions:

fn check(a: usize) -> Result<(), FooError> {
    if a == 0 {
        Err(FooError::Bar)
    }
    else { 
        Ok(())
    }
}

#[nasl_function]
fn foo(a: usize) -> Result<usize, FnError> {
    check(a)?;
    Ok(a)
}

As a side note, NASL functions can also return any concrete impl Into<FnError> directly, so for this case we can also write

#[nasl_function]
fn foo(a: usize) -> Result<usize, FooError> {
    if a == 0 { 
        Err(FooError::Bar)
    }
    else {
        Ok(a)
    }
}

Note that the above From impls that are automatically written by the builtin_error_variant! macro can also be manually implemented if one wants to specify defaults for a specific error variant. For example

impl From<FooError> for FnError {
    fn from(e: FooError) -> FnError {
        match e {
            FooError::Foo => BuiltinError::Foo(e).with(ReturnValue(-1)),
            _ => BuiltinError::Foo(e).into(),
        }
    }
}

PartialEq, Eq and Clone

Previously, all our error types derived PartialEq, Eq, Clone. This was basically unused in the codebase (with some minor exceptions where an easy rewrite made these derives unnecessary). In this PR I got rid of all of these derives. This has the advantage of making it easier to wrap certain internal library errors that may not implement any of the three traits (std::io::Error implements neither and is used quite a bit, for example, causing us to always use the io::ErrorKind instead.). I think there is a case to be made for either choice, but personally prefer not implementing these.
Note that this will also be a problem in a dyn FnError-based solution, since the type will have to become dyn FnError + PartialEq + Eq + Clone or alternatively FnError will have to be defined as trait FnError: PartialEq + Eq + Clone, either requiring each concrete type to implement the three traits.

WithErrorInfo

As a last, opinionated part of this PR, I added a trait WithErrorInfo that is basically meant to attach some kind of information to an already existing error. This originated in the SSH implementation, where I wanted to add the SessionId that caused the error to ~70% of error variants (but not all of them, which would have meant I could simply make it part of the parent error). I also often wanted to add the internal library error that caused the error to occur. This trait made it convenient to simply write SshError::Foo.with(session_id).with(err). I then stumbled upon this concept again when I wanted to attach the retryable/return behavior information discussed above to certain errors, so I simply extended this trait to allow usage like .with(ReturnValue(-1)) or .with(Retryable) where ReturnValue and Retryable are simply dummy types meant for just this one purpose. This has the nice advantage of allowing autoconversion to FnError making the resulting code look really clean, but if this is too fancy I'm fine with getting rid of it. An alternative would be to implement methods like with_return_value and .with_retryable for every type that needs them or to instead write FnError::from(...).with_retryable() which is more verbose.

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Snapshot Warnings

⚠️: No snapshots were found for the head SHA adbf987.

Ensure that dependencies are being submitted on PR branches and consider enabling retry-on-snapshot-warnings. See the documentation for more information and troubleshooting advice.

OpenSSF Scorecard

Package	Version	Score	Details

Scanned Files

[github-actions]

🔍 Vulnerabilities of harbor-os.greenbone.net/community/openvas-scanner:1752-merge-amd64

📦 Image Reference harbor-os.greenbone.net/community/openvas-scanner:1752-merge-amd64

digest	sha256:d9fde17656621fad018521985ea96803132b591f49b40d120209ccc29a3cf256
vulnerabilities
size	144 MB
packages	262

📦 Base Image debian:stable-20241016-slim

also known as	stable-slim
digest	sha256:d337e8c1770de491cd165b65051f49455ff20fdd26b296d24650876aefaa445f
vulnerabilities

pam 1.5.2-6+deb12u1 (deb) pkg:deb/debian/[email protected]%2Bdeb12u1?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=1.5.2-6+deb12u1 Fixed version Not Fixed EPSS Score 0.09% EPSS Percentile 40th percentile Description A vulnerability was found in pam_access due to the improper handling of tokens in access.conf, interpreted as hostnames. This flaw allows attackers to bypass access restrictions by spoofing hostnames, undermining configurations designed to limit access to specific TTYs or services. The flaw poses a risk in environments relying on these configurations for local access control.

pcre3 2:8.39-15 (deb) pkg:deb/debian/pcre3@2:8.39-15?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=2:8.39-15 Fixed version Not Fixed EPSS Score 1.03% EPSS Percentile 84th percentile Description libpcre in PCRE before 8.43 allows a subject buffer over-read in JIT when UTF is disabled, and \X or \R has more than one fixed quantifier, a related issue to CVE-2019-20454. Affected range >=2:8.39-15 Fixed version Not Fixed EPSS Score 0.65% EPSS Percentile 80th percentile Description Stack-based buffer overflow in the pcre32_copy_substring function in pcre_get.c in libpcre1 in PCRE 8.40 allows remote attackers to cause a denial of service (WRITE of size 268) or possibly have unspecified other impact via a crafted file. Affected range >=2:8.39-15 Fixed version Not Fixed EPSS Score 0.65% EPSS Percentile 80th percentile Description Stack-based buffer overflow in the pcre32_copy_substring function in pcre_get.c in libpcre1 in PCRE 8.40 allows remote attackers to cause a denial of service (WRITE of size 4) or possibly have unspecified other impact via a crafted file. Affected range >=2:8.39-15 Fixed version Not Fixed EPSS Score 0.08% EPSS Percentile 37th percentile Description In PCRE 8.41, after compiling, a pcretest load test PoC produces a crash overflow in the function match() in pcre_exec.c because of a self-recursive call. NOTE: third parties dispute the relevance of this report, noting that there are options that can be used to limit the amount of stack that is used Affected range >=2:8.39-15 Fixed version Not Fixed EPSS Score 0.37% EPSS Percentile 73rd percentile Description In PCRE 8.41, the OP_KETRMAX feature in the match function in pcre_exec.c allows stack exhaustion (uncontrolled recursion) when processing a crafted regular expression.

openldap 2.5.13+dfsg-5 (deb) pkg:deb/debian/[email protected]%2Bdfsg-5?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=2.5.13+dfsg-5 Fixed version Not Fixed EPSS Score 0.16% EPSS Percentile 54th percentile Description libldap in certain third-party OpenLDAP packages has a certificate-validation flaw when the third-party package is asserting RFC6125 support. It considers CN even when there is a non-matching subjectAltName (SAN). This is fixed in, for example, openldap-2.4.46-10.el8 in Red Hat Enterprise Linux. Affected range >=2.5.13+dfsg-5 Fixed version Not Fixed EPSS Score 0.41% EPSS Percentile 74th percentile Description contrib/slapd-modules/nops/nops.c in OpenLDAP through 2.4.45, when both the nops module and the memberof overlay are enabled, attempts to free a buffer that was allocated on the stack, which allows remote attackers to cause a denial of service (slapd crash) via a member MODDN operation. Affected range >=2.5.13+dfsg-5 Fixed version Not Fixed EPSS Score 0.04% EPSS Percentile 11th percentile Description slapd in OpenLDAP 2.4.45 and earlier creates a PID file after dropping privileges to a non-root account, which might allow local users to kill arbitrary processes by leveraging access to this non-root account for PID file modification before a root script executes a "kill cat /pathname" command, as demonstrated by openldap-initscript. Affected range >=2.5.13+dfsg-5 Fixed version Not Fixed EPSS Score 0.42% EPSS Percentile 75th percentile Description The nss_parse_ciphers function in libraries/libldap/tls_m.c in OpenLDAP does not properly parse OpenSSL-style multi-keyword mode cipher strings, which might cause a weaker than intended cipher to be used and allow remote attackers to have unspecified impact via unknown vectors.

krb5 1.20.1-2+deb12u2 (deb) pkg:deb/debian/[email protected]%2Bdeb12u2?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=1.20.1-2+deb12u2 Fixed version Not Fixed EPSS Score 0.04% EPSS Percentile 10th percentile Description Kerberos 5 (aka krb5) 1.21.2 contains a memory leak vulnerability in /krb5/src/lib/gssapi/krb5/k5sealv3.c. Affected range >=1.20.1-2+deb12u2 Fixed version Not Fixed EPSS Score 0.04% EPSS Percentile 10th percentile Description Kerberos 5 (aka krb5) 1.21.2 contains a memory leak in /krb5/src/lib/rpc/pmap_rmt.c. Affected range >=1.20.1-2+deb12u2 Fixed version Not Fixed EPSS Score 0.10% EPSS Percentile 42nd percentile Description An issue was discovered in MIT Kerberos 5 (aka krb5) through 1.16. There is a variable "dbentry->n_key_data" in kadmin/dbutil/dump.c that can store 16-bit data but unknowingly the developer has assigned a "u4" variable to it, which is for 32-bit data. An attacker can use this vulnerability to affect other artifacts of the database as we know that a Kerberos database dump file contains trusted data.

gcc-12 12.2.0-14 (deb) pkg:deb/debian/[email protected]?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=12.2.0-14 Fixed version Not Fixed EPSS Score 0.06% EPSS Percentile 26th percentile Description DISPUTEDA failure in the -fstack-protector feature in GCC-based toolchains that target AArch64 allows an attacker to exploit an existing buffer overflow in dynamically-sized local variables in your application without this being detected. This stack-protector failure only applies to C99-style dynamically-sized local variables or those created using alloca(). The stack-protector operates as intended for statically-sized local variables. The default behavior when the stack-protector detects an overflow is to terminate your application, resulting in controlled loss of availability. An attacker who can exploit a buffer overflow without triggering the stack-protector might be able to change program flow control to cause an uncontrolled loss of availability or to go further and affect confidentiality or integrity. NOTE: The GCC project argues that this is a missed hardening bug and not a vulnerability by itself. Affected range >=12.2.0-14 Fixed version Not Fixed EPSS Score 0.09% EPSS Percentile 39th percentile Description libiberty/rust-demangle.c in GNU GCC 11.2 allows stack consumption in demangle_const, as demonstrated by nm-new.

perl 5.36.0-7+deb12u1 (deb) pkg:deb/debian/[email protected]%2Bdeb12u1?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=5.36.0-7+deb12u1 Fixed version Not Fixed EPSS Score 0.28% EPSS Percentile 69th percentile Description HTTP::Tiny before 0.083, a Perl core module since 5.13.9 and available standalone on CPAN, has an insecure default TLS configuration where users must opt in to verify certificates. Affected range >=5.36.0-7+deb12u1 Fixed version Not Fixed EPSS Score 0.24% EPSS Percentile 65th percentile Description _is_safe in the File::Temp module for Perl does not properly handle symlinks.

libpcap 1.10.3-1 (deb) pkg:deb/debian/[email protected]?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=1.10.3-1 Fixed version Not Fixed EPSS Score 0.04% EPSS Percentile 10th percentile Description Remote packet capture support is disabled by default in libpcap. When a user builds libpcap with remote packet capture support enabled, one of the functions that become available is pcap_findalldevs_ex(). One of the function arguments can be a filesystem path, which normally means a directory with input data files. When the specified path cannot be used as a directory, the function receives NULL from opendir(), but does not check the return value and passes the NULL value to readdir(), which causes a NULL pointer derefence. Affected range >=1.10.3-1 Fixed version Not Fixed EPSS Score 0.04% EPSS Percentile 10th percentile Description In affected libpcap versions during the setup of a remote packet capture the internal function sock_initaddress() calls getaddrinfo() and possibly freeaddrinfo(), but does not clearly indicate to the caller function whether freeaddrinfo() still remains to be called after the function returns. This makes it possible in some scenarios that both the function and its caller call freeaddrinfo() for the same allocated memory block. A similar problem was reported in Apple libpcap, to which Apple assigned CVE-2023-40400.

m4 1.4.19-3 (deb) pkg:deb/debian/[email protected]?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=1.4.19-3 Fixed version Not Fixed EPSS Score 2.99% EPSS Percentile 91st percentile Description Unspecified vulnerability in GNU m4 before 1.4.11 might allow context-dependent attackers to execute arbitrary code, related to improper handling of filenames specified with the -F option. NOTE: it is not clear when this issue crosses privilege boundaries. Affected range >=1.4.19-3 Fixed version Not Fixed EPSS Score 2.12% EPSS Percentile 90th percentile Description The (1) maketemp and (2) mkstemp builtin functions in GNU m4 before 1.4.11 do not quote their output when a file is created, which might allow context-dependent attackers to trigger a macro expansion, leading to unspecified use of an incorrect filename.

util-linux 2.38.1-5+deb12u2 (deb) pkg:deb/debian/[email protected]%2Bdeb12u2?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=2.38.1-5+deb12u2 Fixed version Not Fixed EPSS Score 0.05% EPSS Percentile 18th percentile Description A flaw was found in the util-linux chfn and chsh utilities when compiled with Readline support. The Readline library uses an "INPUTRC" environment variable to get a path to the library config file. When the library cannot parse the specified file, it prints an error message containing data from the file. This flaw allows an unprivileged user to read root-owned files, potentially leading to privilege escalation. This flaw affects util-linux versions prior to 2.37.4.

gnupg2 2.2.40-1.1 (deb) pkg:deb/debian/[email protected]?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=2.2.40-1.1 Fixed version Not Fixed EPSS Score 0.05% EPSS Percentile 18th percentile Description GnuPG can be made to spin on a relatively small input by (for example) crafting a public key with thousands of signatures attached, compressed down to just a few KB.

curl 7.88.1-10+deb12u8 (deb) pkg:deb/debian/[email protected]%2Bdeb12u8?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=7.88.1-10+deb12u8 Fixed version Not Fixed EPSS Score 0.04% EPSS Percentile 14th percentile Description libcurl skips the certificate verification for a QUIC connection under certain conditions, when built to use wolfSSL. If told to use an unknown/bad cipher or curve, the error path accidentally skips the verification and returns OK, thus ignoring any certificate problems.

sqlite3 3.40.1-2+deb12u1 (deb) pkg:deb/debian/[email protected]%2Bdeb12u1?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=3.40.1-2+deb12u1 Fixed version Not Fixed EPSS Score 0.22% EPSS Percentile 61st percentile Description A Memory Leak vulnerability exists in SQLite Project SQLite3 3.35.1 and 3.37.0 via maliciously crafted SQL Queries (made via editing the Database File), it is possible to query a record, and leak subsequent bytes of memory that extend beyond the record, which could let a malicious user obtain sensitive information. NOTE: The developer disputes this as a vulnerability stating that If you give SQLite a corrupted database file and submit a query against the database, it might read parts of the database that you did not intend or expect.

tar 1.34+dfsg-1.2+deb12u1 (deb) pkg:deb/debian/[email protected]%2Bdfsg-1.2%2Bdeb12u1?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=1.34+dfsg-1.2+deb12u1 Fixed version Not Fixed EPSS Score 0.69% EPSS Percentile 81st percentile Description Tar 1.15.1 does not properly warn the user when extracting setuid or setgid files, which may allow local users or remote attackers to gain privileges.

shadow 1:4.13+dfsg1-1 (deb) pkg:deb/debian/shadow@1:4.13%2Bdfsg1-1?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=1:4.13+dfsg1-1 Fixed version Not Fixed EPSS Score 0.16% EPSS Percentile 53rd percentile Description initscripts in rPath Linux 1 sets insecure permissions for the /var/log/btmp file, which allows local users to obtain sensitive information regarding authentication attempts. NOTE: because sshd detects the insecure permissions and does not log certain events, this also prevents sshd from logging failed authentication attempts by remote attackers.

apt 2.6.1 (deb) pkg:deb/debian/[email protected]?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=2.6.1 Fixed version Not Fixed EPSS Score 0.16% EPSS Percentile 54th percentile Description It was found that apt-key in apt, all versions, do not correctly validate gpg keys with the master keyring, leading to a potential man-in-the-middle attack.

gnutls28 3.7.9-2+deb12u3 (deb) pkg:deb/debian/[email protected]%2Bdeb12u3?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=3.7.9-2+deb12u3 Fixed version Not Fixed EPSS Score 0.60% EPSS Percentile 79th percentile Description The SSL protocol, as used in certain configurations in Microsoft Windows and Microsoft Internet Explorer, Mozilla Firefox, Google Chrome, Opera, and other products, encrypts data by using CBC mode with chained initialization vectors, which allows man-in-the-middle attackers to obtain plaintext HTTP headers via a blockwise chosen-boundary attack (BCBA) on an HTTPS session, in conjunction with JavaScript code that uses (1) the HTML5 WebSocket API, (2) the Java URLConnection API, or (3) the Silverlight WebClient API, aka a "BEAST" attack.

net-tools 2.10-0.1 (deb) pkg:deb/debian/[email protected]?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=2.10-0.1 Fixed version Not Fixed EPSS Score 0.06% EPSS Percentile 26th percentile Description ifconfig, when used on the Linux kernel 2.2 and later, does not report when the network interface is in promiscuous mode if it was put in promiscuous mode using PACKET_MR_PROMISC, which could allow attackers to sniff the network without detection, as demonstrated using libpcap.

nmap 7.93+dfsg1-1 (deb) pkg:deb/debian/[email protected]%2Bdfsg1-1?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=7.93+dfsg1-1 Fixed version Not Fixed EPSS Score 2.28% EPSS Percentile 90th percentile Description Nmap through 7.70, when the -sV option is used, allows remote attackers to cause a denial of service (stack consumption and application crash) via a crafted TCP-based service.

libxml2 2.9.14+dfsg-1.3~deb12u1 (deb) pkg:deb/debian/[email protected]%2Bdfsg-1.3~deb12u1?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=2.9.14+dfsg-1.3~deb12u1 Fixed version Not Fixed EPSS Score 0.04% EPSS Percentile 11th percentile Description An issue was discovered in xmllint (from libxml2) before 2.11.8 and 2.12.x before 2.12.7. Formatting error messages with xmllint --htmlout can result in a buffer over-read in xmlHTMLPrintFileContext in xmllint.c.

coreutils 9.1-1 (deb) pkg:deb/debian/[email protected]?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=9.1-1 Fixed version Not Fixed EPSS Score 0.04% EPSS Percentile 5th percentile Description In GNU Coreutils through 8.29, chown-core.c in chown and chgrp does not prevent replacement of a plain file with a symlink during use of the POSIX "-R -L" options, which allows local users to modify the ownership of arbitrary files by leveraging a race condition.

glib2.0 2.74.6-2+deb12u4 (deb) pkg:deb/debian/[email protected]%2Bdeb12u4?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=2.74.6-2+deb12u4 Fixed version Not Fixed EPSS Score 0.16% EPSS Percentile 53rd percentile Description GLib 2.31.8 and earlier, when the g_str_hash function is used, computes hash values without restricting the ability to trigger hash collisions predictably, which allows context-dependent attackers to cause a denial of service (CPU consumption) via crafted input to an application that maintains a hash table. NOTE: this issue may be disputed by the vendor; the existence of the g_str_hash function is not a vulnerability in the library, because callers of g_hash_table_new and g_hash_table_new_full can specify an arbitrary hash function that is appropriate for the application.

libgcrypt20 1.10.1-3 (deb) pkg:deb/debian/[email protected]?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=1.10.1-3 Fixed version Not Fixed EPSS Score 0.19% EPSS Percentile 58th percentile Description cipher/elgamal.c in Libgcrypt through 1.8.2, when used to encrypt messages directly, improperly encodes plaintexts, which allows attackers to obtain sensitive information by reading ciphertext data (i.e., it does not have semantic security in face of a ciphertext-only attack). The Decisional Diffie-Hellman (DDH) assumption does not hold for Libgcrypt's ElGamal implementation.

openssl 3.0.15-1~deb12u1 (deb) pkg:deb/debian/[email protected]~deb12u1?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=3.0.11-1~deb12u2 Fixed version Not Fixed EPSS Score 0.07% EPSS Percentile 30th percentile Description OpenSSL 0.9.8i on the Gaisler Research LEON3 SoC on the Xilinx Virtex-II Pro FPGA uses a Fixed Width Exponentiation (FWE) algorithm for certain signature calculations, and does not verify the signature before providing it to a caller, which makes it easier for physically proximate attackers to determine the private key via a modified supply voltage for the microprocessor, related to a "fault-based attack."

net-snmp 5.9.3+dfsg-2 (deb) pkg:deb/debian/[email protected]%2Bdfsg-2?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=5.9.3+dfsg-2 Fixed version Not Fixed Description net-snmp 5.9.4 contains a memory leak vulnerability in /net-snmp/apps/snmpvacm.c.

[nichtsfrei]

Keep in mind that the io::ErrorKind is used to identify retry cases, see https://github.com/greenbone/openvas-scanner/blob/main/rust/src/nasl/interpreter/interpreter.rs#L196 for an incomplete example. The possibility to identify cases that can be retried transparently to the user should be considered.

[Tehforsch]

Keep in mind that the io::ErrorKind is used to identify retry cases, see https://github.com/greenbone/openvas-scanner/blob/main/rust/src/nasl/interpreter/interpreter.rs#L196 for an incomplete example. The possibility to identify cases that can be retried transparently to the user should be considered.

I think we need a more robust set up to identify these cases. Using IO errors to mean retryable might be a good heuristic, but is still not accurate, since there are both false positives (io::ErrorKind::NotADirectory is not something that will be solved by retrying) and false negatives (an ssh connection might fail due to a timeout but won't return an IO error).
I am not sure that we can find a high level structure that represents re-try-ability well and would prefer doing this on a "local" level, i.e. someting like

foo().map_err(|e| MyCustomError::MyCustomErrorVariant(e).retryable())`

(method naming very much up for debate)

[nichtsfrei]

Yes, it’s imperfect—I wasn’t suggesting we use it as-is. However, this concept is entirely missing from the current proposal, even though it’s available, albeit imperfectly, in the current handling.

I’m not in favor of implementing it at a local level because it relies too heavily on the function developer's knowledge and could lead to inconsistent handling, making it harder to reason about, inconvenient, and adding cognitive load—especially when you just want to quickly create a built-in function.

[Tehforsch]

Yes, it’s imperfect—I wasn’t suggesting we use it as-is. However, this concept is entirely missing from the current proposal, even though it’s available, albeit imperfectly, in the current handling.

Yes, youre right.

I’m not in favor of implementing it at a local level because it relies too heavily on the function developer's knowledge and could lead to inconsistent handling, making it harder to reason about, inconvenient, and adding cognitive load—especially when you just want to quickly create a built-in function.

I was also afraid of that, but if we don't trust the author of the builtin function to make the correct decision on whether an error is solvable by retrying or not, then I don't think we have a chance of solving this problem anyways. I would prefer doing this on a local level because it still gives us the room to discuss these things in code review etc.. I think making the overarching structure of the error type determine whether an error is "retryable" or not carries a larger risk because we will eventually have to fight our own system if we want more precise control over these errors.

This also doesn't always have to be solved on the most local level, because you could, for example, write an From impl for your error type such as

impl From<io::Error> for MyCustomError {
    fn from(val: io:Error) -> MyCustomError {
        MyCustomError::Foo(val).retryable()
    }
}

which effectively reproduces the original behavior of making any io::Error something that can be solved by retrying, but does it on a more fine-grained level (for an entire builtin module), where it might always make sense.