I'm looking forward to RC3. On Fri, Mar 25, 2022 at 11:06 AM Shane Dell <shaned...@apache.org> wrote:
> 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/log4cats-core_2.12@2.1.0 > > > > > > > https://ossindex.sonatype.org/component/pkg:maven/org.typelevel/log4cats-slf4j_2.12@2.1.0 > > > > 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 < > slawre...@apache.org> 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 shaned...@apache.org, 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 > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>> > > >>>>>> > > >>>> > > >>>> > > >> > > >> > > > > >
