Hi, On Sat, 21 Mar 2026 at 18:52, Jarek Potiuk <[email protected]> wrote: > if you > can write a script (purely sources you can read) and have it released > together in the sources, and if yoy can run the script on two files and > that script shows and explains all the differences when you run the same > package locally and in the cloud, then this meets **my** definition of > "reproducible-enough".
If you mean a pure sources script that replicates the process in GHA, then that's easy - that's what the repo is (linked in my first post). The workflow sets up the certificates and environment, then runs a single Java source file that does the verification and packaging. This is designed to be runnable locally. If you mean a script to verify where the differences are, then while doable, I think this is better verified in other ways. For a start it's all OS-specific, with at least one OS probably requiring running the installation, and the differences will differ depending on code signing access. We would have 3 things to check against - original binary zip payload, local package without code signing, and GHA package with code signing. > Also the question is where the input files are > downloaded from. I asume from SVN of ours, and there is similar > reproducible check before to produce those. :). The packager is released and downloaded from Maven Central. As far as I'm aware, it is reproducible. NetBeans itself is not reproducible. It probably never will be. It's a massive project with 30 years of technical debt, and a few questionable build decisions. My current external workflow (and this might change if we replicate internally) downloads from nightlies.a.o for weekly release candidates, and from dlcdn.a.o for the actual release. Signed release candidates are actually an essential part of testing. NetBeans releases its sources (obviously!), along with a binary zip. Derived from the binaries in that zip are hundreds of Maven artefacts and any installer packages. Provenance back to the binaries in that zip is important, and is all we have for verification purposes. But as far as I'm concerned, the payload isn't relevant here. We've been code signing installers that bundle the released zip for years. Moving the signing on to GHA, while verifying to the maximum extent feasible that it is actually bundling that zip, does not change anything fundamental about what we're doing. If distributing non-reproducible binaries in itself becomes the issue, then you might as well tell NetBeans to shut up shop. > In short for me, the goal of building things in GH is not to **reduce the > load**—in fact, I think proper security for a release introduces some > healthy friction and requires effort. It's deliberately designed to make > people think, pause and actually verify that what they are doing is good > and secure. Rather than striving to spend as little effort as possible ... That is an unfair characterization of what the concern is here. And what is a priority for individual PMCs should be left to them to decide. What we require most is to reduce release overhead by not relying too much on individuals, and finding ways to share access to these resources. We need to be able to share access to code signing, including with members of the PMC who may not be in a position to run things locally. I have been delivering installers for NetBeans+JDK externally for five years now. These are the only installers available right now. I was the only person on our PMC capable of building ASF macOS installers for years until we dropped them last year, because we had no way of sharing access to the foundation's Apple certificate. Leaving aside the issue with finding the next person willing to be lumbered with the time consuming job even if we did - I don't even use macOS! :-) At the moment we are in a catch 22 - the very things we need access to on shared infrastructure (eg. Apple's signing and packaging tools) are the very things that stop the process from being reproducible. For the last two releases, the only installers for NetBeans have been produced, signed and distributed by me at my own expense. We might get another provider soon. But we've also had questions within ASF, including from the board, on why we've dropped provision of installers directly, and the security and other ramifications of relying on "third-parties" for this. If we are ever to bring back installers directly at ASF, we need to find the best answer here, not the perfect one. Thanks, Neil --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
