Previously, multi-line directives like '.info' or '.error' reported the
line number of their last line instead of their first line, which is
more usual. This also affected the debug log from '-dp'.
Without this change the LEDs would get stuck on until the first
keypress. (This also seemed to trigger a crash in heavy load on
bringing aue(4) up and down over and over again while unplugging, but
I'm not sure why and I hope it's not actually related...)
Support -? to show help.
Implemented using getopts "leading colon optstring" feature.
Improve error messages for unknown options and missing arguments.
Show options alphabetically.
Use UPPER_CASE instead of lowercase as the convention for argument names.
Provide per-OPERATION argument usage.
Implement options alphabetically.
Validate the operation and items before extracting any etc.tgz,
so that help or errors are displayed quicker, for a better user
experience.
Style:
- Rename todo to ITEMS.
- Order processing of list after check.
- Ensure DIFF_OPT is initialised, for consistency.
When invoked as "help" or "usage", send the usage to stdout
instead of stderr, so that it's easier to pipe to a pager.
Explicitly warn that the operation is missing.
Tweak the usage; "operation" instead of "op", no need for [] around ...
Put related decisions on the same indentation level, remove unnecessary
negation, keep the code for the '.for' directive together.
No functional change.
The input buffer is guaranteed to be terminated by '\n'. This means
that after a '\\', there is no need to check for the end of that buffer.
While here, condense ReadLowLevelLine.
No functional change.
The previous variable name suggested that the variable would point to
the first '#' character of the line, instead it points to the whitespace
before the first '#'.
No functional change.
The comment in ApplyDependencySourceOther repeated the code, its second
half didn't match any current code.
The comment above ParseDependencySourcesEmpty repeated the code.
No binary change, except for assertion line numbers.
Sort ForLoop members in natural reading order.
Remove redundant condition in ForLoop_ParseItems; at that point, the
number of variables is non-zero.
Rename Buf_AddEscaped since that function is not part of the Buffer API,
it is specific to .for loops.
No functional change.
Since the body of a .for loop is scanned from start to end, there is no
need to remember the length of a variable name.
Using memcmp for comparing the variable name was probably overkill since
the variable names are usually very short, so rather compare them byte
by byte.
No functional change.
*) Avoid loading of a dynamic engine twice.
[Bernd Edlinger]
*) Fixed building on Debian with kfreebsd kernels
[Mattias Ellert]
*) Prioritise DANE TLSA issuer certs over peer certs
[Viktor Dukhovni]
*) Fixed random API for MacOS prior to 10.12
These MacOS versions don't support the CommonCrypto APIs
[Lenny Primak]
Changes between 1.1.1k and 1.1.1l [24 Aug 2021]
*) Fixed an SM2 Decryption Buffer Overflow.
In order to decrypt SM2 encrypted data an application is expected
to call the API function EVP_PKEY_decrypt(). Typically an application
will call this function twice. The first time, on entry, the "out"
parameter can be NULL and, on exit, the "outlen" parameter is
populated with the buffer size required to hold the decrypted
plaintext. The application can then allocate a sufficiently sized
buffer and call EVP_PKEY_decrypt() again, but this time passing
a non-NULL value for the "out" parameter.
A bug in the implementation of the SM2 decryption code means that
the calculation of the buffer size required to hold the plaintext
returned by the first call to EVP_PKEY_decrypt() can be smaller
than the actual size required by the second call. This can lead to
a buffer overflow when EVP_PKEY_decrypt() is called by the application
a second time with a buffer that is too small.
A malicious attacker who is able present SM2 content for decryption
to an application could cause attacker chosen data to overflow the
buffer by up to a maximum of 62 bytes altering the contents of
other data held after the buffer, possibly changing application
behaviour or causing the application to crash. The location of the
buffer is application dependent but is typically heap allocated.
(CVE-2021-3711)
[Matt Caswell]
*) Fixed various read buffer overruns processing ASN.1 strings
ASN.1 strings are represented internally within OpenSSL as an
ASN1_STRING structure which contains a buffer holding the string
data and a field holding the buffer length. This contrasts with
normal C strings which are repesented as a buffer for the string
data which is terminated with a NUL (0) byte.
Although not a strict requirement, ASN.1 strings that are parsed
using OpenSSL's own "d2i" functions (and other similar parsing
functions) as well as any string whose value has been set with the
ASN1_STRING_set() function will additionally NUL terminate the byte
array in the ASN1_STRING structure.
However, it is possible for applications to directly construct
valid ASN1_STRING structures which do not NUL terminate the byte
array by directly setting the "data" and "length" fields in the
ASN1_STRING array. This can also happen by using the ASN1_STRING_set0()
function.
Numerous OpenSSL functions that print ASN.1 data have been found
to assume that the ASN1_STRING byte array will be NUL terminated,
even though this is not guaranteed for strings that have been
directly constructed. Where an application requests an ASN.1
structure to be printed, and where that ASN.1 structure contains
ASN1_STRINGs that have been directly constructed by the application
without NUL terminating the "data" field, then a read buffer overrun
can occur.
The same thing can also occur during name constraints processing
of certificates (for example if a certificate has been directly
constructed by the application instead of loading it via the OpenSSL
parsing functions, and the certificate contains non NUL terminated
ASN1_STRING structures). It can also occur in the X509_get1_email(),
X509_REQ_get1_email() and X509_get1_ocsp() functions.
If a malicious actor can cause an application to directly construct
an ASN1_STRING and then process it through one of the affected
OpenSSL functions then this issue could be hit. This might result
in a crash (causing a Denial of Service attack). It could also
result in the disclosure of private memory contents (such as private
keys, or sensitive plaintext).
(CVE-2021-3712)
[Matt Caswell]
For lines that use backslash continuation, the human-readable line
number does not equal the number of raw lines that have been read from
the file.
The big comment in PrintStackTrace has become outdated, it still
referred to first_lineno. Due to the bugs documented in
opt-debug-parse.mk, that function needs to be redone completely.
No functional change.
This enables GCC 11 to inline ApplyModifier_Time, like all the other
modifiers. Similar pattern as for ':M' and ':N', as well as for ':D'
and ':U'.
No functional change.
Use consistent wording (zulu -> gmt), make VarStrftime parameter order
consistent with strftime, rename confusing 'time_t utc' to 't',
eliminate common subexpression in error message.
No functional change.
It is not necessary anymore to modify the passed-in line. It had been
necessary when the parsing function was several hundred lines long, to
avoid gotos.
No functional change.
rillig