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 > >>>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>> > >>> > >> > >
