Hi Marton - I don't think there is any denying that it would be great to have such documentation for all of those reasons. If it is a natural extension of getting the checklist information as an assertion of security state when merging then we can certainly include it.
I think that backfilling all such information across the project is a different topic altogether and wouldn't want to expand the scope of this discussion in that direction. Thanks for the great thoughts on this! thanks, --larry On Sat, Oct 21, 2017 at 3:00 AM, Elek, Marton <h...@anzix.net> wrote: > > > On 10/21/2017 02:41 AM, larry mccay wrote: > >> >> "We might want to start a security section for Hadoop wiki for each of the >>> services and components. >>> This helps to track what has been completed." >>> >> >> Do you mean to keep the audit checklist for each service and component >> there? >> Interesting idea, I wonder what sort of maintenance that implies and >> whether we want to take on that burden even though it would be great >> information to have for future reviewers. >> > > I think we should care about the maintenance of the documentation anyway. > We also need to maintain all the other documentations. I think it could be > even part of the generated docs and not the wiki. > > I also suggest to fill this list about the current trunk/3.0 as a first > step. > > 1. It would be a very usefull documentation for the end-users (some > answers could link the existing documentation, it exists, but I am not sure > if all the answers are in the current documentation.) > > 2. It would be a good example who the questions could be answered. > > 3. It would help to check, if something is missing from the list. > > 4. There are future branches where some of the components are not touched. > For example, no web ui or no REST service. A prefilled list could help to > check if the branch doesn't break any old security functionality on trunk. > > 5. It helps to document the security features in one place. If we have a > list for the existing functionality in the same format, it would be easy to > merge the new documentation of the new features as they will be reported in > the same form. (So it won't be so hard to maintain the list...). > > Marton >
