Okay so here is what I was able to find last night: - Adding the dependencyOverrides for commons-lang fixes the CVE issue and causes no issue to build - Updating "logback-classic" from 1.2.3 to 1.2.11 fixes the CVE issues and causes no issue to build - Updating to daffodil 3.3.0 causes no issue in build - Updating com.microsoft.java.debug.core from 0.31.1 to 0.35.0 causes no issues - Updating fs2-io from 3.0.4 to 3.0.6 causes no issues - However updating to the latest version being 3.2.5 causes the build to break hence why it is only being updated to 3.0.6 - Updating decline-effect from 2.1.0 to 2.2.0 caused no issue - Updating log4cats-slf4j from 2.1.0 to 2.1.1 caused no issue - However updating to the latest version, being 2.2.0, causes the build to fail hence why it will only be updated to 2.1.1
If this all sounds reasonable I can push a PR for this. Once merged I will close this vote, make rc3 and send out a vote for that. On 2022/03/25 11:27:23 Steve Lawrence wrote: > I think the log4cats findings are false positives. The links that > dependencyCheck provides for the log4cats findings are here: > > > https://ossindex.sonatype.org/component/pkg:maven/org.typelevel/[email protected] > > > https://ossindex.sonatype.org/component/pkg:maven/org.typelevel/[email protected] > > Neither of those pages list any CVE's. And the details for each of those > findings lists these two CVE's which have nothing to do with log4cats: > > https://nvd.nist.gov/vuln/detail/CVE-2021-32816 > > https://nvd.nist.gov/vuln/detail/CVE-2022-22931 > > The first one is something about ProtonMail Web Client, and the second > one about for Apache James. > > So I think the log4cats findings can be ignored, and should be > considered a bug in the CVE checker. > > > On 3/24/22 9:27 PM, Shane Dell wrote: > > Ah okay that makes we will still want dependabot for the node/typescript > > extension side. But > > what do you think is best for log4cats stuff since the latest version still > > has CVEs? The > > overriding fixed the commons-lang3 issue. But the log4cats-slf4j is a > > direct dependency that > > adds log4cats-core and both of those at latest still have CVEs. > > > > I will make sure to test debugger still builds and run fine with these > > updates as well before > > pushing them up to GitHub. > > > > On 2022/03/25 01:21:37 Steve Lawrence wrote: > >> I'd probably update deps first so we don't get a flood of new dependency > >> PRs to approve. > >> > >> Also, now that I think about it, dependabot doesn't do sbt dependencies. > >> We need scala-steward for that. Daffodil uses enables dependabot for > >> github-actions and container updates, and scala steward for sbt updated. > >> > >> On 3/24/22 9:18 PM, Shane Dell wrote: > >>> So with the PR I will need to make to get this fixes going, would you > >>> want me to just add dependabot? I believe that is an issue but can't > >>> remember for sure but I can get it hooked up for both scala/sbt and for > >>> node/ts/extension. > >>> > >>> On 2022/03/25 01:13:07 Steve Lawrence wrote: > >>>> I believe the sbt way to override transitive dependencies is with the > >>>> dependencyOverrides setting: > >>>> > >>>> https://www.scala-sbt.org/1.x/docs/Library-Management.html#Overriding+a+version > >>>> > >>>> While we're at it, we may want to also update all dependencies so > >>>> everything is at the latest. Eventually we'll want dependabot to help us > >>>> with that and automate it, but the sbt-updates plugin can be used to > >>>> manually check for updates: > >>>> > >>>> https://github.com/rtimush/sbt-updates > >>>> > >>>> On 3/24/22 9:02 PM, Shane Dell wrote: > >>>>> So its an issue com.microsoft.java:com.microsoft.java.debug.core:0.31.1 > >>>>> but updating to > >>>>> com.microsoft.java:com.microsoft.java.debug.core:0.35.0, which is the > >>>>> latest, it still uses a commons-lang3:3.6. So what do I do for these > >>>>> items since updating to the latest version don't fix them? > >>>>> > >>>>> > >>>>> On 2022/03/25 00:37:40 Steve Lawrence wrote: > >>>>>> The sbt dependency graph plugin might help to show where transitive > >>>>>> dependencies are coming from: > >>>>>> > >>>>>> https://github.com/sbt/sbt-dependency-graph > >>>>>> > >>>>>> > >>>>>> On 3/24/22 8:34 PM, Shane Dell wrote: > >>>>>>> I would say it is correct as in the list of jars for log4j-api I am > >>>>>>> seeing 2.17.2 which is the version that fixed that CVE issue right? > >>>>>>> If so we are good on that from. I was able to fix the logback errors > >>>>>>> by updating logback-classic from 1.2.3 to 1.2.11. Still trying to > >>>>>>> figure out log4cat-slf4j as well as core because the latest version > >>>>>>> seems to be 2.2.0 but that still has a CVE. I am also working on > >>>>>>> where commons-lang3-3.6 comes from as it most be a dependency of a > >>>>>>> dependency. > >>>>>>> > >>>>>>> > >>>>>>> On 2022/03/24 16:17:14 Steve Lawrence wrote: > >>>>>>>> Interesting. This might be a difference between 3.3.0 and 4.0.0 of > >>>>>>>> the > >>>>>>>> plugin? I get your list with 4.0.0, and a different list with 3.3.0. > >>>>>>>> > >>>>>>>> Note that vscode does include log4j-api-2.17.0.jar. The log4j CVE's > >>>>>>>> were > >>>>>>>> fixed in 2.17.2, so it's a bit concerning that this is only 2.17.0. > >>>>>>>> But > >>>>>>>> maybe the vulnerability is only in log4j-core, which vscode does not > >>>>>>>> include? > >>>>>>>> > >>>>>>>> So maybe this 4.0.0 list is correct, assuming log4j-api doesn't have > >>>>>>>> the > >>>>>>>> vulnerability? > >>>>>>>> > >>>>>>>> On 3/24/22 11:11 AM, Shane Dell wrote: > >>>>>>>>> I get the vulnerabilities for: > >>>>>>>>> > >>>>>>>>> - commons-lang3-3.6.jar > >>>>>>>>> - log4cats-core_2.12-2.2.0.jar > >>>>>>>>> - log4cats-slf4j_2.12-2.2.0.jar > >>>>>>>>> - logback-classic-1.2.3.jar > >>>>>>>>> - logback-core-1.2.3.jar > >>>>>>>>> > >>>>>>>>> I don't get anything about log4j-api. And the only onces with a > >>>>>>>>> HIGH Severity value are the two log4cats items. So is yours picking > >>>>>>>>> up cached dependencies or ones from other projects not just the > >>>>>>>>> vscode repo? > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On 2022/03/24 15:05:27 Shane Dell wrote: > >>>>>>>>>> So I think the log4j errors you are seeing are coming from a > >>>>>>>>>> library dependency the Scala debugger user, this being > >>>>>>>>>> `log4cats-slf4j` which only goes to 2.2.0 put still has two high > >>>>>>>>>> CVE's, Adam maybe you know if we can switch this something else to > >>>>>>>>>> avoid the vulnerabilities? > >>>>>>>>>> > >>>>>>>>>> On 2022/03/24 14:02:37 Steve Lawrence wrote: > >>>>>>>>>>> I just used this for the dependency check, that has all the > >>>>>>>>>>> instructions > >>>>>>>>>>> that are needed: > >>>>>>>>>>> > >>>>>>>>>>> https://github.com/albuch/sbt-dependency-check > >>>>>>>>>>> > >>>>>>>>>>> They say to put that in project/plugins.sbt, but I recommend > >>>>>>>>>>> putting it > >>>>>>>>>>> in ~/.sbt/1.0/plugins/plugins.sbt, then it's available for any > >>>>>>>>>>> project > >>>>>>>>>>> you might use (e.g. both daffodil and vscode). > >>>>>>>>>>> > >>>>>>>>>>> Then just run "sbt dependencyCheckAggregate", and the resulting > >>>>>>>>>>> report > >>>>>>>>>>> is put in target/scala-2.12/dependency-check-report.html. > >>>>>>>>>>> > >>>>>>>>>>> I'm not sure I would recommend adding CVE checking to CI because > >>>>>>>>>>> downloading the CVE database takes a long time, especially the > >>>>>>>>>>> first > >>>>>>>>>>> time. I might recommend instead just enabling dependabot, that's > >>>>>>>>>>> been > >>>>>>>>>>> good about keeping Daffodil dependencies up to date. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On 3/24/22 9:45 AM, Shane Dell wrote: > >>>>>>>>>>>> Fixing the CVEs and bumping up to Daffodil 3.3.0 make sense to > >>>>>>>>>>>> me. Steve how would I setup the dependency check you are doing > >>>>>>>>>>>> so I make sure I use versions that fix it? Figure it would be > >>>>>>>>>>>> good to add that into build.sbt/source so it can be ran in CI at > >>>>>>>>>>>> some stage as well. > >>>>>>>>>>>> > >>>>>>>>>>>> On 2022/03/24 13:42:36 Mike Beckerle wrote: > >>>>>>>>>>>>> Since we have to fix the CVE issues, we should also update to > >>>>>>>>>>>>> Daffodil 3.3.0 > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Thu, Mar 24, 2022 at 9:04 AM Steve Lawrence > >>>>>>>>>>>>> <[email protected]> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>> I think I've sort of found the issue with the different .class > >>>>>>>>>>>>>> files. If > >>>>>>>>>>>>>> I disassemble the class files that don't match, they all have > >>>>>>>>>>>>>> diffs that > >>>>>>>>>>>>>> look like this: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> - 21: ldc #155 // String > >>>>>>>>>>>>>> Uninitialized > >>>>>>>>>>>>>> field: /home/user/daffodil-vscode/path/to/file.scala: 394 > >>>>>>>>>>>>>> + 21: ldc #155 // String > >>>>>>>>>>>>>> Uninitialized > >>>>>>>>>>>>>> field: /root/daffodil-vscode/path/to/file.scala: 394 > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Note that the uninitialized field path changes depending on > >>>>>>>>>>>>>> the system > >>>>>>>>>>>>>> that built it. So absolute paths are compiled into the > >>>>>>>>>>>>>> bytecode somehow. > >>>>>>>>>>>>>> The surrounding byte code suggests that this is about a > >>>>>>>>>>>>>> scala.UninitializedError exception, my guess is that path > >>>>>>>>>>>>>> shows up in > >>>>>>>>>>>>>> that exception message. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I'm not sure why we don't see this issue with Daffodil. Maybe > >>>>>>>>>>>>>> Daffodil > >>>>>>>>>>>>>> does something different so we can't have any > >>>>>>>>>>>>>> UninitializedFieldErrors? > >>>>>>>>>>>>>> I don't think this needs to be fixed for this released, but I > >>>>>>>>>>>>>> would > >>>>>>>>>>>>>> prefer it is fixed for next release. I can change that to a > >>>>>>>>>>>>>> [MINOR] > >>>>>>>>>>>>>> finding. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> My vote stills stays a -1 for the CVE issues, though. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On 3/24/22 8:44 AM, Steve Lawrence wrote: > >>>>>>>>>>>>>>> -1 (binding) > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Main issues is inclusion of packages with open CVE's, I think > >>>>>>>>>>>>>>> that > >>>>>>>>>>>>>>> should be fixed for this release. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I'm also concerned about differences I found between the > >>>>>>>>>>>>>>> released > >>>>>>>>>>>>>>> daffodil-debugger jar and the same jar I built from source. > >>>>>>>>>>>>>>> Class > >>>>>>>>>>>>>>> files inside that jar differ, and it's not clear why. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I checked: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> [OK] hashes and signatures of source and helper binares are > >>>>>>>>>>>>>>> correct > >>>>>>>>>>>>>>> [OK] signature of git tag is correct > >>>>>>>>>>>>>>> [OK] source release matches git tag > >>>>>>>>>>>>>>> [OK] source compiles using yarn build > >>>>>>>>>>>>>>> [NOT OK] compiled source matches convenience binary > >>>>>>>>>>>>>>> The org.apache.daffodil.daffodil-debugger-1.0.0.jar > >>>>>>>>>>>>>>> packaged in > >>>>>>>>>>>>>>> daffodil-debugger-3.2.1-1.0.0.zip is different when > >>>>>>>>>>>>>>> I build the > >>>>>>>>>>>>>>> .vsix file from source. Numerous .class files inside > >>>>>>>>>>>>>>> that jar have > >>>>>>>>>>>>>>> different hashes. This is unexpected. We don't have > >>>>>>>>>>>>>>> this issue with > >>>>>>>>>>>>>>> Daffodil, so I'm concerned something with the vscode > >>>>>>>>>>>>>>> build system is > >>>>>>>>>>>>>>> broke. > >>>>>>>>>>>>>>> [OK] src and binaries include correct LICENSE/NOTICE > >>>>>>>>>>>>>>> [OK] RAT check passes > >>>>>>>>>>>>>>> [OK] no unexpected binaries in source > >>>>>>>>>>>>>>> [OK] vsix installs without error > >>>>>>>>>>>>>>> [NOT OK] No open CVE's found using sbt-dependency-check plugin > >>>>>>>>>>>>>>> Scan found three packages with open CVES: > >>>>>>>>>>>>>>> - log4j-api-2.17.0.jar > >>>>>>>>>>>>>>> - logback-classic-1.2.3.jar > >>>>>>>>>>>>>>> - logback-core-1.2.3.jar > >>>>>>>>>>>>>>> We depend on Daffodil 3.2.1 which should pull in > >>>>>>>>>>>>>>> log4j 2.17.2 which > >>>>>>>>>>>>>>> addresses the CVE's. Seems like something is > >>>>>>>>>>>>>>> overriding that? Also > >>>>>>>>>>>>>>> not sure where the logback dependency is pulled in > >>>>>>>>>>>>>>> from, but maybe > >>>>>>>>>>>>>>> related. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> [MINOR] The "publisher" for the vsix file is "asf". That > >>>>>>>>>>>>>>> should > >>>>>>>>>>>>>>> probably be "Apache Software Foundation" or just > >>>>>>>>>>>>>>> "Apache", or maybe > >>>>>>>>>>>>>>> it should be "Apache Daffodil". We can have this > >>>>>>>>>>>>>>> discussion later, > >>>>>>>>>>>>>>> but this should be fixed for the next release. > >>>>>>>>>>>>>>> [MINOR] The README shows up in VS Code, but is focused on how > >>>>>>>>>>>>>>> to build > >>>>>>>>>>>>>>> the extension. This makes sense for the main github > >>>>>>>>>>>>>>> README, but I > >>>>>>>>>>>>>>> wonder if the README displayed in VS Code wants to > >>>>>>>>>>>>>>> be different, and > >>>>>>>>>>>>>>> focus more on features/usability. We already have a > >>>>>>>>>>>>>>> differnt LICENSE > >>>>>>>>>>>>>>> file, we should do the same for the README? > >>>>>>>>>>>>>>> [MINOR] The LICENSE file has incorrect indentation making it > >>>>>>>>>>>>>>> difficult > >>>>>>>>>>>>>>> to see where one sub component ends and another > >>>>>>>>>>>>>>> begins. Would be > >>>>>>>>>>>>>>> helfup to fix this for the next release. The file > >>>>>>>>>>>>>>> bundled in the > >>>>>>>>>>>>>>> .vsix binary looks good. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On 3/17/22 3:06 PM, Shane Dell wrote: > >>>>>>>>>>>>>>>> Hello all, > >>>>>>>>>>>>>>>> Ignore the last vote as I did not change my email to the > >>>>>>>>>>>>>>>> proper one > >>>>>>>>>>>>>>>> registered for apache. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> I'd like to call a vote to release Apache Daffodil VS Code > >>>>>>>>>>>>>>>> 1.0.0-rc2. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> All distribution packages, including signatures, digests, > >>>>>>>>>>>>>>>> etc. can be > >>>>>>>>>>>>>>>> found at: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> https://dist.apache.org/repos/dist/dev/daffodil/daffodil-vscode/1.0.0-rc2/ > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> This release has been signed with PGP key > >>>>>>>>>>>>>>>> 86DDE7B41291E380237934F007570D3ADC76D51B, corresponding > >>>>>>>>>>>>>>>> to [email protected], which is included in the KEYS file > >>>>>>>>>>>>>>>> here: > >>>>>>>>>>>>>>>> https://downloads.apache.org/daffodil/KEYS > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> The release candidate has been tagged in git with 1.0.0-rc2. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> For reference, here is a list of all closed GitHub issues > >>>>>>>>>>>>>>>> tagged with > >>>>>>>>>>>>>>>> 1.0.0: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> https://github.com/apache/daffodil-vscode/issues?q=is%3Aissue+is%3Aclosed+is%3A1.0.0 > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Please review and vote. The vote will be open for at least > >>>>>>>>>>>>>>>> 72 hours > >>>>>>>>>>>>>>>> (Sunday, 17 March 2022, 12 Noon EST). > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> [ ] +1 approve > >>>>>>>>>>>>>>>> [ ] +0 no opinion > >>>>>>>>>>>>>>>> [ ] -1 disapprove (and reason why) > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Thank you, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> - Shane Dell > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > >>>> > >>>> > >> > >> > >
