[TYPO3-ect] TER clean up actions

[Michael]

On 18/02/12 22:31, Jigal van Hemert wrote:

> The text below will be put in the ECT wiki too. It outlines the steps we
> need to take, technical considerations, time frame, etc.

great concept document! :-)

> 7.2 Difference between 'insecure' and 'outdated'

If we use the "reviewstate" value for classifying 'insecure' (-1) *and*
'outdated' extensions (-2), this would mean, we can not distinguish
between both states.

It is possible that an extension is "outdated" but not "insecure".
It is also possible that an extension is "outdated" and "insecure".

Both cases would show "reviewstate = -2" (outdated).

Assuming the Security Team would identify a security issue in an
extension, which is not outdated yet, reviewstate would be -1. Some
months later, the extension becomes outdated and a script would
overwrite this state by the value "-2". From this time on, it is not
possible to say, if the extension has ever been classified as insecure
or not, which is (from my perspective) an important factor for an
integrator to make a decision to use (or continue using) the extension
or not. Under certain circumstances it could be legitimate to use an
outdated/unmaintained extension - but an insecure extension is a no-go!

What I mean is: we would loose an important information.

Here is a suggestion to address this issue: how about using the binary
system as the "reviewstate" value? This makes the logic a little bit
more complicated but gives much more flexibility.

-1 = insecure
-2 = outdated
-4 = another classification 1
-8 = another classification 2
-16 = another classification 3
etc.

reviewstate = <sum of classifications>

If reviewstate = -1, extension is "insecure" (and insecure only).
If reviewstate = -2, extension is "outdated" (and outdated only).
If reviewstate = -3, extension is "insecure" and "outdated" (-1 + -2 = -3)
If reviewstate = -10, extension is "outdated" and "another
classification 2" (-2 + -8 = -10)

and so on.

This would allow us to extend the "state" of extensions in the future
(in theory without limits) and this would also allow the Security Team
to exclude extensions with negative reviewstate values.

Cheers
Michael