Age | Commit message (Collapse) | Author |
|
In the legacy stack, a message handling function returns -1 for failure,
0 for need more data and 1 for success (although in extra special cases
2 may also be used). However, the various send/get kex functions only
need to indicate success or failure - switch these to return 0 on failure
(rather than -1) and use normal result testing.
This leaves GOST unchanged for now, as that code is special and needs
extra work.
ok inoguchi@ tb@
|
|
|
|
If we receive something other than a "named curve", send a handshake
failure alert as we're unable to complete the handshake with the given
parameters. If the server responded with a curve that we did not advertise
send an illegal parameter alert.
ok inoguchi@ tb@
|
|
This provides better symmetry with the parsing code and will allow for
better reuse with the legacy stack, which has different message structures.
ok inoguchi@ tb@
|
|
ok inoguchi@ tb@
|
|
completion. To leave files in /tmp, use new -k option.
|
|
|
|
Problem noted by naddy@
|
|
the binding to global (NB == "no binding"), as clang 13 is now
warning about changing the binding from global to weak.
This first pass does amd64 and sparc64 and pulls DEFS.h out of the
per-arch directory to a common directory; others to follow
ok kettenis@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
prefer this.
|
|
This is again a straightforward conversion and leads to something which
matches our usual style more.
ok jsing
|
|
Again, we're dealing with necessarily not fully validated data here,
so a check up front seems prudent.
ok jsing
|
|
This is a more or less straightforward conversion using the new
IPAddressFamily accessor API. As a result, some checks have become
a bit stricter, which is only desirable here.
ok jsing
|
|
As mentioned in a previous commit, IPAddressFamily_cmp() can't really
check for trailing garbage in addressFamily->data. Since the path
validation and hence the X.509 validator call X509v3_addr_is_canonical(),
this deals with only partially validated data.
ok jsing
|
|
Define and use MINIMUM() instead of a ternary operator and separate
the code from the declarations. Also, we can spare a line to make the
return legible instead of squeezing it into another ternary operator.
addressFamily->data contains a two-bytes AFI and an optional one-byte
SAFI. This function currently also compares any trailing garbage that
may be present. Since comparison functions can't really error, this
needs to be checked bofore it is used. Such checks will be added in
subsequent commits.
ok jsing
|
|
ok jsing
|
|
ok jsing
|
|
Declare IPAddressFamily before using it.
|
|
|
|
unknown address family types.
Pointed out by jsing during review.
|
|
One reason why this file is hard to read are endless repetitions of
checks and assignments reaching deep inside structs. This can be made
much more readable by adding a bunch of accessors. As a first step,
we deal with IPAddressFamily, where we want to check the type of the
ipAddressChoice member, check whether the inheritance element is present
or access the addressOrRanges field.
This diff already makes minimal use of these accessors to appease -Werror.
More use and additional accessors will follow in later passes.
ok inoguchi jsing
|
|
RFC 3779 section 2.1.2 does a decent job of explaining how IP addresses
are encoded in. What's stored amounts to a prefix with all trailing zero
octets omitted. If there are trailing zero bits in the last non-zero octet,
bs->flags & 7 indicates how many. addr_expand() expands this to an address
of length 4 or 16 depending on whether we deal with IPv4 or IPv6.
Since an address can be the lower or the upper bound of a prefix or
address range, expansion needs to be able to zero-fill or one-fill the
unused bits/octets. No other expansion is ever used, so simplify the
meaning of fill accordingly. There's no need to special case the case
that there are no unused bits, the masking/filling is a noop.
ok jsing
|
|
in make_IPAddressFamily()
|
|
The IPAddrBlocks type, which represents the IPAddrBlocks extension,
should have exactly one IPAddressFamily per AFI+SAFI combination to
be delegated. make_IPAddressFamily() first builds up a search key
from the afi and safi arguments and then looks for an existing
IPAddressFamily with that key in the IPAddrBlocks that was passed
in. It returns that if it finds it or allocates and adds a new one.
This diff preserves the current behavior that the afi and *safi
arguments are truncated to 2 and 1 bytes, respectively. This may
change in the future.
ok inoguchi jsing
|
|
The ASN.1 template for IPAddressFamily doesn't mark either of its two
members as optional, so they are allocated by IPAddressFamily_new().
ok inoguchi jsing
|
|
Per RFC 3779 2.2.3.3, the addressFamily field contains the 2-byte AFI
and an optional 1-byte SAFI. Nothing else. The optional SAFI is nowhere
exposed in the API. It is used expliclty only for pretty printing. There
are implicit uses in a few places, notably for sorting/comparing where
trailing garbage would be erroneously taken into account.
Erroring in this situation will let us avoid this in upcoming revisions.
ok inoguchi jsing
|
|
The manual byte bashing is performed more safely using this API
which would have avoided the out-of-bounds read that this API had
until a few years back.
The API is somewhat strange in that it uses the reserved AFI 0 as an
in-band error but it doesn't care about the reserved AFI 65535.
ok inoguchi jsing
|
|
Discussed with tb@
|
|
|
|
CID 345118
|
|
a weird coverity warning.
CID 345121
ok jsing
|
|
BN_with_flags() preserves the BN_FLG_MALLOCED flag of the destination
which results in a potential use of an uninitialized bit. In practice
this doesn't matter since we don't free the cloned BIGNUMs anyway.
As jsing points out, these are mostly pointless noise and should be
garbage collected. I'll leave that for another rainy day.
Coverity flagged one instance BN_gcd_no_branch(), the rest was found by
the ever so helpful grep(1).
CID 345122
ok jsing
|
|
a use of uninitialized in the unlikely event that either of them fails.
Problem introduced in r1.128.
CID 345113
ok jsing
|
|
Due to a wonderful API inconsistency, a client includes the peer's leaf
certificate in the stored certificate chain, while a server does not.
Found due to a haproxy test failure reported by Ilya Shipitsin.
ok tb@
|
|
|
|
|
|
|
|
as is done for most other X.509 v3 extension methods.
discussed with jsing
|
|
Whitespace change only.
|
|
No functional change.
|
|
No functional change.
|
|
No functional change.
|
|
Consolidate various ASN1_item_* functions into asn1_item.c and the
remaining NO_OLD_ASN1 code (not to be confused with the NO_ASN1_OLD code)
into asn1_old.c. This is preferable to having many files, often with one
or two functions per file.
No functional change.
Discussed with tb@
|
|
Where an ASN.1 type has its own file, move the ASN.1 item template and
template related functions into the file.
Discussed with tb@
|