Change audit.ignore behavior before 2.6.0

[mxr576]

Closes #11604

[mxr576]

Since we may have the reason for ignoring a given security advisory, I'd consider adding that to the output (also to the JSON above). What do you think?

[Seldaek]

Yes makes sense to me. It probably needs to be highlighted like <warning>Ignored: $reason</>

And for the table output add an Ignore column with Yes/empty and no reason to keep it small perhaps, because otherwise the table width will blow up

[mxr576]

Yes makes sense to me. It probably needs to be highlighted like Ignored: $reason</>

Just to be clear, do you mean display all ignore reasons as console message unless the output format is JSON?

Speaking of JSON, partially because the JSON output leverages that advisories are JSON serializable, should I just introduce a new class IgnoredSecurityAdvisory extends SecurityAdvisory{} that can also hold the reason?

[Seldaek]

Yeah I was also wondering how to best achieve this. For sure for JSON it would be easier with a subclass..

For the plain text output I meant it probably should go here https://github.com/composer/composer/blob/main/src/Composer/Advisory/Auditor.php#L207 as a new line with a so it is highlighted as being ignored.

[mxr576]

It seems to me that wrapping text in tables works OOTB, so is there any need for workarounds like...?

                $ignoreReason = '';
                if ($advisory instanceof IgnoredSecurityAdvisory && $advisory->ignoreReason !== NULL) {
                    if (strlen($advisory->ignoreReason) > 80) {
                        $ignoreReason = substr($advisory->ignoreReason, 0, 77) . '...';
                    }
                    else {
                        $ignoreReason = $advisory->ignoreReason;
                    }
                }

[mxr576]

A better example

[mxr576]

https://github.com/composer/composer/compare/e570c5a1b9eaf67076c2336651fc6c4adac35576..708db5e9a4a47135753f938e87b3ba5646c4e1d0

[stof]

should we create an object that extends SecurityAdvisory in which you copy all the metadata or should we rather have a IgnoredSecurityAdvisory that would take a SecurityAdvisory|PartialSecurityAdvisory as argument and implements its jsonSerialize method by adding an ignore_reason key in the array returned by the delegated call ?

[mxr576]

These were the options that I also considered, the solution in the PR just felt better, even if it is "ugly" a bit.

[fredden]

Perhaps IgnoredSecurityAdvisory could be a proxy class or have a factory method which takes in a SecurityAdvisory object. That'd make the code here much cleaner.

$advisory = IgnoredSecurityAdvisory::create($advisory, $ignoreReason); or $advisory = new IgnoredSecurityAdvisory($advisory, $ignoreReason);

[mxr576]

IgnoredSecurityAdvisory::createFromSecurityAdvisory($advisory I would have gone with this approach by default, but since everything in public on these objects (as public properties) this approach just moves copying object data to somewhere else. Would that have a real added value? In this case, should I make the constructor of IgnoredSecurityAdvisory private so it could be only constructed from a SecurityAdvisory from now?

[fredden]

Perhaps IgnoredSecurityAdvisory could be a proxy class or have a factory method which takes in a SecurityAdvisory object. That'd make the code here much cleaner.

$advisory = IgnoredSecurityAdvisory::create($advisory, $ignoreReason); or $advisory = new IgnoredSecurityAdvisory($advisory, $ignoreReason);

[fredden]

I thought that the reason was a required field.

Edit: I've now seen that there are two accepted values and only one has the 'reason' field. I'd vote that a reason should always be provided/required.

[mxr576]

Actually I decided to give more freedom to developers... so it cannot be mandatory.
https://github.com/composer/composer/pull/11605/files#diff-89992649ff6652d737d4dac645fbbac6ceeb112ab29010d0eaba3b42c658dc7eR112-R132

[Seldaek]

@mxr576 please don't change anything anymore, I'm editing a couple things here and then merging :) thanks a lot for the quick work here!

[Seldaek]

I think it looks good now but I perhaps broke some tests.. anyway bedtime, will wrap up tomorrow.

[mxr576]

@mxr576 please don't change anything anymore, I'm editing a couple things here and then merging :) thanks a lot for the quick work here!

Roger! 🙂 Time well spent! 🍻

[Seldaek]

Ok looking good, thanks again.