We had all kinds of indentation: 2 sp, 3 sp, 4 sp, 8 sp, and mixed.
4 sp was the most common, in particular the majority of scripts under test/
used that. Let's standarize on 4 sp, because many commandlines are long and
there's a lot of nesting, and with 8sp indentation less stuff fits. 4 sp
also seems to be the default indentation, so this will make it less likely
that people will mess up if they don't load the editor config. (I think people
often use vi, and vi has no support to load project-wide configuration
automatically. We distribute a .vimrc file, but it is not loaded by default,
and even the instructions in it seem to discourage its use for security
reasons.)
Also remove the few vim config lines that were left. We should either have them
on all files, or none.
Also remove some strange stuff like '#!/bin/env bash', yikes.
We have a few cases or reported issues which are about a timeout to parse
the input in 25 s. In all cases, the input is a few hundred kb. We don't really
care if the config parsers are super efficent, so let's set a limit on the input
size to avoid triggering such issues. The parsers often contain quadratic
algorithms. This is OK, because the numbers of elements are almost always very
small in real use. Rewriting the code to use more complicated data structures
to speed this up would not only complicate the code, but also pessimize behaviour
for the overwhelmingly common case of small samples. Note that in all those
cases, the input data is trusted. We care about memory correctness, and not
not so much about efficiency.
The size checks are done twice: using options for libfuzzer, and using an
internal check for afl. Those should be changed together. I didn't use a define,
because there is no easy mechanism to share the define between the two files.
It was already the case before commit a75211421f,
which upgraded the log to warning.
This seems an unintended side effect as the commit message doesn't mention it
and the old behavior looks more appropriate.
This fixes bugs introduced by 29448498c7
and d838e14515.
Previously, RUN and SECLABEL keys are stored in udev_list with its unique
flag is false. If the flag is false, then udev_list is just a linked
list and new entries are always added in the last.
So, we should use OrderedHashmap instead of Hashmap.
Fixes#11368.
CID#996458. Coverity warns that we trust desc->bLength as read in
the input data to adjust our position in the buffer. This value could
be anything, leading to overflow. It's unlikely that the kernel feeds
us invalid data, but let's me more careful.
If any error is encountered, more logs are given.
