| /openbmc/linux/crypto/asymmetric_keys/ |
| H A D | restrict.c | diff aaf66c883813f0078e3dafe7d20d1461321ac14f Tue Aug 30 13:33:13 CDT 2016 Mat Martineau <mathew.j.martineau@linux.intel.com> KEYS: Split role of the keyring pointer for keyring restrict functions
The first argument to the restrict_link_func_t functions was a keyring
pointer. These functions are called by the key subsystem with this
argument set to the destination keyring, but restrict_link_by_signature
expects a pointer to the relevant trusted keyring.
Restrict functions may need something other than a single struct key
pointer to allow or reject key linkage, so the data used to make that
decision (such as the trust keyring) is moved to a new, fourth
argument. The first argument is now always the destination keyring.
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
|
| /openbmc/linux/include/keys/ |
| H A D | system_keyring.h | diff aaf66c883813f0078e3dafe7d20d1461321ac14f Tue Aug 30 13:33:13 CDT 2016 Mat Martineau <mathew.j.martineau@linux.intel.com> KEYS: Split role of the keyring pointer for keyring restrict functions
The first argument to the restrict_link_func_t functions was a keyring
pointer. These functions are called by the key subsystem with this
argument set to the destination keyring, but restrict_link_by_signature
expects a pointer to the relevant trusted keyring.
Restrict functions may need something other than a single struct key
pointer to allow or reject key linkage, so the data used to make that
decision (such as the trust keyring) is moved to a new, fourth
argument. The first argument is now always the destination keyring.
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
|
| /openbmc/linux/certs/ |
| H A D | system_keyring.c | diff aaf66c883813f0078e3dafe7d20d1461321ac14f Tue Aug 30 13:33:13 CDT 2016 Mat Martineau <mathew.j.martineau@linux.intel.com> KEYS: Split role of the keyring pointer for keyring restrict functions
The first argument to the restrict_link_func_t functions was a keyring
pointer. These functions are called by the key subsystem with this
argument set to the destination keyring, but restrict_link_by_signature
expects a pointer to the relevant trusted keyring.
Restrict functions may need something other than a single struct key
pointer to allow or reject key linkage, so the data used to make that
decision (such as the trust keyring) is moved to a new, fourth
argument. The first argument is now always the destination keyring.
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
|
| /openbmc/linux/include/crypto/ |
| H A D | public_key.h | diff aaf66c883813f0078e3dafe7d20d1461321ac14f Tue Aug 30 13:33:13 CDT 2016 Mat Martineau <mathew.j.martineau@linux.intel.com> KEYS: Split role of the keyring pointer for keyring restrict functions
The first argument to the restrict_link_func_t functions was a keyring
pointer. These functions are called by the key subsystem with this
argument set to the destination keyring, but restrict_link_by_signature
expects a pointer to the relevant trusted keyring.
Restrict functions may need something other than a single struct key
pointer to allow or reject key linkage, so the data used to make that
decision (such as the trust keyring) is moved to a new, fourth
argument. The first argument is now always the destination keyring.
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
|
| /openbmc/linux/include/linux/ |
| H A D | key.h | diff aaf66c883813f0078e3dafe7d20d1461321ac14f Tue Aug 30 13:33:13 CDT 2016 Mat Martineau <mathew.j.martineau@linux.intel.com> KEYS: Split role of the keyring pointer for keyring restrict functions
The first argument to the restrict_link_func_t functions was a keyring
pointer. These functions are called by the key subsystem with this
argument set to the destination keyring, but restrict_link_by_signature
expects a pointer to the relevant trusted keyring.
Restrict functions may need something other than a single struct key
pointer to allow or reject key linkage, so the data used to make that
decision (such as the trust keyring) is moved to a new, fourth
argument. The first argument is now always the destination keyring.
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
|
| /openbmc/linux/security/keys/ |
| H A D | key.c | diff aaf66c883813f0078e3dafe7d20d1461321ac14f Tue Aug 30 13:33:13 CDT 2016 Mat Martineau <mathew.j.martineau@linux.intel.com> KEYS: Split role of the keyring pointer for keyring restrict functions
The first argument to the restrict_link_func_t functions was a keyring
pointer. These functions are called by the key subsystem with this
argument set to the destination keyring, but restrict_link_by_signature
expects a pointer to the relevant trusted keyring.
Restrict functions may need something other than a single struct key
pointer to allow or reject key linkage, so the data used to make that
decision (such as the trust keyring) is moved to a new, fourth
argument. The first argument is now always the destination keyring.
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
|
| H A D | keyring.c | diff aaf66c883813f0078e3dafe7d20d1461321ac14f Tue Aug 30 13:33:13 CDT 2016 Mat Martineau <mathew.j.martineau@linux.intel.com> KEYS: Split role of the keyring pointer for keyring restrict functions
The first argument to the restrict_link_func_t functions was a keyring
pointer. These functions are called by the key subsystem with this
argument set to the destination keyring, but restrict_link_by_signature
expects a pointer to the relevant trusted keyring.
Restrict functions may need something other than a single struct key
pointer to allow or reject key linkage, so the data used to make that
decision (such as the trust keyring) is moved to a new, fourth
argument. The first argument is now always the destination keyring.
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
|