Secure-by-default APIs

[Vlad Dascalu]

> If some methods need more detailed documentation, then fix the documentation.
> [...]
> I disagree. They are supposed to know.

Gerv wasn't talking about fixing docs or what people are supposed to
know (or do).
He was proposing a solution for fixing a development *process* (as a
result of doing research on previous security incidents related to
Bugzilla).

> I will veto the kind of changes you have in mind

It's too early to veto things when the discussion didn't even happen yet.
Gerv's proposals have obviously room for improvement, such as your
suggestion about the case when the user which receives the mail is
relevant for permission-checking.
But his fundamentals are sound - we have a pattern in security flaws
due to bad template filtering, and just like we audit the FILTER
directives, we should brainstorm on fixing this as well.

> Renaming methods used for
> ages is just going to break existing extensions and confuse developers
> used to them.

Maybe an annotation in a comment right above the function definition,
that could be checked by a simple static code analyzer tool?

Examples:

# Security: all
(the function following this line returns all the information,
unfiltered for security access)

# Security: $user (1)
(the function following this line returns the information visible for
user $user given as parameter 1 to the function)

Best regards,
Vlad