Difference between revisions of "Projects/Master Key DAL Redesign"
From K5Wiki
< Projects
(New page: {{project-early}} This project has been split out of Projects/Database Access Layer cleanup. ==Background== As of krb5 1.8, the DAL interface for master keys was very confusing. So...) |
(→Goals) |
||
| Line 9: | Line 9: | ||
==Goals== |
==Goals== |
||
| − | This project is to create a new design for master key encryption. Specific desirables include: |
+ | This project is to create a new design for the DAL access routines related to master key encryption. Specific desirables include: |
* Modules which don't use master key encryption can simply decline to implement the relevant interfaces, rather than having to fake them out. |
* Modules which don't use master key encryption can simply decline to implement the relevant interfaces, rather than having to fake them out. |
||
Latest revision as of 05:51, 20 July 2010
This is an early stage project for MIT Kerberos. It is being fleshed out by its proponents. Feel free to help flesh out the details of this project. After the project is ready, it will be presented for review and approval.
This project has been split out of Projects/Database Access Layer cleanup.
Background
As of krb5 1.8, the DAL interface for master keys was very confusing. Some of the most glaring inefficiencies have been removed as part of simple cleanups, but the interface remains inconvenient for modules which do not implement master key encryption.
Goals
This project is to create a new design for the DAL access routines related to master key encryption. Specific desirables include:
- Modules which don't use master key encryption can simply decline to implement the relevant interfaces, rather than having to fake them out.
- Memory allocated by fetch_master_key_list (or equivalent) should be freed inside the module, not by the caller.
- Eliminate set_master_key_list and get_master_key_list, making the caller responsible for caching those.
