Hi Stian, Maven Central now has HTTPS available, and Maven will use it by default if you are using 3.2.3 or later:
http://central.sonatype.org/pages/consumers.html#apache-maven That was the main reason for me to update to 3.2.3. Cheers, Peter On 1 April 2015 at 02:58, Stian Soiland-Reyes <[email protected]> wrote: > (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
