Catch up to the removal of OSSL_STORE_open_file()
authorBenjamin Kaduk <bkaduk@akamai.com>
Thu, 29 Jun 2017 20:12:18 +0000 (15:12 -0500)
committerBenjamin Kaduk <kaduk@mit.edu>
Thu, 27 Jul 2017 19:32:13 +0000 (14:32 -0500)
Remove references to it in documentation.

Unfortunately, it is too late to renumber symbols in libcrypto.num
and avoid the NOEXIST entry there.

Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3860)

doc/man3/OSSL_STORE_INFO.pod
doc/man3/OSSL_STORE_open.pod
doc/man7/ossl_store.pod
include/openssl/store.h

index 1b0f23347adc79111e267ff12bcbdcddc2cb8d98..9b9e93b609ba7eaf75c2ab3b7d026e2fa059292c 100644 (file)
@@ -117,10 +117,10 @@ used by the application to get the objects in that file.
 This can be applied to all schemes that can somehow support a listing
 of object URIs.
 
 This can be applied to all schemes that can somehow support a listing
 of object URIs.
 
-For C<file:> URIs that are used without the explicit scheme, or paths
-given to L<OSSL_STORE_open_file(3)>, the returned name will be the path of
-each object, so if C</foo/bar> was given and that path has the file
-C<cookie.pem>, the name C</foo/bar/cookie.pem> will be returned.
+For C<file:> URIs that are used without the explicit scheme, the
+returned name will be the path of each object, so if C</foo/bar> was
+given and that path has the file C<cookie.pem>, the name
+C</foo/bar/cookie.pem> will be returned.
 
 At the discretion of the loader that was used to get these names, an
 extra description may be attached as well.
 
 At the discretion of the loader that was used to get these names, an
 extra description may be attached as well.
index 1a2626c94413be710fafe0c2da64e6a3f51a6883..0bc6d5ccfd87ceb3a92501300f42b85e208c0c1e 100644 (file)
@@ -99,26 +99,14 @@ OSSL_STORE_register_loader().
 
 =head1 NOTES
 
 
 =head1 NOTES
 
-When unsure whether a given string contains a simple file or directory
-reference, or if it's a full blown URI, the question is how to figure
-that out.
-One way is to try OSSL_STORE_open_file() and if that fails, try
-OSSL_STORE_open().
-The other way is the other way around.
-Either way you choose, there are corner cases,
-F<file:/foo/bar/cookie.txt> might very will be a simple file reference
-on a system that supports the notion of volumes.
-
-This manual won't tell you which way is better, that's up to each
-application developer to decide on their own.
-However, there are some tools that can be used together with
+A string without a scheme prefix (that is, a non-URI string) is
+implicitly interpreted as using the F<file:> scheme.
+
+There are some tools that can be used together with
 OSSL_STORE_open() to determine if any failure is caused by an unparsable
 URI, or if it's a different error (such as memory allocation
 failures); if the URI was parsable but the scheme unregistered, the
 top error will have the reason C<OSSL_STORE_R_UNREGISTERED_SCHEME>.
 OSSL_STORE_open() to determine if any failure is caused by an unparsable
 URI, or if it's a different error (such as memory allocation
 failures); if the URI was parsable but the scheme unregistered, the
 top error will have the reason C<OSSL_STORE_R_UNREGISTERED_SCHEME>.
-If you decide to use OSSL_STORE_open() with OSSL_STORE_open_file() as a
-fallback, those reasons can be good tools to decide if the fallback
-should be taken or not.
 
 =head1 RETURN VALUES
 
 
 =head1 RETURN VALUES
 
index 59cfc7cea71f273914e788603f35ddf8a8d2e25e..cda5ce47d6e0facd087e2e8b67cb0a4512b205ff 100644 (file)
@@ -59,10 +59,6 @@ only).
 
 =head2 A generic call
 
 
 =head2 A generic call
 
- /*
-  * There is also a OSSL_STORE_open_file() that can be used for file paths
-  * that can't be represented as URIs, such as Windows backslashes
-  */
  OSSL_STORE_CTX *ctx = OSSL_STORE_open("file:/foo/bar/data.pem");
 
  /*
  OSSL_STORE_CTX *ctx = OSSL_STORE_open("file:/foo/bar/data.pem");
 
  /*
index c6948f223d09f6cfdd29c4e82ea397bafda6b283..43cf2031e79aaddd1ef9b48a95ac07eeb3aa3ff8 100644 (file)
@@ -114,8 +114,7 @@ int OSSL_STORE_close(OSSL_STORE_CTX *ctx);
 
 /*
  * Functions to generate OSSL_STORE_INFOs, one function for each type we
 
 /*
  * Functions to generate OSSL_STORE_INFOs, one function for each type we
- * support having in them.  Along with each of them, one macro that
- * can be used to determine what types are supported.
+ * support having in them, as well as a generic constructor.
  *
  * In all cases, ownership of the object is transfered to the OSSL_STORE_INFO
  * and will therefore be freed when the OSSL_STORE_INFO is freed.
  *
  * In all cases, ownership of the object is transfered to the OSSL_STORE_INFO
  * and will therefore be freed when the OSSL_STORE_INFO is freed.