(RANT below! :) ) I would love to see some tool for actually somewhat verifying that some bytecode release is possible to create from a given source release, and specially that there are no "extra bits" in it.
If Apache binaries were automatically produced through a properly sandboxed, INFRA-managed machine (not as widely write-accessible as the current Jenkins), then that would also make a trustworthy system. If I have time and it is managable - I do at least an unzip of the deployed JARs and see that the file list compare with what I find in the compiled JAR. It is not secure in the sense that the binary bytecode could theoretically be doing something widely different from the source, but it could uncover say that the deployment used some local files not being checked in or similar. The source code is what matters -- to be secure you should compile from signature-verified source. Compiling *everything* from source is usually reserved to a couple of Debian enthusiasts and security-aware companies. Most Java developers will happily pull the binaries from Maven Central and rely just Maven checking the sha1 hashes (pulled from the same place over an unencrypted line). On 30 March 2015 at 11:24, Andy Seaborne <[email protected]> wrote: > On 29/03/15 23:57, Peter Ansell wrote: >> >> On 30 March 2015 at 06:10, John D. Ament <[email protected]> wrote: >>> >>> On Sat, Mar 28, 2015 at 9:34 PM Peter Ansell <[email protected]> >>> wrote: >>> >>>> On 29 March 2015 at 11:57, John D. Ament <[email protected]> wrote: >>>>> >>>>> Great question/comment! I always look forward to this part with new >>>>> podlings. >>>>> >>>>> On Sat, Mar 28, 2015 at 5:32 PM Peter Ansell <[email protected]> >>>> >>>> wrote: >>>>> >>>>> >>>>>> That is fine with me. >>>>>> >>>>>> I am not overly fascinated by internal Apache infrastructure though so >>>>>> I would like to keep the .travis.yml file and the references to >>>>>> coveralls if possible as there is nothing broken with that system >>>>>> right now for CI and code coverage. >>>>>> >>>>> >>>>> It's weird that you feel this way (from my point of view). Part of why >>>>> projects seek out the ASF is to leverage the infrastructure in place >>>> >>>> that's >>>>> >>>>> provided. It's generally expected that the in house services will be >>>>> leveraged. >>>>> >>>>> http://www.apache.org/dev/services.html >>>> >>>> >>>> That perspective is very reduced these days by the free set of >>>> services that non-Apache projects generally rely on these days. >>>> >>>> Ie, a project can (and virtually all of my other projects that I am >>>> active with do so) run quite comfortably just with free (for open >>>> source code) providers: >>>> >>>> * GitHub or BitBucket for code hosting, wiki >>>> * GitHub for HTTP hosting and possibly issue tracking >>>> * Free Jira issue tracking license and hosting on Atlassian >>>> Cloud/OnDemand for OSS projects >>>> * TravisCI for continuous integration >>>> * Sonatype OSS Nexus repositories for snapshots and releases >>>> * Coveralls for code coverage >>>> * Google Groups for mailing lists >>>> >>>> In reality, the main reasoning for going to Apache is probably solely >>>> the brand these days, which overcomes the administrative overhead in >>>> the case of mature projects, or in our case, fairly short-lived >>>> projects (in terms of active development, we want to maintain a >>>> consistent core after a short term of stabilisation). >>>> >>> >>> I think this is the most troubling part of your post from my point of >>> view. One of the things we need to be extremely careful about in the >>> incubation process isn't the fact that people are consumed with the >>> Apache >>> brand. If the goals here are simply to get the name Apache put in front >>> of >>> the project, it's probably not going to grow that well. >> >> >> We don't expect a community to grow around the code itself, which was >> part of the reason for wanting it to be located within the broader >> Commons community in preference to a TLP. The reasoning is that there >> will be minimal changes to the APIs which make up the code, once it is >> stabilised, by design. Other than the pure Java interfaces which make >> up the API, we only have a single implementation that we will be >> developing against it. The only reasoning for having the simple >> implementation is to check the contract tests against a system that >> has no dependencies and is produced for the sole purpose of being a >> test harness. Given its status as a test harness, it doesn't need to >> be optimised, but it does need to fulfill the contracts, so if the >> contracts change, the test harness will need to reflect the change. >> Once the contracts are finalised, the simple implementation will be >> basically as static as the APIs. >> >> Part of the reasoning for starting out on GitHub was to attract a >> broad initial discussion, which, before we had a dedicated mailing >> list here, wasn't as simple as GitHub Issues and PRs for collaboration >> and quick commenting on the overall design. Since everyone has GitHub >> accounts, but not everyone wanted to subscribe to the deluge of emails >> going through the commons dev mailing list, it was the logical >> solution for the initial discussion. In addition, we had two >> approaches to the commons community last year but both seemed to fail >> during negotiation on the point that we required a dedicated mailing >> list inside of the Commons TLP, which is why we ended up here in the >> Incubator, essentially. >> >> I am personally ambivalent to whether this project is hosted within >> Apache, to gain the brand recognition, or whether it exists on GitHub >> as an independent project there, but the other main contributors >> heavily favour Apache and are fine with handling the administrative >> overhead that comes with that choice. >> >>> While it is true there are many services out there to leverage, we're >>> expected to use Apache services. That doesn't mean solely Apache >>> services. You can use Travis, Coveralls, Cloudbees, GitHub wiki, etc all >>> you want. One limitation we do have is that you can't download binaries >>> from those sites that don't point to an Apache mirror'd location. >> >> >> That sounds fine, although I thought that Apache didn't have any >> control measures around binaries, with all releases only formally >> containing the source, with the binaries incidental? We will be using >> Maven Central as the main point of access for downloads, so that >> should be fine, given that every other Apache Java project also does >> that. >> >> Cheers, >> >> Peter >> > > For me personally, I see the move to Apache as giving the project long term > (e.g. 10 year) stability separate from github (a commercial company that > might change at any time (unlikely, but then FoundationDB was a big > surprise), and separate from specific people. > > Any long term OS project needs to have a governance structure. Many have > their own foundations; that's a big overhead for small(er) projects. ASF > provides assurance that the IP is setup correctly. IP, and legal issues > generally, seem a burden at times but if done right initially then > everything runs smoothly. Unlike code, going back and trying to fix an > early problem is much harder in legal. > > I think using all the tools around to improve the output of this activity is > good. ASF infrastructure and process first and foremost insures the > integrity of releases (source and binary). The development assist is very > useful as well. As a small activity, many different ways of doing that work > for us. > > Branding the technology is, for me, not a significant part of the move. > >> Apache didn't have any >> control measures around binaries > > A community can define what it agrees over and above the minimum at Apache > and Java makes it somewhat different to the C world. Any binaries in a > release process must correspond to the source which is what one would expect > of any OS project. Publishing to maven is part of the release process for > Java projects. > > (I also find some of the language around releases vs snapshots too extreme > as well. It seems to reinforce an artificial barrier between user@ and dev@ > for the Java world which is not where it's at.) > > Andy > -- Stian Soiland-Reyes Apache Taverna (incubating), Apache Commons RDF (incubating) http://orcid.org/0000-0001-9842-9718
