| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
switch to generating them by default. prodded by deraadt and sthen
|
|
|
|
|
|
|
| |
have resulted in a segfault. Also update the resulting output bytes now
that the invalid/corrupt input is detected and rejected; unless you're
using BIO_FLAGS_BASE64_NO_NL, in which case you still get a stream of
zero value bytes and no way of knowing that the data is invalid/corrupt.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
handling of padding. This fixes a crash that can be triggered by feeding
base64 data followed by 64 or more padding characters, which results in a
negative output length.
This issue was reported by David Ramos, although the same bug has been
sitting in the OpenSSL RT since 2011:
https://rt.openssl.org/Ticket/Display.html?id=2608
Worse still, BIO_read seems to be completely unable to detect that the
base64 input was invalid/corrupt - in particular, enabling
BIO_FLAGS_BASE64_NO_NL results in a stream of zero value bytes rather than
no input (possibly a good replacement for /dev/null...), which could
result in nasty consequences. Prior to this fix some zero value bytes were
also injected without this flag being enabled.
The recently added base64 regress triggers and documents these issues
(and also ensures that this change retains functional behaviour).
|
|
|
|
|
|
|
|
|
|
| |
2. Pull up the actual minor processing code into the switch that
parses it.
3. atoi is actually simpler than strtonum in this case, but check the
input beforehand so we don't get unexpected results.
4. Slightly more consistent style between various parse and check and
increment operations on salt.
ok deraadt
|
| |
|
| |
|
|
|
|
| |
ok deraadt@
|
| |
|
| |
|
|
|
|
| |
Assembler bits for AES remain commented out as they run slower than the C code.
|
|
|
|
|
| |
a SIGILL handler.
Do not attempt to detect and use a 64-bit FPU yet.
|
| |
|
| |
|
| |
|
|
|
|
| |
things. Worth doing as it's twice faster than the C code.
|
|
|
|
|
|
|
|
|
|
|
|
| |
processor (PA2.0) and, if so, switches to 64-bit code.
However, when running under a 32-bit OpenBSD/hppa kernel, there is no guarantee
that the upper part of the registers will be preserved accross context switches
(or even userland->kernel boundaries), which causes this code to fail.
Wrap the generated code within #ifndef __OpenBSD__ in that case, to avoid
using the 64-bit code completely. (OpenBSD/hppa64, once stable, will not be
affected by this)
|
|
|
|
| |
from http://csrc.nist.gov/groups/ST/toolkit/examples.html
|
| |
|
|
|
|
| |
ok beck@ miod@
|
| |
|
|
|
|
| |
ok beck@
|
|
|
|
|
|
| |
than once.
ok beck@
|
|
|
|
| |
ok beck@
|
|
|
|
| |
RC4 assembler code is not used, as it runs about 35% slower than the C code.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
ok miod@
|
| |
|
|
|
|
| |
ok miod@
|
|
|
|
| |
ok miod@
|
|
|
|
| |
ok deraadt@
|
|
|
|
|
|
|
|
|
|
| |
While not to be considered a good choice of elliptic curve (refer to
http://safecurves.cr.yp.to/ for more details), it is nevertheless deemed a
good decision to allow developers with requirements to use such a curve,
to be able to do this via a crypto library allowing for much better choices
to be made, without having to change (much of) their code to get better crypto.
ok beck@ deraadt@
|
|
|
|
|
| |
Be sure to rerun `make includes' after updating.
ok tedu@ beck@ deraadt@
|
|
|
|
|
|
|
| |
OpenSSL FIPS module to prevent forbidden digests to be allowed.
No functional change but readability.
ok deraadt@
|
|
|
|
|
| |
a free chunk at random and may allow to increase delayed chunk array.
ok otto
|
|
|
|
| |
default and the new 'j' option to disable this; ok jmc@
|
|
|
|
|
|
| |
managed to allocate a fragment, before trying to memcpy data into it.
ok miod@
|
|
|
|
|
|
|
| |
scripts. We certainly do not need an identical copy of the win64
exception handler in each script (surely one copy would be sufficient).
ok miod@
|
| |
|
|
|
|
| |
ok miod@ tedu@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a getaddrinfo() flag that is defined thusly in RFC 3493:
If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be
returned only if an IPv4 address is configured on the local system,
and IPv6 addresses shall be returned only if an IPv6 address is
configured on the local system. The loopback address is not
considered for this case as valid as a configured address.
For example, when using the DNS, a query for AAAA records should
occur only if the node has at least one IPv6 address configured
(other than IPv6 loopback) and a query for A records should occur
only if the node has at least one IPv4 address configured (other
than the IPv4 loopback).
The flag is set by default when hints is NULL.
ok Eric Faurot, Jason McIntyre
|