In sbt you can run `show evicted` to print the dependencies and what has been overridden, although usually the highest version is chosen by default, so it is a bit confusing that a earlier version was chosen.
Then something like https://stackoverflow.com/questions/63272822/can-sbt-override-a-transitive-dependency-with-a-different-library can be used to choose a different version. On Thu, Mar 24, 2022 at 8:06 AM Shane Dell <[email protected]> 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 > > >>>>> > > >>>> > > >>> > > >>> > > >> > > > > >
