Re: what about an special QA package priority?
Hi,
On Tue, May 20, 2008 at 05:21:07PM -0300, Luciano Bello wrote:
> Hi list,
> I was thinking about the Debian/OpenSSL debacle. Clearly it not easy to
> manage a hard meticulous QA process in all packages. In the other hand, there
> are packages more critical than others, which are more delicate to security.
> Sometimes, those packages have different priorities in the policy meaning.
> Maybe we can implement this as an Optional header in the control.
> The point is: if we can create critical QA category for delicate packages in
> the security sense we can have mandatory QA requirement.
It will be hard to define this list of "delicate" packages.
For example, I'm not sure I would have put openssl in the list a few weeks
ago.
I would have first think about setuid/setgid programs, servers, with high
popcon packages first.
> For example:
> - It should be checked with debugging tools (like valgrind :P)
It's not always needed.
It may show some bad practices, but having a command line utility which
allocate some resources (memory, syslog, files, PAM, ...) and does not
free them directly (i.e. it relies on system to do the cleanup on exit) is
not an issue.
If you want to improve quality, you can also recommend using checkers
(splint, security checkers), code metrics tools (e.g. pmccabe), unit tests
It might be good to recommend these tools (including valgrind), and to
provide some web services to provide the reports of these tools (IIRC,
there is already some servers with rats reports; for other checkers,
formalizing some debian/rules rules could help to to start the checkers).
But I don't think it will be possible to have them mandatory.
> - It should maintained by a team
We will only be able to advertise that these packages need comaintainers.
Or is there a defined response for the "delicate" packages with no
teams/comaintainers.
> - It should a public VCS
> - Its patches should be sign-off by reviewers (Raphael Hertzog (hertzog@)
> proposed something like this)
ACK for both.
> You can extend or reduce this list. We can discuss about the implementation.
> But I mainly want to know your opinion.
I really appreciate the idea, but it might be hard to implement.
--
Nekral
Reply to: