Closed llaville closed 1 year ago
Hi @llaville!
I do remember your work on this, and had it in the back of my mind ever since then ;) Recently there's been some work on SBOM which in my mind is a perfect fit between what you're doing, and providing an internationally supported and understood format.
I briefly remember https://github.com/CycloneDX/cyclonedx-php-composer but ideally, after talking with Sebastian Bergmann, I think it is kind of expected of Composer to provide this at some point.
I unfortunately could not dig into any of this any further. I do not know if there is any alternative to cycloneDX, how it is expected to be shipped & co. Also even with it, I think it would be interesting to have a human readable format like you are proposing. But maybe this one can be based on the SBOM as the source of truth instead?
I am also not sure if this should be in the Metadata
section and instead maybe it could be an entirely new section.
WDYT?
Hello ThΓ©o,
Thanks for your feedback and especially to point to me the SBOM standard solution. If it's related to my work on a PHAR manifest, I think it's could be pretty cool to have a possibility to embed such results into a PHAR. I don't think it may be too much difficult to have a bridge with https://github.com/CycloneDX/cyclonedx-php-library and my fork of BOX v4 (https://github.com/llaville/box-manifest). I'll investigate later, when I'll have finished the major rewrites of https://github.com/overtrue/phplint v9.0
But, this feature report is not to talk about a manifest or SBOM or something equivalent. No, this report is just to add a little version about the product maker (BOX v4), as an indicator like API version.
Always ready to heard your proposals about BOX. I like this project.
As my works on PHPLint 9.0 is over, I'll be able now to work on a version of BOX Manifest that support SBOM format. Keep an eye open, solution will come in next days ...
@theofidry Integration of CycloneDX SBOM feature is very easy. Code is ready for preview: Need more tests and polish for a final version !!!
An operational prototype is already available (see commit https://github.com/llaville/box-manifest/commit/75fd43731c6b5722e8aff5ba5b45cb4fe7d8d53b) on my repository (sbom
branch).
IMPORTANT notes:
If you want to give it a try for another project than BOX-Manifest itself, don't forget to provide --boostrap vendor/autoload.php
(to load your project autoloader) on box compile invocation.
But If you review code of static manifest builder calls, a new specification may be include easily : https://github.com/llaville/box-manifest/blob/sbom/src/Composer/ManifestFactory.php#L97-L105
Here are some examples of SBOM manifest production:
With "metadata": "Bartlett\\BoxManifest\\Composer\\ManifestFactory::toSbomXml1dot3"
setting in your box.json
config file
With "metadata": "Bartlett\\BoxManifest\\Composer\\ManifestFactory::toSbomJson1dot3"
setting in your box.json
config file
To validate contents of SBOM generated by CycloneDX, use the https://github.com/CycloneDX/cyclonedx-cli project.
With Docker version:
REPOSITORY TAG IMAGE ID CREATED SIZE
cyclonedx/cyclonedx-cli latest 9548cf5241e3 4 months ago 151MB
Run following command:
docker run --rm --user $(id -u):$(id -g) --mount type=bind,source=$PWD,target=/tmp -w /tmp cyclonedx/cyclonedx-cli validate --input-file sbom.xml
Change input file sbom.xml
by sbom.json
depending of format generated
And you will get expected result : BOM validated successfully.
@sebastianbergmann FYI : this purpose may interrest you even if I don't consider this as a PHPUnit issue. (I use actually the latest version 10.0.7)
The PHPUnit SBOM generation script => https://github.com/sebastianbergmann/phpunit/blob/10.0.7/build/scripts/phar-manifest.php#L54 use the CycloneDX solution (specification 1.4)
But it seems that the contents generated do not pass validation : at least with https://github.com/CycloneDX/cyclonedx-cli#validate-command (that support all specifications)
Here is my try :
With Docker image
REPOSITORY TAG DIGEST IMAGE ID CREATED SIZE
cyclonedx/cyclonedx-cli latest sha256:c7d71852320da2d24fdc3f3dea8895b562e411cce43abb4c6817dc155bf54689 9548cf5241e3 4 months ago 151MB
phpunit-10.0.7.phar --sbom > phpunit-10.0.7-sbom.xml
docker run --rm --user $(id -u):$(id -g) --mount type=bind,source=$PWD,target=/tmp -w /tmp cyclonedx/cyclonedx-cli validate --input-file phpunit-10.0.7-sbom.xml
Prints
Unable to validate against any XML schemas.
BOM is not valid.
This is not a useful and actionable error:
Unable to validate against any XML schemas. BOM is not valid.
Trying to use xmllint
to validate PHPUnit's SBOM against the XSD fails with this error:
$ xmllint --schema cyclonedx-1.4.xsd sbom.xml --noout
error : Unknown IO error
warning: failed to load external entity "http://cyclonedx.org/schema/spdx"
cyclonedx-1.4.xsd:27: element import: Schemas parser warning : Element '{http://www.w3.org/2001/XMLSchema}import': Failed to locate a schema at location 'http://cyclonedx.org/schema/spdx'. Skipping the import.
cyclonedx-1.4.xsd:444: element element: Schemas parser error : element decl. '{http://cyclonedx.org/schema/bom/1.4}id', attribute 'type': The QName value '{http://cyclonedx.org/schema/spdx}licenseId' does not resolve to a(n) type definition.
WXS schema cyclonedx-1.4.xsd failed to compile
Not sure what is going on here. It would be helful to know what is actually wrong. But this should not be discussed here. I have opened https://github.com/sebastianbergmann/phpunit/issues/5186 for this. Thank you for bringing this to my attention.
@theofidry Code is now completed. Tell me if you think it's acceptable, or if you want more !
Chunk of box compile
command output with "metadata": "Bartlett\\BoxManifest\\Composer\\ManifestFactory::toSbomJson1dot3"
setting on Box-Manifest project itself
? Setting metadata
- Using composer.json : /shared/backups/bartlett/box-manifest/composer.json
- Using composer.lock : /shared/backups/bartlett/box-manifest/composer.lock
- {
"$schema": "http://cyclonedx.org/schema/bom-1.3.schema.json",
"bomFormat": "CycloneDX",
"specVersion": "1.3",
"version": 1,
"metadata": {
"tools": [
{
"vendor": "box-project",
"name": "box",
"version": "4.2.0@afc3a47"
}
],
"component": {
"bom-ref": "BomRef.63e56378e5b904.73643295",
"type": "application",
"name": "box-manifest",
"version": "2.x-dev@781abd9",
"group": "bartlett",
"description": "Create a manifest to a PHP Archive (PHAR) for the BOX project (https://github.com/box-project/box)",
"licenses": [
{
"license": {
"id": "MIT"
}
}
],
"purl": "pkg:composer/bartlett/box-manifest@2.x-dev%40781abd9"
}
},
"components": [
{
"bom-ref": "BomRef.63e56378e5a414.90121867",
"type": "library",
"name": "amp",
"version": "v2.6.2",
"group": "amphp",
"purl": "pkg:composer/amphp/amp@v2.6.2"
},
Caught up with it!
So ideally I would like the SBOM to be handled by Composer itself, but I don't see any plan for that now so I'm happy to integrate it in Box.
I think however I would prefer to see it as a regular file rather than metadata. If then wouldn't need the metadata change and also could just be a regular setting.
For sure the Info command would need to be enriched to check for it and show it, the same way I would like it to give more info regarding the requirement checker.
@theofidry I think cdxgen
of CylconeDX may require your attention, because it may be generate BOM 1.4 XML or JSON results of any PHP project, even if there are still some minor issues (I've already reported in https://github.com/CycloneDX/cdxgen/issues/236)
re: https://github.com/box-project/box/issues/841#issuecomment-1424942646
So ideally I would like the SBOM to be handled by Composer itself [...]
Have you tried the composer plugin cyclonedx/cyclonedx-php-composer
? It utilizes composer itself to gather the evidences for creating CycloneDX.
Unlike cdxgen
and others, it does not need NodeJS or python installed or some other binary downloaded.
Hello @jkowalleck
As you've perharps noticed, I've already created a solution (https://github.com/llaville/box-manifest/blob/sbom/src/Composer/Manifest/SbomManifestBuilder.php) based on the cyclonedx/cyclonedx-library
.
Box-Manisfest was born for historical reason, and even if it's a fork/patched version of main BOX project, I'm happy of results produced. I regret just that the cyclonedx php lib does not support spec 1.4 ;-)
Was rereffing to https://github.com/box-project/box/issues/841#issuecomment-1424942646
the manifesto you came up with is better for the job here, since not all phars are composer-based.
What features of CycloneDX 1.4 do you actually need?
There are not that many changes from 1.3 to 1.4 - just externalReferences
, releaseNotes
, some annotation
and the big block for vulnerability-disclosure/vulnerabilities
.
@llaville , please let me know, or feature-request them for the upcoming cyclonedx/cyclonedx-library@v2
@jkowalleck I don't have any new feature requests for v2. Just waiting stable release :) And when I'll have more free time, my manifest builder should be able to use either stable spec 1.3, and upcoming 1.4 with a bridge !
@theofidry I've just created a prototype of a new Manifest
command that may be able to generate any manifest results as implementations available.
Related to my question https://github.com/theofidry/console/issues/145, I don't know how to lazy load any new command (e.g in the contrib
namespace) without to alter the https://github.com/box-project/box/blob/4.3.7/src/Console/Application.php#L78-L91
My new manifest command invocation will look like php -d phar.readonly=0 bin/manifest contrib:add-manifest
to print result on standard output (by default), but may be also able to write directly to a file that can be include later when we try to bin/box compile
any project.
PS: bin/manifest
is same as bin/box
just for testing purpose.
contrib:add-manifest
command is able just right now to generate results in the same format as https://github.com/llaville/box-manifest did, including SBOM format (Spec 1.3) and soon (Spec 1.4)
We are closed to realize a dream to add finally the manifest feature in official Box project.
That will allow to me to let down maintaince of my bartlett/box-manifest
project.
@theofidry Meanwhile your feedback, I'll release soon the last major release 3..0.0 of bartlett/box-manifest
that will support this new command rather than patching the humbug/box
like I did in past with help of cweagans/composer-patches
Final major version 3.0
of bartlett/box-manifest
is ready.
I just want to polish some details and perharps prepare a bridge for CycloneDX spec 1.4 with (upcoming cyclonedx/cyclonedx-library
v2.0 still in development)
But code is fully operational with full documentation (available on branch 3.x
)
The Dream became a reality :
bin/box-manifest
) to generate a file manifestmetadata
field of the PHP Archive when invoking default bin/box compile
command !And to conclude my implementation, an example of free format and how to build it ! See https://github.com/llaville/box-manifest/commit/89849329b476f780406a6476eb31011722cfcc7b
Preview, when BOX compile with its contents !
Thank you @llaville, will check it out ASAP
In case of anybody want to use it as a bridge, here are with commit https://github.com/llaville/box-manifest/commit/261d1eea628d9fafe253e732a86ef793ceed9bd7 an example script to follow !
And console logs to preview, if you don't have a chance or time to run it !
With PR 925 my work on adding a manifest feature to official BOX project is now completed (for me).
Awaiting feedbacks
I think with the emergence of the BOM standard, it makes more sense to go towards that solution rather than arbitrary alternative manifest formats. I think PHPUnit was a good and interesting source of inspiration and I like the initial proposal of the manifest that you did, but unlike PHPUnit, we do not need a special format so picking the standard makes more sense.
So reviewing your work and the PR, my initial thoughts are:
true|false
(and default to true
, instead of false
)compile
command, but it's likely a bit too verbose. So maybe it should be there in verbose mode only? But I'm wondering if it's really relevant in the compile output.box/.requirements.php
). So maybe it would make more sense to ship a sbom.xml
file in the PHAR instead.contrib:add-manifest
does exactly? I think it could be interesting to generate a manifest for a given composer based project. Maybe it would be easier to do so only for a Box project as it means mostly re-using code that is used elsewhere (the manifest generator & the rendered from the info command).It's a bit late so might be a bit messy...
To summarize the situation that have changed since last time.
If I've well understood, you don't want to have multiple manifest format supported, but I'm opposite to this idea (sorry) ! I want that the final users are free to choose the format that will match their needs: plain text, decorated text, SBOM (XML or JSON) and everything else.
This is the reason why I'll keep the BOX-Manifest project opened (and will publish a major version 3.0)
I've closed PR #925 because we can solve it with default stub
setting and a custom version (e.g: https://github.com/llaville/box-manifest/commit/07f14a00f4f53ea4d9af907ffa01dfabaf39c0eb)
Purpose of this stub version is to display one of the manifest file it could found into root of the PHP Archive (choice are : first find on the priority list ['manifest.txt', 'manifest.xml', 'sbom.xml', 'sbom.json'], or a specific file identified)
Example runs:
command $ ./app-fixtures.phar --manifest man.txt
output $ Manifest "man.txt" is not available in this PHP Archive.
command $ ./app-fixtures.phar --manifest
output $
<?xml version="1.0" encoding="UTF-8"?>
<bom xmlns="http://cyclonedx.org/schema/bom/1.4" version="1">
<metadata>
<tools>
<tool>
<vendor><![CDATA[box-project]]></vendor>
<name><![CDATA[box]]></name>
<version><![CDATA[4.3.8@5534406]]></version>
</tool>
</tools>
</metadata>
<components>
<component type="library" bom-ref="pkg:composer/psr/log@3.0.0">
<group><![CDATA[psr]]></group>
<name><![CDATA[log]]></name>
<version><![CDATA[3.0.0]]></version>
<purl><![CDATA[pkg:composer/psr/log@3.0.0]]></purl>
</component>
</components>
<dependencies>
<dependency ref="pkg:composer/psr/log@3.0.0"/>
</dependencies>
</bom>
manifest
command in now a pure Symfony Command,
to avoid all questions about fidry/console
.There are two binary commands :
manifest
command to generate files in different formats.Thanks to symfony/runtime
that allow to make it so easy. BTW I've an enhanced version of your autoload_runtime.template
to support PHAR !
Sources :
I've just finished to write a tutorial to learn about BOX-Manifest v3 features. This feature request is no more necessary, because all behaviors (at least on my side) have now a solution.
Would you be open to do a voice call over this topic? I do have several questions but feel like there would be a lot of back and forth (and we already had some)
Time for contribution is now over ! Answers and solutions are available with https://github.com/llaville/box-manifest/releases/tag/3.0.0
Feature Request
Those who know me a little, already know that I've tried in past to include a manifest into the official BOX project. Even if this feature is not available, a fork with patch was born : https://github.com/llaville/box-manifest
That allow to include in
metadata
field, the list of dependency constraints and versions installed. Something like this :Now, with this feature request, I would like to ask if we could see the BOX version used to build the PHAR contents with the
box info
command. Contents such as we see withbox --version
command.That will allow to learn more about PHAR version generated, and perharps diagnose possible issues !
What do you think about this little add-on ?
Box info command will look like: