On Sat, 18 Sep 2021 15:15:10 GMT, Kevin Rushforth wrote:
>> John Neffenger has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains seven commits:
>>
>> - Make build of SDK ZIP bundle reproducible
>> - Me
ies the Gradle and Groovy build files to fix the first
> three sources of non-determinism. A later pull request can modify the Java
> files to fix the fourth.
>
> [1]: https://reproducible-builds.org/docs/source-date-epoch/
> [2]: https://salsa.debian.org/reproducible-builds/strip-n
On Mon, 22 Nov 2021 06:43:30 GMT, John Neffenger wrote:
>> This pull request allows for reproducible builds of JavaFX on Linux, macOS,
>> and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For
>> example, the following commands create a
On 1/19/22 2:12 PM, Steve Hannah wrote:
I have been resisting using modules for a long time because it just makes
things more complicated, ...
It also makes some things easier, though, and certainly smaller. It's
easier to use an old-school Makefile with modules, and using 'jlink' can
get a
On Mon, 22 Nov 2021 06:43:30 GMT, John Neffenger wrote:
>> This pull request allows for reproducible builds of JavaFX on Linux, macOS,
>> and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For
>> example, the following commands create a
On Sat, 18 Sep 2021 15:15:10 GMT, Kevin Rushforth wrote:
> I did a CI build yesterday and again today on all three platforms and
> compared the sdk between the two builds for each platform. On all three
> platforms the results are the same: All files were identical except the
> native
On Fri, 17 Sep 2021 22:10:41 GMT, Kevin Rushforth wrote:
>> John Neffenger has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains seven commits:
>>
>> - Make build of SDK ZIP bundle reproducible
>> - Me
ies the Gradle and Groovy build files to fix the first
> three sources of non-determinism. A later pull request can modify the Java
> files to fix the fourth.
>
> [1]: https://reproducible-builds.org/docs/source-date-epoch/
> [2]: https://salsa.debian.org/reproducible-builds/strip-nond
Vote: YES
Just in time,
John
On 9/13/21 7:37 AM, Kevin Rushforth wrote:
I hereby nominate Thiago Sayao [1] to OpenJFX Committer.
Thiago is an OpenJFX community member, who has contributed 15 commits
[2] to OpenJFX.
Votes are due by September 27, 2021 at 15:00 UTC.
Only current OpenJFX
On Fri, 17 Sep 2021 23:24:45 GMT, Kevin Rushforth wrote:
> * The timestamps for all files in the zip archives are set to a hard-coded
> "1980-02-01", rather than the date and time specified by `SOURCE_DATE_EPOCH`.
That date was chosen by the Gradle project five years ago in the commit ["Add
On Mon, 14 Jun 2021 20:53:50 GMT, John Neffenger wrote:
>> This pull request allows for reproducible builds of JavaFX on Linux, macOS,
>> and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For
>> example, the following commands create a
On Mon, 14 Jun 2021 20:53:50 GMT, John Neffenger wrote:
>> This pull request allows for reproducible builds of JavaFX on Linux, macOS,
>> and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For
>> example, the following commands create a
On 8/19/21 1:27 PM, Kevin Rushforth wrote:
Those enhancements that have reached general consensus, are far enough
along in the process that we have a good idea how much they will "cost",
and have a willing contributor and sponsor (for contributors who are not
Committers), are more likely to
On 6/23/21 6:50 AM, Kevin Rushforth wrote:
Are there any IDE users who are currently having problems as a result of
this? If not, I'll retarget this for a future release.
I haven't seen problems with the current location of the 'src.zip' file
in NetBeans. For Apache Ant projects, though, I do
On Thu, 17 Jun 2021 14:52:53 GMT, Kevin Rushforth wrote:
> The JavaFX WebKit build fails with Xcode 12.5 + MacOS 11.3 SDK. This is
> related to the added C++20 support where some of the system include files now
> do `#include `. Because the macOS file system is case insensitive,
> it matches
On 6/16/21 10:21 AM, John Neffenger wrote:
4. Finally look up what the GitHub Actions are using (12.4).
Oops, make that "Finally look up what the project uses (12.4)."
For the record, our GitHub Actions use Xcode_11.3.1. [1]
John
[1]:
https://github.com/openjdk/jfx/blob/mast
On 6/16/21 9:56 AM, Philip Race wrote:
1) Don't let macOS upgrade my xcode tools automatically
Lesson learned! But then there's that annoying red badge on your System
Preferences forever. :-)
Actually, it was worse, and went more like this (just in case any else
gets led off-course by the
Just a heads-up about using the latest Xcode 12.5 ...
I use the Command Line Tools for Xcode 12.4 (at 431 MB) to build JavaFX
on macOS as an alternative to the full Xcode package (at 11.86 GB).
Thank you, Arunprasad Rajkumar! [1]
Then Apple Software Update installed the latest Command Line
On Mon, 14 Jun 2021 20:53:50 GMT, John Neffenger wrote:
>> This pull request allows for reproducible builds of JavaFX on Linux, macOS,
>> and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For
>> example, the following commands create a
ies the Gradle and Groovy build files to fix the first
> three sources of non-determinism. A later pull request can modify the Java
> files to fix the fourth.
>
> [1]: https://reproducible-builds.org/docs/source-date-epoch/
> [2]: https://salsa.debian.org/reproducible-builds/strip-nond
On Tue, 9 Mar 2021 22:20:10 GMT, John Neffenger wrote:
> This is a continuation of the [pull request][1] started by @bmwiedemann in
> January 2020. After this change is integrated, I can follow up immediately
> with additional pull requests that get us much closer to provid
On Fri, 30 Apr 2021 00:10:30 GMT, John Neffenger wrote:
>> This is a continuation of the [pull request][1] started by @bmwiedemann in
>> January 2020. After this change is integrated, I can follow up immediately
>> with additional pull requests that get us much closer
On Fri, 16 Apr 2021 19:05:34 GMT, Kevin Rushforth wrote:
>> John Neffenger has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Include WebKit shared library for Windows
>>
>> Enable reproducibl
On Tue, 11 May 2021 01:17:32 GMT, John Neffenger wrote:
>> The Windows build calls a series of batch files to get the Visual Studio
>> paths and environment variables. The batch files are a black box: any
>> messages they print are discarded. If anything goes wro
On 5/19/21 1:17 PM, Ty Young wrote:
Biggest things for JavaFX that I can think of is jextract, a tool for
generating Java headers from a C header, and having all binding code
written in Java.
JavaFX has been doing its own manual form of Project Panama since 2014.
Look for the string "extends
On 5/25/21 2:26 PM, John Neffenger wrote:
Unknown command v - for a list of valid commands use /help.
Just to follow up, there's a Skara bug report for this glitch:
SKARA-755: Anything starting with a "/" is treated as a command
https://bugs.openjdk.java.net/browse/SKARA-755
John
$ grep -A2 'reg query' build/vcvarsall.log
C:\cygwin64\home\john\src\jfx>for /F "tokens=1,2*" %i in
('reg query "HKLM\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows\v10.0"
I did it again -- started a line with a Windows command option inside a
Shell Session code block, resulting in a
On Thu, 13 May 2021 19:11:26 GMT, John Neffenger wrote:
>> John Neffenger has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Skip sending telemetry to fix "file in use" error
>
> I wrote a Bash she
On Tue, 11 May 2021 01:17:32 GMT, John Neffenger wrote:
>> The Windows build calls a series of batch files to get the Visual Studio
>> paths and environment variables. The batch files are a black box: any
>> messages they print are discarded. If anything goes wro
On 5/11/21 10:27 AM, Johan Vos wrote:
I'm still +1 to keep Gradle for OpenJFX.
The OpenJFX build is shockingly complicated. It's not just a Gradle
build. It's a Gradle, Groovy Custom Task, Apache Maven, Apache Ant, GNU
Make, CMake, Ninja, ANTLR, JUnit, GNU GCC, XCode, Visual Studio,
On 5/11/21 5:24 AM, Jeanette Winzenburg wrote:
deleting the caches did work, at last ;)
That's also what I had to do after similar errors. I thought there might
be some bumps in the road when I proposed adding the Gradle dependency
verification, but I hope we can retain enough of it to make
On Tue, 11 May 2021 01:17:32 GMT, John Neffenger wrote:
>> The Windows build calls a series of batch files to get the Visual Studio
>> paths and environment variables. The batch files are a black box: any
>> messages they print are discarded. If anything goes wro
gt;
> ︙
>
> 'powershell.exe' is not recognized as an internal or external command,
> operable program or batch file.
>
> FAILURE: Build failed with an exception.
>
> * Where:
> Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108
>
> * What
On Mon, 10 May 2021 05:54:51 GMT, John Neffenger wrote:
>> The Windows build calls a series of batch files to get the Visual Studio
>> paths and environment variables. The batch files are a black box: any
>> messages they print are discarded. If anything goes wro
On Mon, 10 May 2021 05:54:51 GMT, John Neffenger wrote:
>> The Windows build calls a series of batch files to get the Visual Studio
>> paths and environment variables. The batch files are a black box: any
>> messages they print are discarded. If anything goes wro
gt;
> ︙
>
> 'powershell.exe' is not recognized as an internal or external command,
> operable program or batch file.
>
> FAILURE: Build failed with an exception.
>
> * Where:
> Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108
>
> * What
On Fri, 7 May 2021 13:42:49 GMT, Kevin Rushforth wrote:
> It would be more convenient to ask the developer set `VSCMD_DEBUG` via an env
> variable, rather than asking them to edit `win.gradle`.
Thanks, Kevin. That is the most direct approach. I didn't document it that way
for the following
On Wed, 6 May 2020 20:37:10 GMT, Kevin Rushforth wrote:
> This is a toolchain upgrade on Windows from the current Visual Studio 2017
> (version 15.9.16) to Visual Studio 2019 (version 16.5.3). This will match a
> recent upgrade done for JDK 15 -- see
>
On Wed, 3 Mar 2021 22:07:34 GMT, Alessadro Parisi
wrote:
>> This is a toolchain upgrade on Windows from the current Visual Studio 2017
>> (version 15.9.16) to Visual Studio 2019 (version 16.5.3). This will match a
>> recent upgrade done for JDK 15 -- see
>>
On 5/6/21 1:46 PM, John Neffenger wrote:
$ reg query "HKLM\SOFTWARE\Microsoft\VisualStudio\VSPerf" \
The last part of my comment was truncated by Skara when it tripped over
the '/v' Windows command-line option. It's repeated below for the
mailing list ...
We could instead set t
On Thu, 6 May 2021 20:39:11 GMT, John Neffenger wrote:
> The Windows build calls a series of batch files to get the Visual Studio
> paths and environment variables. The batch files are a black box: any
> messages they print are discarded. If anything goes wrong, the only signs are
The Windows build calls a series of batch files to get the Visual Studio paths
and environment variables. The batch files are a black box: any messages they
print are discarded. If anything goes wrong, the only signs are a vague Gradle
exception and a corrupted properties file.
This has been
On 5/4/21 5:08 AM, Frank Delporte wrote:
I researched this topic for a few hours, but didn't manage to find a good
approach to save a JavaFX Image.
For what it's worth, I ran 224 benchmarks to find the fastest method to
go in the other direction: read in an image using AWT and convert it to
On Tue, 23 Mar 2021 05:32:04 GMT, John Neffenger wrote:
> This pull request adds dependency verification to the Gradle builds of JavaFX
> on Linux, macOS, and Windows. It is the third of three changes that close the
> gaps in the JavaFX build security:
>
> * [JDK-8262236][1]: C
ies the Gradle and Groovy build files to fix the first
> three sources of non-determinism. A later pull request can modify the Java
> files to fix the fourth.
>
> [1]: https://reproducible-builds.org/docs/source-date-epoch/
> [2]: https://salsa.debian.org/reproducible-builds/strip-
n-attacks-like-solarwinds
> [3]: https://tests.reproducible-builds.org/debian/reproducible.html
> [4]: https://reproducible-builds.org/specs/source-date-epoch/
> [5]:
> https://wiki.debian.org/ReproducibleBuilds/StandardEnvironmentVariables#More_detailed_discussion
> [6]: https://reprodu
enjdk.java.net/browse/JDK-8263204
> [3]: https://bugs.openjdk.java.net/browse/JDK-8264010
>
> [4]: https://docs.gradle.org/current/userguide/dependency_verification.html
> [5]:
> https://www.jfokus.se/jfokus20-preso/Protecting-your-organization-against-attacks-via-the-build-system
On Tue, 27 Apr 2021 21:19:26 GMT, Kevin Rushforth wrote:
> Here are the two additional internal downloads for the new versions of the
> gcc-10.3 and vs2019-16.9.3 download
Thanks, Kevin. I'll assume those replace the older versions shown in the
excerpt below, and I'll remove them. Let me know
On 4/21/21 12:06 PM, Johan Vos wrote:
However, I don't think Monocle is ready at this moment to be
bundled with the desktop releases.
Serious question: Why not?
If we do move the Headless Platform out of Monocle, we should consider
bringing its VNC Platform subclass along as well.
John
On Sat, 17 Apr 2021 23:17:04 GMT, John Neffenger wrote:
>> This pull request adds dependency verification to the Gradle builds of
>> JavaFX on Linux, macOS, and Windows. It is the third of three changes that
>> close the gaps in the JavaFX build security:
>>
>>
enjdk.java.net/browse/JDK-8263204
> [3]: https://bugs.openjdk.java.net/browse/JDK-8264010
>
> [4]: https://docs.gradle.org/current/userguide/dependency_verification.html
> [5]:
> https://www.jfokus.se/jfokus20-preso/Protecting-your-organization-against-attacks-via-the-build-system
On Sun, 4 Apr 2021 16:36:27 GMT, John Neffenger wrote:
>> This pull request allows for reproducible builds of JavaFX on Linux, macOS,
>> and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For
>> example, the following commands create a reproducible build:
&
On Sun, 4 Apr 2021 16:36:27 GMT, John Neffenger wrote:
>> This pull request allows for reproducible builds of JavaFX on Linux, macOS,
>> and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For
>> example, the following commands create a reproducible build:
&
On Sat, 27 Mar 2021 18:49:32 GMT, Bernhard M. Wiedemann
wrote:
> Sorted output still complies with that API, though.
Well, that's true. I hadn't thought of it that way.
I have tried twice and failed to [add you as a
contributor](https://github.com/openjdk/jfx/pull/422#issuecomment-806317783)
On Wed, 29 Jan 2020 08:58:47 GMT, Bernhard M. Wiedemann
wrote:
> Allow to override buildDate with `SOURCE_DATE_EPOCH`
> in order to make builds reproducible.
> See https://reproducible-builds.org/ for why this is good
> and https://reproducible-builds.org/specs/source-date-epoch/
> for the
On Sat, 27 Mar 2021 03:34:11 GMT, Bernhard M. Wiedemann
wrote:
> Now the interesting question is, if it is possible to change `listFiles` to
> always return deterministic output ...
Yes, that would be interesting, if `listFiles()` were defined by the Gradle
build tool. I think it originates,
On Tue, 9 Mar 2021 03:11:48 GMT, Bernhard M. Wiedemann
wrote:
> When linking shared libraries, ensure that .o files are listed in
> deterministic order - i.e. `sort(glob(*.c))` and check if individual .c or .o
> files vary between builds.
Wow, that tip was priceless! Thank you, Bernhard. It
On Wed, 15 Apr 2020 02:35:44 GMT, Bernhard M. Wiedemann
wrote:
> I am currently low on time and my Java-foo is not that great, so I was hoping
> that someone would pick it up.
@bmwiedemann Thank you for getting this important change started. If you can
finish this pull request, I'll follow
On Wed, 14 Apr 2021 04:32:29 GMT, John Neffenger wrote:
>> This pull request adds dependency verification to the Gradle builds of
>> JavaFX on Linux, macOS, and Windows. It is the third of three changes that
>> close the gaps in the JavaFX build security:
>>
>>
enjdk.java.net/browse/JDK-8263204
> [3]: https://bugs.openjdk.java.net/browse/JDK-8264010
>
> [4]: https://docs.gradle.org/current/userguide/dependency_verification.html
> [5]:
> https://www.jfokus.se/jfokus20-preso/Protecting-your-organization-against-attacks-via-the-build-system
On Wed, 24 Mar 2021 19:45:55 GMT, John Neffenger wrote:
>> This pull request adds dependency verification to the Gradle builds of
>> JavaFX on Linux, macOS, and Windows. It is the third of three changes that
>> close the gaps in the JavaFX build security:
>>
>>
On Sun, 4 Apr 2021 16:36:27 GMT, John Neffenger wrote:
>> This pull request allows for reproducible builds of JavaFX on Linux, macOS,
>> and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For
>> example, the following commands create a reproducible build:
&
On Sat, 3 Apr 2021 01:49:47 GMT, John Neffenger wrote:
>>> Silly question, is the difference with Windows just the nature of the
>>> native support on each platform (Unix based vs Windows) and libraries used
>>> as part of that?
>>
>> That's a good qu
and Groovy build files to fix the first
> three sources of non-determinism. A later pull request can modify the Java
> files to fix the fourth.
>
> [1]: https://reproducible-builds.org/docs/source-date-epoch/
> [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism
On Fri, 2 Apr 2021 17:45:38 GMT, John Neffenger wrote:
>> Media makefiles look fine.
>
>> Silly question, is the difference with Windows just the nature of the native
>> support on each platform (Unix based vs Windows) and libraries used as part
>> of that?
>
On Thu, 1 Apr 2021 23:21:55 GMT, Alexander Matveev wrote:
>> John Neffenger has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Include media shared libraries for Windows
>>
>> Enable reproducib
On Thu, 1 Apr 2021 19:38:18 GMT, Bernhard M. Wiedemann
wrote:
> IMHO, it would make sense to merge any clear improvement of the status-quo
> and debug+fix more in a later PR.
I agree that we will have to draw the line somewhere, but right now I'm down to
just one file on one operating system
and Groovy build files to fix the first
> three sources of non-determinism. A later pull request can modify the Java
> files to fix the fourth.
>
> [1]: https://reproducible-builds.org/docs/source-date-epoch/
> [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism
On Wed, 31 Mar 2021 13:59:12 GMT, Kevin Rushforth wrote:
>>> I think there might be a Skara bug.
>>
>> No, no bug. Sorry about that. I just don't know how GitHub works.
>> :frowning_face: The pre-submit tests ran two days ago when I pushed the
>> branch to GitHub, so by the time I submitted
On Wed, 31 Mar 2021 23:08:38 GMT, John Neffenger wrote:
>> I recommend trying this with the following gradle flags, to match the
>> settings for production builds:
>>
>> -PCONF=Release -PPROMOTED_BUILD_NUMBER=NNN -PHUDSON_BUILD_NUMBER=MMM
>> -PHUDSON_JOB_
On Wed, 31 Mar 2021 13:59:12 GMT, Kevin Rushforth wrote:
> I recommend trying this with the following gradle flags, to match the
> settings for production builds:
Thanks, Kevin. Good news so far. I'm posting the Linux results while I run the
macOS and Windows builds.
Linux
I ran the
On Thu, 25 Mar 2021 22:58:57 GMT, Kevin Rushforth wrote:
> Build fails on my system with `FAIL: WINSDK_DIR not defined`
@palexdev I hit that error, too. You may have already found this, but you can
work around the problem by using the sample [`windows_tools.properties`][1]
file on the
On Tue, 30 Mar 2021 16:30:25 GMT, John Neffenger wrote:
> I think there might be a Skara bug.
No, no bug. Sorry about that. I just don't know how GitHub works.
:frowning_face: The pre-submit tests ran two days ago when I pushed the branch
to GitHub, so by the time I submitted the pull requ
On 3/25/21 4:12 AM, Kevin Rushforth wrote:
Until then, adding the email address as an unverified additional email
address in your GitHub profile is the way to go.
And the first GitHub user to claim the address wins!
There are a large number of unclaimed commits in our repository that are
up
On 3/28/21 5:24 AM, Johan Vos wrote:
I'm still in favor of closing it though.
It would be nice if there were a way in GitHub to close the repository
to new issues but keep the old ones public and editable. For example,
I'm still getting good information on the old closed issues, even as
On Thu, 25 Mar 2021 02:35:24 GMT, John Neffenger wrote:
>>> @jgneff Could not parse `bmwiedemann` as a valid contributor.
>>
>> You might retry the "contributor" command with the `@` before their GitHub
>> username (I'm not 100% sure that wil
On Tue, 30 Mar 2021 16:20:21 GMT, John Neffenger wrote:
> This pull request allows for reproducible builds of JavaFX on Linux, macOS,
> and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For
> example, the following commands create a reproducible build:
>
This pull request allows for reproducible builds of JavaFX on Linux, macOS, and
Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For example,
the following commands create a reproducible build:
$ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct)
$ bash gradlew sdk jmods
On Wed, 24 Mar 2021 19:50:11 GMT, John Neffenger wrote:
> Are all of them actually needed?
Just to follow up on that question, all of them are in fact downloaded during
the build, at least. I removed the Gradle directory `$HOME/.gradle` and ran the
build as follows. Then I compared the l
I noticed that my last commit used the address jgn...@openjdk.org
instead of the address I normally use to create and sign commits. GitHub
didn't recognize the commit as mine until I added the address to my account.
Do the openjdk.org addresses receive e-mail? If not, do we just leave
the
On Wed, 24 Mar 2021 23:39:21 GMT, Kevin Rushforth wrote:
> You might retry the "contributor" command with the `@` before their GitHub
> username.
Thanks. I'll try that now. I checked and Bernhard is on the list of "OCAs
submitted prior to 2021," but not on the OpenJDK Census list, in case
On Wed, 24 Mar 2021 19:55:20 GMT, Kevin Rushforth wrote:
> I don't yet know to handle this ...
Would any of the following options work?
1. If you're using your own supplemental closed Gradle build file, create your
own supplemental closed Gradle verification file, too. Before the internal
On Tue, 23 Mar 2021 12:07:48 GMT, Kevin Rushforth wrote:
>> This pull request adds dependency verification to the Gradle builds of
>> JavaFX on Linux, macOS, and Windows. It is the third of three changes that
>> close the gaps in the JavaFX build security:
>>
>> * [JDK-8262236][1]: Configure
se/JDK-8263204
> [3]: https://bugs.openjdk.java.net/browse/JDK-8264010
>
> [4]: https://docs.gradle.org/current/userguide/dependency_verification.html
> [5]:
> https://www.jfokus.se/jfokus20-preso/Protecting-your-organization-against-attacks-via-the-build-system.pdf
> [6]: https
On Tue, 23 Mar 2021 18:24:40 GMT, John Neffenger wrote:
> As the comment in the test case mentions, "Tests require that default locale
> is en_US." The default locale is required by the objects created in the
> static method `implementations`, marked with t
As the comment in the test case mentions, "Tests require that default locale is
en_US." The default locale is required by the objects created in the static
method `implementations`, marked with the JUnit annotation
`@Parameterized.Parameters`. So the static method `initDefaultLocale`, marked
On 3/23/21 12:34 AM, Johan Vos wrote:
* bug-report system: I'm all in to find a more accessible way, keeping into
account that would require work being done by the community (hence, us) for
converting issues into high-quality JBS issues.
I have two GitHub Issue Templates that gather the same
On 3/22/21 3:27 PM, Philip Race wrote:
I am informed that, for no reason given, the corporate IT folks will not
allow attachment upload.
Thank you for looking into it, Phil. It's good at least to have a
definitive answer. I brought this up on the mailing list three years
ago, too:
Re: More
This pull request adds dependency verification to the Gradle builds of JavaFX
on Linux, macOS, and Windows. It is the third of three changes that close the
gaps in the JavaFX build security:
* [JDK-8262236][1]: Configure Gradle checksum verification
* [JDK-8263204][2]: Add Gradle Wrapper
On 3/19/21 12:37 PM, Philip Race wrote:
I'm surprised credit is considered important
It took me weeks to figure out some bugs and create a good report, all
done as a volunteer in my spare time. Credit is my only compensation.
I went as far as sneaking my name into the source code comments
On 3/19/21 11:05 AM, Philip Race wrote:
If this was important to him I don't understand why just a blog post and
not a bug report ..
If I had to guess, it might be because, in the age of GitHub, this is
not what people expect when they try to report a bug:
Report a Bug or Request a Feature
This is a continuation of the [pull request][1] started by @bmwiedemann in
January 2020. After this change is integrated, I can follow up immediately with
additional pull requests that get us much closer to providing fully
reproducible builds.
Motivation
The only conclusive way to verify
On Mon, 8 Mar 2021 20:34:05 GMT, John Neffenger
wrote:
> See the [Gradle Wrapper Validation
> Action](https://github.com/marketplace/actions/gradle-wrapper-validation) for
> details on this pull request. I'll test the changes with the following
> sequence of commits:
>
> 1
On Mon, 8 Mar 2021 22:37:10 GMT, John Neffenger
wrote:
>> If it isn't too hard to make the running of the other three jobs dependent
>> on the wrapper validation job, that would be good, as long as the validation
>> job is fast. The other three still need to run in parall
e, which should go
> undetected.
> 2. The next commit will add the Official Gradle Wrapper Validation Action,
> which should detect the tampered file.
> 3. The final commit will remove the tampered file and replace it with the
> original Gradle 4.8 Wrapper.
John Neffenger has updat
On Mon, 8 Mar 2021 22:13:09 GMT, Kevin Rushforth wrote:
>> Thanks, Kevin. I'll merge the two workflow files.
>>
>> The test results aren't what I expected:
>>
>>
e, which should go
> undetected.
> 2. The next commit will add the Official Gradle Wrapper Validation Action,
> which should detect the tampered file.
> 3. The final commit will remove the tampered file and replace it with the
> original Gradle 4.8 Wrapper.
John Neffenger has updat
On Mon, 8 Mar 2021 21:44:03 GMT, Kevin Rushforth wrote:
>> So far, so good. The tampered file was not detected:
>>
>> 
>>
>> The next commit will add the Official
On Mon, 8 Mar 2021 20:38:09 GMT, Kevin Rushforth wrote:
>> See the [Gradle Wrapper Validation
>> Action](https://github.com/marketplace/actions/gradle-wrapper-validation)
>> for details on this pull request. I'll test the changes with the following
>> sequence of commits:
>>
>> 1. This
e, which should go
> undetected.
> 2. The next commit will add the Official Gradle Wrapper Validation Action,
> which should detect the tampered file.
> 3. The final commit will remove the tampered file and replace it with the
> original Gradle 4.8 Wrapper.
John Neffenger has updat
1 - 100 of 190 matches
Mail list logo
