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



Reply via email to