Serializable gone for 3.0?
Should we remove implements Serializable from classes for 3.0? Gary
Re: SBOM
Hi all, On Thu, 19 Oct 2023 at 15:08, Volkan Yazıcı wrote: > > We probably also need to fill in other keys in the SBOM: > > As far as I can read from sources, custom "keys" (i.e., "external > references") are not supported by `cyclonedx-maven-plugin`. I am > double-checking this with Hervé Boutemy (`cyclonedx-maven-plugin` > maintainer) as we speak. I might create a ticket (maybe even along with a > PR) depending on the outcome. We can probably post-process the output of `cyclonedx-maven-plugin` to add additional externalReferences[1] to our artifacts. The main question is: how useful will that be to current and future SBOM processing tools? Brian, do you have any tips on how to make our SBOM available to the largest possible audience? What we are currently planning is: 1. To generate a CycloneDX SBOM for each of our artifacts using `cyclonedx-maven-plugin`, which will add the SBOMs with a classifier of `cyclonedx` and a type of `xml` and `json`. 2. To add to each of our components in the SBOM two external references (that list the vulnerabilities in our own products and how we are affected by known vulnerabilities in our dependencies): https://logging.apache.org/security/vulnerabilities https://logging.apache.org/security/exploitability The URLs will profit from HTTP content negotiation and will be provided in three formats: * CycloneDX XML, if the client accepts 'application/vnd.cyclonedx+xml', * CycloneDX JSON, if the client accepts 'application/vnd.cyclonedx+json', * a plain HTML web page for the 'text/html` format. My questions regarding this procedure are: 1. Are CycloneDX attachments in Maven Central processed by some tools? Unless I am mistaken, at least Sonatype uses them, 2. Are the `vulnerability-assertion` and `exploitability-statement` references the right way to provide users with information about security-related issues? For example if our `foobar` dependency 1.0.0 publishes a vulnerability and we update our VEX file with our recommendations, will this info reach someone? 3. Can we use HTTP content negotiation or should we provide multiple external references for each of the supported formats? Piotr [1] https://cyclonedx.org/docs/1.5/json/#externalReferences
Re: Serializable gone for 3.0?
Hi Gary, On Fri, 27 Oct 2023 at 12:45, Gary Gregory wrote: > > Should we remove implements Serializable from classes for 3.0? Matt already did it as far as I know. Anyway it's a +1024 from me: it is technically a breaking change even in `log4j-api`, but it is a change most users can live with. Piotr
Re: Serializable gone for 3.0?
Music to my ears :-) On Fri, Oct 27, 2023 at 7:06 AM Piotr P. Karwasz wrote: > > Hi Gary, > > On Fri, 27 Oct 2023 at 12:45, Gary Gregory wrote: > > > > Should we remove implements Serializable from classes for 3.0? > > Matt already did it as far as I know. > Anyway it's a +1024 from me: it is technically a breaking change even > in `log4j-api`, but it is a change most users can live with. > > Piotr
Re: SBOM
FYI to Logging and Brian, Over at Apache Commons, I added generating of CycloneDX and SPDX SBOMs that we publish along with our artifacts. So I'd be curious if "we're doing it wrong" ;-) My take is that it is still early in the SBOM game and that we're getting ahead of the game but just producing these files. We are also discussing publishing OSV and/or VEX files. Gary On Fri, Oct 27, 2023 at 7:04 AM Piotr P. Karwasz wrote: > > Hi all, > > On Thu, 19 Oct 2023 at 15:08, Volkan Yazıcı wrote: > > > We probably also need to fill in other keys in the SBOM: > > > > As far as I can read from sources, custom "keys" (i.e., "external > > references") are not supported by `cyclonedx-maven-plugin`. I am > > double-checking this with Hervé Boutemy (`cyclonedx-maven-plugin` > > maintainer) as we speak. I might create a ticket (maybe even along with a > > PR) depending on the outcome. > > We can probably post-process the output of `cyclonedx-maven-plugin` to > add additional externalReferences[1] to our artifacts. > > The main question is: how useful will that be to current and future > SBOM processing tools? > > Brian, do you have any tips on how to make our SBOM available to the > largest possible audience? What we are currently planning is: > > 1. To generate a CycloneDX SBOM for each of our artifacts using > `cyclonedx-maven-plugin`, which will add the SBOMs with a classifier > of `cyclonedx` and a type of `xml` and `json`. > 2. To add to each of our components in the SBOM two external > references (that list the vulnerabilities in our own products and how > we are affected by known vulnerabilities in our dependencies): > > > https://logging.apache.org/security/vulnerabilities > > > https://logging.apache.org/security/exploitability > > > The URLs will profit from HTTP content negotiation and will be > provided in three formats: > > * CycloneDX XML, if the client accepts 'application/vnd.cyclonedx+xml', > * CycloneDX JSON, if the client accepts 'application/vnd.cyclonedx+json', > * a plain HTML web page for the 'text/html` format. > > My questions regarding this procedure are: > > 1. Are CycloneDX attachments in Maven Central processed by some tools? > Unless I am mistaken, at least Sonatype uses them, > 2. Are the `vulnerability-assertion` and `exploitability-statement` > references the right way to provide users with information about > security-related issues? For example if our `foobar` dependency 1.0.0 > publishes a vulnerability and we update our VEX file with our > recommendations, will this info reach someone? > 3. Can we use HTTP content negotiation or should we provide multiple > external references for each of the supported formats? > > Piotr > > [1] https://cyclonedx.org/docs/1.5/json/#externalReferences
Re: SBOM
On Fri, Oct 27, 2023 at 7:22 AM Gary Gregory wrote: > > FYI to Logging and Brian, > > Over at Apache Commons, I added generating of CycloneDX and SPDX SBOMs > that we publish along with our artifacts. So I'd be curious if "we're > doing it wrong" ;-) > > My take is that it is still early in the SBOM game and that we're > getting ahead of the game but just producing these files. > This ^^. Hardly anyone is producing SBOMs yet... this is something we've been trying to change by have Herve work on the plugin and get it integrated into the Apache Pom so we get them by default. I'm aware of even fewer doing the VEX publication. I will do some digging on how the Cyclone team expected those links to be used but I don't see any red flags. The only thing I can think of is if there should be separate VEX documents for each release. The other thing to be aware of is there is still lack of concensus of VEX vs VDR. It seems like VDR is gaining more traction https://owasp.org/blog/2023/02/07/vdr-vex-comparison > We are also discussing publishing OSV and/or VEX files. > > Gary > > On Fri, Oct 27, 2023 at 7:04 AM Piotr P. Karwasz > wrote: > > > > Hi all, > > > > On Thu, 19 Oct 2023 at 15:08, Volkan Yazıcı wrote: > > > > We probably also need to fill in other keys in the SBOM: > > > > > > As far as I can read from sources, custom "keys" (i.e., "external > > > references") are not supported by `cyclonedx-maven-plugin`. I am > > > double-checking this with Hervé Boutemy (`cyclonedx-maven-plugin` > > > maintainer) as we speak. I might create a ticket (maybe even along with a > > > PR) depending on the outcome. > > > > We can probably post-process the output of `cyclonedx-maven-plugin` to > > add additional externalReferences[1] to our artifacts. > > > > The main question is: how useful will that be to current and future > > SBOM processing tools? > > > > Brian, do you have any tips on how to make our SBOM available to the > > largest possible audience? What we are currently planning is: > > > > 1. To generate a CycloneDX SBOM for each of our artifacts using > > `cyclonedx-maven-plugin`, which will add the SBOMs with a classifier > > of `cyclonedx` and a type of `xml` and `json`. > > 2. To add to each of our components in the SBOM two external > > references (that list the vulnerabilities in our own products and how > > we are affected by known vulnerabilities in our dependencies): > > > > > > https://logging.apache.org/security/vulnerabilities > > > > > > https://logging.apache.org/security/exploitability > > > > > > The URLs will profit from HTTP content negotiation and will be > > provided in three formats: > > > > * CycloneDX XML, if the client accepts 'application/vnd.cyclonedx+xml', > > * CycloneDX JSON, if the client accepts 'application/vnd.cyclonedx+json', > > * a plain HTML web page for the 'text/html` format. > > > > My questions regarding this procedure are: > > > > 1. Are CycloneDX attachments in Maven Central processed by some tools? > > Unless I am mistaken, at least Sonatype uses them, > > 2. Are the `vulnerability-assertion` and `exploitability-statement` > > references the right way to provide users with information about > > security-related issues? For example if our `foobar` dependency 1.0.0 > > publishes a vulnerability and we update our VEX file with our > > recommendations, will this info reach someone? > > 3. Can we use HTTP content negotiation or should we provide multiple > > external references for each of the supported formats? > > > > Piotr > > > > [1] https://cyclonedx.org/docs/1.5/json/#externalReferences
Re: Serializable gone for 3.0?
Yeah I nuked it a while back. > On Oct 27, 2023, at 5:44 AM, Gary Gregory wrote: > > Should we remove implements Serializable from classes for 3.0? > > Gary
