Know more about PHAR build contents #841
Comments
|
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 WDYT? |
|
Hello Théo, Thanks for your feedback and especially to point to me the SBOM standard solution. 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. |
|
@theofidry Integration of CycloneDX SBOM feature is very easy. An operational prototype is already available (see commit llaville/box-manifest@75fd437) on my repository ( IMPORTANT notes:
If you want to give it a try for another project than BOX-Manifest itself, don't forget to provide 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: XML format (for specification 1.3)With Output of `box compile` commandJSON format (for specification 1.3)With Output of `box compile` command |
|
To validate contents of SBOM generated by CycloneDX, use the https://github.com/CycloneDX/cyclonedx-cli project. With Docker version: Run following command: Change input file And you will get expected result : |
|
@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 phpunit-10.0.7.phar --sbom > phpunit-10.0.7-sbom.xmlContents of `phpunit-10.0.7-sbom.xml` filedocker 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.xmlPrints |
|
This is not a useful and actionable error:
Trying to use 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 sebastianbergmann/phpunit#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 |
|
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 |
|
re: #841 (comment)
Have you tried the composer plugin |
|
Hello @jkowalleck 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. |
|
Was rereffing to #841 (comment) 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? |
|
@jkowalleck I don't have any new feature requests for v2. Just waiting stable release :) |
|
@theofidry I've just created a prototype of a new Related to my question theofidry/console#145, I don't know how to lazy load any new command (e.g in the My new manifest command invocation will look like
We are closed to realize a dream to add finally the manifest feature in official Box project. |
|
@theofidry Meanwhile your feedback, I'll release soon the last major release 3..0.0 of |
|
Final major version I just want to polish some details and perharps prepare a bridge for CycloneDX spec 1.4 with (upcoming But code is fully operational with full documentation (available on branch The Dream became a reality :
|
|
And to conclude my implementation, an example of free format and how to build it ! 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 llaville/box-manifest@261d1ee 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:
It's a bit late so might be a bit messy... |
|
To summarize the situation that have changed since last time.
Purpose of this stub version is to display one of the manifest file it could found into root of the PHP Archive Example runs:
There are two binary commands :
Thanks to Sources : |
|
I've just finished to write a tutorial to learn about BOX-Manifest v3 features.
|
|
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 ! |
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
metadatafield, 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 infocommand.Contents such as we see with
box --versioncommand.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:
The text was updated successfully, but these errors were encountered: