openbsd/src/lib/libcrypto/man, branch libressl-v3.8.2 A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=libressl-v3.8.2 2023-10-03T09:58:06+00:00 Fix a typo and move a word 2023-10-03T09:58:06+00:00 tb 2023-10-03T09:58:06+00:00 urn:sha1:08e7cae74e8cb6e634c1d7425b6fed61c8069f5a Example code tweak: do not hardcode the size of array 2023-10-01T22:46:21+00:00 tb 2023-10-01T22:46:21+00:00 urn:sha1:e238d8127f4b481f01fc931c4df0d81b341e9953 Document EVP_CIPHER_CTX_iv_length() return values 2023-10-01T18:23:50+00:00 tb 2023-10-01T18:23:50+00:00 urn:sha1:14325811a46be3e6d6d9a2f3e7431ed8789a08ed We aligned with upstream behavior. Let's document it properly. Surprisingly, OpenSSL 1.1 half-assed the docs: two parts of the manual contradict each other. The part getting EVP_CIPHER_CTX_iv_length() right, incorrectly documents possible -1 return value to EVP_CIPHER_iv_length(). OpenSSL 3 documentation improvement efforts seem to have tried to address this issue with the result that the manual is now entirely wrong when it comes to the EVP_CIPHER_CTX_iv_length() replacement. Par for the course. The colons separate the octets, not the digits; add missing link to 2023-10-01T10:51:19+00:00 tb 2023-10-01T10:51:19+00:00 urn:sha1:2877b0c96c385a58189dc0d110887eadd2730d0e crypto(3) Improve a code comment in the EXAMPLES section 2023-10-01T08:29:12+00:00 tb 2023-10-01T08:29:12+00:00 urn:sha1:741f3b8e0f4b440e8a7a379659d9b42a1c849f79 Refer to RFC 3779, 2.1.2 for encoding of ranges 2023-10-01T08:23:58+00:00 tb 2023-10-01T08:23:58+00:00 urn:sha1:7a28ba92270c2d6ff7cbe1a97e60c85f1e516c5e Mention sections 2.1.1 and 2.1.2 in STANDARDS Point out that the result of IPAddressRange_new() is an invalid range 2023-10-01T08:17:52+00:00 tb 2023-10-01T08:17:52+00:00 urn:sha1:c368b6f736b5114a569a1bf0056c7b2ab27fbeb0 since it should be a prefix. encoding -> decoding for d2i 2023-10-01T05:20:41+00:00 tb 2023-10-01T05:20:41+00:00 urn:sha1:0dd23d93feab229c0eae430649b3a0c051ea1040 Reorder list of additional validation checks needed 2023-09-30T19:07:38+00:00 tb 2023-09-30T19:07:38+00:00 urn:sha1:403bf875937525bac051a8d6668ec62f9928f011 Switch copyright year to 2023. 2023-09-30T18:16:44+00:00 tb 2023-09-30T18:16:44+00:00 urn:sha1:09334fdc67593f5851df2b213e8f78f8d8c2e42b Apparently I should have used 2023 despite sharing versions of these files with several people under this license (and thus permitting them to redistribute and share with the public). It makes no sense to me, but shrug.