Print this page
6862532 "cryptoadm: failed to parse configuration" error
6353443 domestic (crypt) source build leaves stuff it shouldn't
6818180 mac(1) printed "invalid key" error message when user input an invalid passphrase
| Split |
Close |
| Expand all |
| Collapse all |
--- old/usr/src/lib/libgss/README.spi
+++ new/usr/src/lib/libgss/README.spi
1 1
2 2 CDDL HEADER START
3 3
4 4 The contents of this file are subject to the terms of the
5 - Common Development and Distribution License, Version 1.0 only
6 - (the "License"). You may not use this file except in compliance
7 - with the License.
5 + Common Development and Distribution License (the "License").
6 + You may not use this file except in compliance with the License.
8 7
9 8 You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
10 9 or http://www.opensolaris.org/os/licensing.
11 10 See the License for the specific language governing permissions
12 11 and limitations under the License.
13 12
14 13 When distributing Covered Code, include this CDDL HEADER in each
15 14 file and include the License file at usr/src/OPENSOLARIS.LICENSE.
16 15 If applicable, add the following below this CDDL HEADER, with the
17 16 fields enclosed by brackets "[]" replaced with your own identifying
18 17 information: Portions Copyright [yyyy] [name of copyright owner]
19 18
20 19 CDDL HEADER END
21 20
22 - Copyright 2005 Sun Microsystems, Inc. All rights reserved.
21 + Copyright 2010 Sun Microsystems, Inc. All rights reserved.
23 22 Use is subject to license terms.
24 23
25 -#ident "%Z%%M% %I% %E% SMI"
26 24
27 -
28 25 The Service Provider Interface for libgss and its Mechanisms
29 26 ------------------------------------------------------------
30 27
31 -/* CRYPT DELETE START */
32 -
33 28 1. The libgss SPI upto 11/2004
34 29
35 30 Prior to PSARC 2004/810 the libgss SPI consisted of a function
36 31 provided by each mechanism whose return value is a pointer to a
37 32 structure full of references to the mechanism's entry points
38 33 (hereinafter: methods).
39 34
40 35 This structure does not include any hooks for versioning, which
41 36 means that additions of any mechanism methods at micro/patch
42 37 releases require patching libgss.so.1 and all the GSS mechanisms
43 38 shipped with Solaris (Kerberos V, DH, SPNEGO).
44 39
45 40 2. The libgss SPI after PSARC 2004/810
46 41
47 42 In order to avoid changing the gss_config struct and patching all
48 43 three mechanisms (four, if the dummy mech counts) and libgss
49 44 together and in anticipation of a cleaner SPI in the future (see
50 45 next section) the SPI after PSARC 2004/810 will be as before but
51 46 supplemented as follows:
52 47
53 48 - any new SPI mechanism methods will NOT be placed in gss_config,
54 49 instead there is a new gss_config_ext structure, which is to be
55 50 used _only_ by libgss (to avoid struct versioning and/or patch
56 51 issues), which should be extended to have a pointer to the new
57 52 method;
58 53
59 54 - there is a new libgss function, __gss_get_mechanism_ext(), which
60 55 is used to get at the gss_config_ext for a mechanism;
61 56
62 57 - __gss_get_mechanism_ext() uses dlsym() to build the
63 58 gss_config_ext struct for the mech by individually loading each
64 59 and every mechanism method that isn't part of the old gss_config
65 60 struct -- this happens only once per-method, of course; the
66 61 result is cached.
67 62
68 63 The symbol names that are dlsym()ed are of the form gssspi_* and
69 64 correspond to gss_*; e.g., gssspi_acquire_cred_with_password().
70 65
71 66 New methods also have a corresponding typedef named
72 67 <gss_func>_sfct -- the 's' in 'sfct' is for "SPI" and the 'fct'
73 68 is for "function." This is used to keep cast expressions short.
74 69
75 70 3. The Future libgss SPI
76 71
77 72 Once the Solaris krb5 source is resync'ed with MIT krb5 1.4 there
78 73 will be no further need for the 'void *context' argument to all the
79 74 libgss mechanisms' methods.
80 75
81 76 At that point it will be possible to remove this 'void *context'
82 77 argument from all the libgss SPI function prototypes, the main
83 78 result of which will be that the mechanisms' methods will then have
84 79 the same function signature as the corresponding GSS-API functions.
85 80
86 81 We can then rename all mechanisms' methods from <mech>_<gss-func> to
87 82 <gss-func>. The corresponding typedefs will be renamed to
88 83 <gss-func>_fct.
89 84
90 85 The SPI, then, will be almost exactly the same as the API.
91 86
92 87 There will be some minor differences, primarily that some API
93 88 functions won't have a corresponding SPI method, such as
94 89 gss_release_buffer(3GSS), for example.
95 90
96 91 Some time later we may open the SPI to third party implementors;
97 92 this could be particularly useful as a way to get access to 3rd
98 93 party implementations of SPKM and LIPKEY (assuming any ever exist --
99 94 SPKM's is a very problematic specification).
100 95
101 96 Third party mechanisms should just export all the symbols for the
102 97 GSS-API functions, like MIT krb5 does, but functions which libgss
103 98 won't call (e.g., gss_release_buffer(3GSS)) should either not be
104 99 implemented or should be weak symbols.
105 100
106 101 Solaris native mechanisms may still provide the mechanism method
107 102 registration function as usual for optimization purposes -- to
|
↓ open down ↓ |
65 lines elided |
↑ open up ↑ |
108 103 reduce the number of calls to dlsym().
109 104
110 105 Mechanisms that do not provide the old method registration function
111 106 will be loaded as follows:
112 107
113 108 - libgss will look for and find the mechanism's
114 109 GSS_Indicate_mechs() method and will call it to discover the
115 110 mechanism provider's mechanism OIDs.
116 111
117 112 - libgss will dlsym() each mechanism provider SPI method.
118 -
119 -/* CRYPT DELETE END */
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX