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