Seems reasonable to me. Note that with all the updates, it's important
to double check that non of the licenses or notice information changes
for any of the dependency (either direct or transitive). Note that I
know changes were made to the bin.NOTICE and bin.LICENSE files for
Daffodil from 3.2.1 and 3.3.0, so those changes will definitely need to
be incorporated.
On 3/25/22 11:06 AM, Shane Dell 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/[email protected]
https://ossindex.sonatype.org/component/pkg:maven/org.typelevel/[email protected]
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 <[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
