add OSGI metadata #661
Comments
|
I am preparing a release that, among other updates, will add an SBOM via Steve Springett's cyclonedx-maven-plugin that produces a SBOM in XML and JSON formats that is compatible with OWASP Dependency Track. Examples (renamed to .txt so I could attach them) from that plug-in is attached. Would this SBOM not serve the same purpose.?The ESAPI pom is already way more complicated that I'd like it to be and it seems like I spend 1/4 of my life trying to keep all the plugins updated. |
|
I would think the OWASP Dependency-Track covers this. I was taking a peek into this one in particular, and the OSGi framework is bloated IMHO. I can see the value-add, but OSGi has been around since '99 and you'd think this would have bubbled up in importance if this was something that was under heavy adoption. I would think that the OWASP Dependency Track would be sufficient. I poked around in this, and to implement OSGi metadata requires adding a custom class to ESAPI to instruct the build operations. I only looked into it for a few minutes, but this seems like overkill if all you need is a manifest file listing dependencies. |
|
Nevermind @kwwall this is easy. I figured out that you can leave your build package alone and just generate the metadata file.
Before a standard "mvn package" command will generate the file, package will automatically scoop it up into META-INF/ |
|
I think this is too easy and simple not to just include it. The only thing I have to figure out is how to make sure it gets executed as part of the standard build command process. (It's been a long separation... maven configurations and me...) |
|
@xeno6696 - Easy, perhaps. That wasn't so much of my concern. But is it necessary if we are creating an SBOM? It complicates the pom which I don't really like. The SBOM contains all the same info as near as I can tell, along with hashes and I've made changes suggested by Dave Wichers to introduce reproducible builds as well. |
|
I have a distinct feeling that the Eclipse foundations OSGI people aren't aware of or care about the SBOM. I think SBOM is the way of the future, but I doubt their parsers would be looking for us anytime soon. |
|
So, in other words, Eclipse is still using technology from 1999 even though Java now includes the concepts of Java Modules in Java 9 which should address most of those concerns in a much simpler way. Okay, got it. Are you going to make a PR for that? If so, might as well include the bump to AntiSamy 1.6.5 (which I've already done a while back in the PR I am prepping) so I can deal with one less merge conflict. |
|
I have to figure out forcing it to trigger, then I'll generate a PR. My thinking is more that the auto industry relies heavily on OSGI (I know from a friend) and that this is a small win... for those not abandoning technology that's 23yrs old. ROFL Hey, at least its not COBOL! |
|
I'll include the antisamy update on it as well |
As long as it automatically runs as part of 'mvn package' that should be sufficient. If it doesn't usually all you need to do is add something like this: Like I have for the cyclonedx-maven-plugin. They usually support something like that. Running it 'package' phase should be sufficient since we do that as standard part of the deployment instructions. |
|
@zspitzer can you confirm that the only thing necessary would be the manifest dependency data? I'm digging down a rabbit hole: http://www.pnambic.com/home/2015/11/21/using-maven-to-bundle-non-osgi-third-party-libraries/ And I'm getting the picture that to enable the dependency-checking feature you're talking about would require more than JUST an OSGI manifest file. As I'm understanding this, to be fully integrated into that environment ESAPI needs to convert to be fully OSGI-compliant, and that is simply too-specific an ask for what is supposed to be a lowest-common-denominator security library. I don't have test harness to be able to tell whether or not the changes I'm currently looking at will work, and to be frank, I'm fine with setting up a manifest file, but I'm not fine with advertising a feature that I can't test myself. This sounds like a task for the framework maintainers who are packaging ESAPI in OSGI applications. Yeah, to become OSGI compliant is its own bear: https://felix.apache.org/documentation/development/using-the-osgi-compliance-tests.html
^^I don't have time for all that. |
|
@kwwall --> Before I revert these changes, I THINK that for us to be OSGI compliant we'd have to accept their version of MANIFEST.MF. I've enclosed the differences in actual file version. What OSGI frameworks are probably picking up on is the However, I don't know enough to determine if THAT is sufficient for OSGI frameworks to check against, and it appears that the only way to be sure is to go through the hassle of full OSGI compliance testing, which as I said above, I don't think we should be doing. I think if someone needs an OSGI-compliant ESAPI library they fork us and do their own project. I'm assuming that what you're getting ready to do with the BOM already covers this requirement. So @zspitzer I'll give you a week to reply before I close this out. You seem to be the only one who could answer if the BOM we'll be producing is sufficient, or if a simple OSGI-Manifest would be sufficient. |
…663) * Signed key history for MATT SEIL begins here. * Signed key history for MATT SEIL begins here. Fixed email typo. * Revert "Signed key history for MATT SEIL begins here. Fixed email typo." This reverts commit 87c4c4e. * created file on main. * Deleted foo.txt * #661 Added ability to generate OSGi metadata with the command 'mvn org.apache.felix:maven-bundle-plugin:manifest'. * Updated to AntiSamy 1.6.5. * Revert "#661 Added ability to generate OSGi metadata with the command 'mvn org.apache.felix:maven-bundle-plugin:manifest'." This reverts commit 9fa2a53. * #656 --> Parameterized cookie name length and value to correspond with the HTTP maxes defined in esapi.properties. * Adjusted regex to allow for zero-length matches. * Added per review comments for PR #663 Co-authored-by: Matt Seil <xeno6696[at]gmail.com>
|
unfortunately, due to log4j1, the Lucee project has to do some extra OSGI rewrapping of this project, which means we can't just use the normal distribution. https://github.com/lucee/extension-esapi Too many Govs and Corps have banned software which still uses log4j1 however, this manifest might be useful?
|
|
Regarding log4j1, you know that you can just exclude it from your builds, right? All the security bulletins relevant to log4j1 show how to do this. And log4j1 isn't really needed as it is no longer the default logger (JUL is). As soon as the two year anniversary after deprecation hits (sometime in mid-July, I think), we are removing it and all the code that accesses it. |
|
@zspitzer that doesn't precisely answer my question. What you show there is the result of using the bundle plugin. What I need to understand is if that manifest data--is sufficient for your purposes? It's pretty trival to add though @kwwall and I will need to discuss if its okay to replace the current manifest with the OSGI-compliant manifest. Or if we need to supply a separate OSGI-MANIFEST.MF. And will downstream infrastructure know to select the OSGI-MANIFEST.MF if we go down that path? And it's also a good question if the OSGI clients you're referring to will be adhering to the security BOM that we were already planning to add? This helps us figure out what the best course of action will be. If the security BOM will work, there's no need to do an OSGI manifest, and also, if an OSGI manifest isn't sufficient, I need to know what IS sufficient so that way we can appropriately scope the work. It looks like achieving full OSGI compliance takes some development effort plus an NDA, and since I'm donating free time on holidays and occasional weekends... |
|
Well, we definitely are NOT going down any NDA path. I think that goes against all the transparency that OWASP tries to stand for. And as far as the BOM goes, I attached a copy of what's supposed to get uploaded to Maven Repository in #661 (comment). I have yet to hear any comment from @zspitzer about it. The BOM also has hashes of the dependencies. The MANIFEST.MF that was requested doesn't, so IMHO, a BOM, like the one we propose, provides a higher level of assurance. I will say one more thing. We are planning on one last release that will support Java 7 as a minimal JDK. After that, JDK 8 or higher will be required. I am hoping that we'll release that in the next two weeks at the max. (Yeah; I think I said that 2 weeks ago, but I keep finding new stuff that needs fixed for those still stuck on Java 7.) But what I am saying is if this OSGI needs to be put into a version that supports Java 7 that @zspitzer needs to be a little more proactive in answering @xeno6696's questions or it's not going to make it in on time. |
|
So to be clear @kwwall, the NDA would be to gain access to the jarfiles used to analyze OSGI package compliance. I have absolutely no idea why an apache project would be mandating an NDA for that. Seems particularly silly for a FOSS organization. |
|
all that the BOM stuff (has merit) but has nothing to do with what I'm asking for, nor does the NDA stuff. All I was after is having the extra metadata which that maven plugin adds to the existing MANIFEST file, which allows a framework like Apache Felix https://felix.apache.org/ to dynamically load the esapi jar |
|
@kwwall do you see anything that might conflict anywhere else with the manifest differences? BEFORE: AFTER:
Me personally, I can't see any reason why we can't replace it as-is. I've yet to encounter tooling that looks into manifest files, but overall I see this providing some concise information. |
|
looks good, Attributes which are not understood are ignored. Such attributes may include implementation specific information used by applications. https://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#JAR_Manifest |
|
@zspitzer so I'm stuck, and this should be easy but it is driving me nuts. I can generate that file using The relevant part of the pom looks like this right now: This SHOULD run by a simple "mvn package" which runs "process-classes" right after the compile phase. But it never fires. I added these: Trying to help troubleshoot, but they don't seem to affect the behavior. Everything I've found in documentation tells me that maven should be creating the new manifest file. We release to maven central only a few times a year, so it becomes easy to forget to run the standalone command. |
|
@xeno6696 I'll have a look into it tomorrow! |
|
@zspitzer thanks. If you clone this: 9fa2a53 and then just run "mvn package -DskipTests" you should get a rapid run of the build. So far I have tried: 1.) Removing maven-jar reference |
* Signed key history for MATT SEIL begins here. * Signed key history for MATT SEIL begins here. Fixed email typo. * Revert "Signed key history for MATT SEIL begins here. Fixed email typo." This reverts commit 87c4c4e. * created file on main. * Deleted foo.txt * Bump release to new patch version #. * #661 Added ability to generate OSGi metadata with the command 'mvn org.apache.felix:maven-bundle-plugin:manifest'. * Updated to AntiSamy 1.6.5. * Revert "#661 Added ability to generate OSGi metadata with the command 'mvn org.apache.felix:maven-bundle-plugin:manifest'." This reverts commit 9fa2a53. * #656 --> Parameterized cookie name length and value to correspond with the HTTP maxes defined in esapi.properties. * Adjusted regex to allow for zero-length matches. * Added per review comments for PR #663 * #656 Finished sweep looking for headername, headervalue, and header value sizes as well as the 'Cookie' versions of those statements. Added unit tests. * #663 Fixed a missed unit test. * Antisamy 1.6.6, Antisamy regression test for analysis 1. A handful of new regression tests for other purposes in validation and encoder tests. * Attempting to fix classfile differences with antisamy dependencies. * Fixed typo on exclusion. * Added xerces exclusion to antisamy in the pom.xml * Added test cases 2 & 3. * Added test cases 2 & 3. @ignore on test case 3 from AntiSamy as the DOS is still present. * Forced my version to match Wichers. * Added a pair of unit tests for canoncialization to prove out an issue opened up on github. One of which however reminded me that we need a codec to account for UTF-8 encoding/decoding. Co-authored-by: Matt Seil <xeno6696[at]gmail.com> Co-authored-by: kwwall <kevin.w.wall@gmail.com>
there's a maven plugin which adds OSGI metadata
because it's missing, there are quite a few projects which wrap the library to add headers, this causes security scanners to miss flagging outdated versions
https://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html
The text was updated successfully, but these errors were encountered: