Include metadata about the security coverage opt-in in the 'extra' attribute of composer.json files

Interesting idea, i could add support for it in the composer_deploy. How does update.module deal with this change?

Thanks, looks like a good start.

$project_wrapper->field_security_advisory_coverage->value() is project-wide coverage. Per-release, we also want to check:

• Is it a full version?
• Has the maintainer marked it as supported on admin releases for the project?

http://cgit.drupalcode.org/drupalorg/tree/drupalorg/drupalorg.module#n4954 is where this is done for update status XML. (If the line number changes, it is in drupalorg_project_release_xml_release_alter(), after // Add security advisory coverage..) That could be pulled out into a generally-useful function, and get the strings matching the update status plan.

Im going to go ahead and add what is essentially @larowans patch from #3, except modified to be the release specific values:

$security_coverage = $release_wrapper->field_release_project->field_security_advisory_coverage->value() === 'covered';
  $package_data['packages'][$package_name][$version]['extra']['drupal']['security-coverage'] = $security_coverage;

I dont think that project composer should know about any business logic about what constitutes covered or not. If that field is not supposed to contain "covered" because the project is either not a full version or it's been marked as unsupported then we need to make sure that whatever code is responsible for 'unsupporting' a module also removes coverage from the field.

The “covered” for SAs value is per-project, it isn’t the only factor per-release. A covered project might have a stable version, but that doesn’t mean any of the pre-release versions are covered. Or a “covered” project might not have any stable version (yet).

Okay, so we've refactored the covered status so that we can gather that information per release. The composer facade has been rebuilt to include this data, and it is now gathering that data and returning it in the extra field as both a 'status' and a 'message':

There are three statuses: "covered", "not-covered", and "revoked"

"extra" : {
               "drupal" : {
                  "version" : "7.x-1.11",
                  "datestamp" : "1479787142",
                  "security-coverage" : {
                     "message" : "Covered by Drupal's security advisory policy",
                     "status" : "covered"
                  }
               },
               "branch-alias" : {
                  "dev-1.x" : "1.x-dev"
               }
            },

"extra" : {
               "drupal" : {
                  "datestamp" : "1502252151",
                  "version" : "8.x-4.0-alpha2",
                  "security-coverage" : {
                     "status" : "not-covered",
                     "message" : "Alpha releases are not covered by Drupal security advisories."
                  }
               },
               "branch-alias" : {
                  "dev-4.x" : "4.x-dev"
               }
            },

"extra" : {
               "branch-alias" : {
                  "dev-1.x" : "1.x-dev"
               },
               "drupal" : {
                  "version" : "7.x-1.0",
                  "datestamp" : "1391193505",
                  "security-coverage" : {
                     "message" : "Project has been unsupported by the Drupal Security Team",
                     "status" : "revoked"
                  }
               }
            },

The message is an explanatory text field, and its contents may change, so do not write any logic based off of the message contents as they may change.

This data only reflects the security team's policy for a particular release, and in no way indicates the actual security or insecurity of a particular module.

https://www.drupal.org/project/drupal_security_warning now makes use of this.