On Tue, Jun 26, 2018 at 7:28 PM, Alex Harui <email@example.com> wrote:
What doesn’t seem right to me is that you can ship a binary without any way to recreate that binary from sources in a way sufficient enough to make it useful to others. That doesn’t seem “open” or “source” to me.
I guess I struggle with what it means to "recreate test data". As an example, in NetBeans there's a test that the classfile reading library does not crash when it reads a (broken) classfile produced by a specific (fairly old) version of JDK. If one had the source code, then it would be possible to compile the source code, but unless one has the given JDK, that's not recreating the test data. Current JDKs won't (AFAIK) produce the problematic classfile, and then the test proves nothing.
The projects I work on have their own compiler. In order to debug the binary output, we have a “dump” utility that converts the byte code into human-readable form. On my to-do list is a tool that converts the human readable form back into binary form. If you have such tools then the source package would ship the human-readable form and the build script would convert back to .class files and run the usual tests. IMO, this would satisfy the objectives. The human-readable form could contain comments that describe the exact pattern that is being tested. The files would be text and thus less likely to be an attack surface.
You could probably also just Base64Encode the .class files as well, but having a human-readable, annotated text ‘source’ for the binary seems like it could be useful.
My 2 cents,
My 2 cents,