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