| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
Given that RFC 5652 does not override the earlier (and simpler)
standards but instead strives to remain compatible, referencing
both the original and the latest versions seems helpful.
OK tb@
|
|
|
|
|
|
|
| |
Document the change of behavor from pk7_attr.c r1.17: the time is now
validated to be in correct RFC 5280 time format.
ok kenjiro
|
|
|
|
|
| |
because PEM_X509_INFO_read(3) no longer exists.
Requested by tb@.
|
| |
|
|
|
|
| |
because tb@ removed them from Symbols.list rev. 1.220 today.
|
| |
|
|
|
|
|
| |
These annoying and careless inconsistencies were introduced when const
was sprinkled everywhere without rhyme or reason.
|
| |
|
| |
|
|
|
|
|
| |
These have been taking a const pkey ever since they were added in
OpenSSL 1.0.0.
|
|
|
|
| |
ok job kenjiro
|
|
|
|
| |
This was changed a bit more than two years ago.
|
|
|
|
|
|
|
| |
10% of our manual pages using this macro employed useless quoting anyway.
Remove these quotes such that they do not incite fear, uncertainty,
and doubt in developers who happen to look at these pages.
jmc@ and tb@ agree with the direction.
|
|
|
|
|
|
|
|
| |
claiming that the "add" functions add anything. Indicate that they
are mostly NOOPs nowadays, but without being overly specific.
Also, more explicitly discourage abusing OpenSSL_add_all_algorithms(3)
for loadiing a configuration file.
Guidance and OK tb@.
|
| |
|
|
|
|
|
| |
are no longer public, so delete their manual pages.
OK tb@
|
|
|
|
|
|
|
| |
descriptions of CMS_REUSE_DIGEST, PKCS7_REUSE_DIGEST, SMIME_BINARY,
and SMIME_CRLFEOL and some improved wordings from that former page to
SMIME_write_CMS(3) and SMIME_write_PKCS7(3), with some further polishing.
Feedback and OK tb@.
|
|
|
|
|
|
| |
and since SMIME_write_ASN1(3) is no longer public,
replace the .Xr to it with some other pointers.
OK tb@
|
|
|
|
|
|
| |
so link to SMIME_read_CMS(3), SMIME_read_PKCS7(3), SMIME_write_CMS(3),
and/or SMIME_write_PKCS7(3) instead;
OK tb@
|
|
|
|
|
|
| |
so link to SMIME_read_CMS(3) or SMIME_read_PKCS7(3) instead,
and sprinkle a few other .Xrs that may be helpful;
OK tb@
|
|
|
|
|
| |
because these functions no longer exist.
OK tb@
|
|
|
|
| |
OK tb@
|
|
|
|
| |
"sounds good" tb@
|
| |
|
|
|
|
|
| |
that no longer exists, and add .Lb;
OK tb@
|
| |
|
| |
|
|
|
|
|
| |
The _cb() variants were only documented as intentionally undocumented.
Be that as it may, they left the building more than a year ago.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This replaces the giant, poor quality and outdated EC_GROUP_copy.3,
EC_GROUP_new.3, and EC_POINT_new.3 manuals with seven new manuals
written from scratch.
* EC_GROUP_new_by_curve_name() is the entry point for builtin curves,
* EC_GROUP_new_curve_GFp() describes lower level API that should not
usually be needed apart from a handful of accessors.
* EC_GROUP_check() contains two functions that applications should not
need because either you know for certain something is an elliptic
curve (so these checks are pointless) or you should not use it.
* EC_GROUP_get_curve_name() describes some low level ASN.1 footguns
and corresponding getters.
* EC_POINT_new() contains the simple EC_POINT allocation and freeing API
* EC_POINT_get_affine_coordinates() contains the coordinate accessors
* EC_POINT_point2oct() is about encoding elliptic curve points
While all this is quite far from perfect, the diff is getting too big
and it will be easier to improve this in tree. It is definitely more
repetitive than I would like it to be.
Reviews, tweaks and general feedback are of course welcome.
discussed with jsing
|
|
|
|
|
|
|
|
|
| |
-This type should be considered opaque and fields should not be modified
-or accessed directly.
The type has long been opaque and reasonable people will not do things
that permit them to access the fields of opaque types directly. Of course,
in the vicinity of OpenSSL code and API all sorts of insanity actually exist.
|
|
|
|
|
| |
The mix of SHA256 and SHA-256 is jarring, so use FIPS's spelling.
Leave HMAC-SHA256 as it is and fix a nearby RIPEMD-160.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current documentation was clearly incorrect since a return of -1 from
the methods is explicitly intercepted and translated to 0. schwarze and I
both audited the tree and concluded that only 0 and 1 is possible.
OpenSSL 3 broke this API contract and now has explicit return -1 in the
convoluted 200-line maze this simple function has become with recent
provider improvements. So add a small sentence hinting at that. Nobody
will be surprised to read that with OpenSSL's characteristic penchant
for needless inconsistency the return value checks in their tree are all
over the place and sometimes incorrect.
ok schwarze (with two tweaks)
|
|
|
|
|
|
| |
Variables of the type serialized or deserialized are called val_in or
val_out in all other manuals, so align this page to using those rather
than the confusing X509_CRL **der_out, etc.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|