incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sterling Hughes <sterling.hughes.pub...@gmail.com>
Subject Re: [VOTE] Accept Milagro into the Incubator
Date Tue, 15 Dec 2015 18:30:29 GMT
+1 binding 

> On Dec 15, 2015, at 7:51 AM, Colm O hEigeartaigh <coheigea@apache.org> wrote:
> 
> +1 (binding)
> 
> Colm.
> 
> On Tue, Dec 15, 2015 at 10:56 AM, Jean-Baptiste Onofré <jb@nanthrax.net>
> wrote:
> 
>> +1 (binding)
>> 
>> Regards
>> JB
>> 
>> 
>>> On 12/15/2015 09:56 AM, Nick Kew wrote:
>>> 
>>> I should like to call a vote to accept Milagro into
>>> the Incubator.  The full proposal is available at
>>> https://wiki.apache.org/incubator/MilagroProposal
>>> as well as below.
>>> 
>>> Note that the project was first discussed here under
>>> the name OpenMiracl.  The adoption of the Milagro name
>>> is a response to that discussion.
>>> 
>>> [ ] +1 Accept Milagro into the Apache Incubator
>>> [ ] 0
>>> [ ] -1 Do not accept Milagro into the Apache Incubator ...
>>> 
>>> The vote remains open until at least the end of the week.
>>> 
>>> For myself:
>>> [*] +1 Accept Milagro into the Apache Incubator
>>> 
>>> 
>>> = Project Proposal: Milagro =
>>> == Abstract ==
>>> Milagro is a distributed cryptosystem for cloud computing. Its purpose
>>> is to provide an open source alternative to proprietary key management
>>> and certificate backed cryptosystems used for secure communication and
>>> authentication. The adoption of Milagro will create a secure, free, open
>>> source alternative to monolithic certificate authorities and eliminate
>>> single points of failure.
>>> 
>>> == Background ==
>>> The Cloud Computing industry is using 40-year-old cryptographic
>>> algorithms and infrastructure, invented for a different era when
>>> client-server computing was the dominant paradigm. At the heart of it,
>>> is the continued reliance on outdated, and problematic, monolithic
>>> cryptographic trust hierarchies such as commercial certificate
>>> authorities.
>>> 
>>> A number of factors are aligning to make this the right time to bring
>>> forth an alternative to the Internet's continued reliance on PKI.
>>> 
>>> The Cloud Infrastructure as a Service (IaaS) industry as a whole
>>> encounters friction bringing the largest customers in regulated
>>> industries onto their platforms because issues of cryptographic trust,
>>> data residency, and data governance prevent total adoption among
>>> regulated industries.
>>> 
>>> Devops teams tasked with running an IaaS provider's datacenter
>>> automation encounter challenges scaling and automating data center
>>> operations when confronted with the complexities of running encryption,
>>> certificate and key management infrastructures built for a client-server
>>> era.
>>> 
>>> Enterprises in regulated industries find challenges to transform
>>> entirely into digital businesses because the economics of cloud
>>> computing are unavailable to them.
>>> 
>>> Despite the astounding growth of cloud infrastructure as a service
>>> platforms over the last few years, full adoption by organizations with
>>> stringent data security requirements won’t be achieved until these
>>> fundamental capability issues get resolved.
>>> 
>>> Lastly, the Internet as a whole is suffering from an erosion of trust
>>> following incidents with commercial certificate authorities industry,
>>> i.e., compromised root keys, and failures in due diligence issuing real
>>> domain certificates.
>>> 
>>> Indeed, mass surveillance, a lack of easy end-user encryption, a growing
>>> demand for key escrow under legal oversight, and general certificate
>>> authority security concerns create the question: How appropriate is the
>>> continued dependency on PKI when the goal is to advance the benefits of
>>> cloud computing across the technology landscape?
>>> 
>>> Netcraft is the industry standard for monitoring Active TLS
>>> certificates. In May 2015, they stated that “Although the global [TLS]
>>> ecosystem is competitive, it is dominated by a handful of major CAs —
>>> three certificate authorities (Symantec, Comodo, Godaddy) account for
>>> three-quarters of all issued [TLS] certificates on public-facing web
>>> servers.”
>>> 
>>> The Internet Security Research Group's (ISRG) "Let's Encrypt" initiative
>>> aims to make Secure Sockets Layer/Transport Layer Security (SSL/TLS)
>>> certificates available for free in an automated fashion. This a step in
>>> the right direction, in that it removes the risk of profit before
>>> ethics. The real issue, which is one entity acts as a monolithic trust
>>> hierarchy, is not addressed. The monolithic trust hierarchy is a
>>> fundamental design flaw within PKI itself.
>>> 
>>> The rate of attacks against certificate authorities seems to be
>>> [increasing](http://wiki.cacert.org/Risk/History) as the obvious single
>>> point of compromise design inherent to PKI is becoming a more popular
>>> route to carry out attacks.
>>> 
>>> == Proposal ==
>>> Milagro is an open source, pairing-based cryptographic platform to solve
>>> key management, secure communications, data governance and compliance
>>> issues that are challenging Cloud Providers and their customers.
>>> 
>>> It does this without the need for certificate authorities, putting into
>>> place a new category of service providers called Distributed Trust
>>> Authorities (D-TA's).
>>> 
>>> The M-Pin protocol, and its existing open-source MIRACL implementation
>>> on which Milagro will build, are already in use by Experian, NTT, Odin,
>>> Gov.UK and are being rolled out at scale for zero password multi-factor
>>> authentication and certificate-less HTTPS / secure channel.
>>> 
>>> It is proposed that Milagro enter incubation at Apache.  At the same
>>> time, a draft standard for M-Pin has been prepared and recently
>>> submitted to IETF.  The standards process at IETF and the platform
>>> implementation at Apache will run in parallel.
>>> 
>>> === Why Pairing-Based Cryptography, why now? ===
>>> Over the last decade, pairings on elliptic curves have been a very
>>> active area of research in cryptography. Pairings map pairs of points on
>>> an elliptic curve into the multiplicative group of a finite field. Their
>>> unique properties have enabled many new cryptographic protocols that had
>>> not previously been feasible.
>>> 
>>> Standards bodies have already begun standardizing various pairing-based
>>> schemes. These include the IEEE, ISO, and IETF. Besides identity-based
>>> encryption (IBE), the standardized schemes include identity-based
>>> signatures, identity-based signcryption, identity-based key
>>> establishment mechanisms, and identity-based key distribution for use in
>>> multimedia.
>>> 
>>> NIST has also recommended the standardization and adoption of
>>> pairing-based cryptographic systems __for government agencies__. In the
>>> NIST "Report on Pairing-based Cryptography" issued in February 2015,
>>> they state:
>>> 
>>> "It has been a decade since the first IBE schemes were proposed. These
>>> schemes have received sufficient attention from the cryptographic
>>> community and no weakness has been identified. IBE is being used
>>> commercially, primarily by Voltage Security and Trend Micro. Intel’s
>>> EPID scheme is another example of pairings being used commercially. > As
>>> a result of our study, we believe there is a good case for allowing
>>> government agencies to use pairings. Pairings have been shown to have
>>> numerous applications, helping to solve problems that are impossible,
>>> difficult, or inefficient with traditional public-key cryptography or
>>> symmetric encryption."
>>> 
>>> The biggest beneficiary of these new pairing-based cryptographic
>>> protocols will be the Cloud Infrastructure as a Service industry.
>>> Pairing-based cryptography can provide real world solutions, right now,
>>> to the outstanding issues of cryptographic trust, data security,
>>> governance and compliance that create roadblocks to adoption of the
>>> Cloud by the industries that can most benefit from it.
>>> 
>>> Pairing cryptography also makes possible the world in which a fleet of
>>> geographically distributed and organizationally independent Distributed
>>> Trust Authorities act as multiple private-key generators (PKGs) where
>>> trust need not reside in a single entity.
>>> 
>>> The difference between this new world of Distributed Trust Authorities
>>> and the current PKI system will be a landscape that provides secure
>>> ease-of-use encryption and authentication, does not rely upon a single
>>> trusted third party, and yet allows for limited key escrow subject to an
>>> end customer's requirement.
>>> 
>>> === Milagro ===
>>> The Milagro libraries and tools consist of:
>>> 
>>>  * Distributed Key Management Service API
>>>  * Distributed Key Management CLI
>>>  * Software Defined Distributed Security Module (SD-DSM) build platform
>>>  * Distributed Key Management Endpoints (software)
>>>  * Crypto Apps, consisting of:
>>>   * M-Pin Authentication Platform (delivering password-less 2FA)
>>>    * M-Pin Secure Channel (delivering certificate-less TLS-PSK)
>>>    * M-Pin-in-Mobile Client Libraries for iOS, Android and Windows Phone
>>>    * M-Pin-in-Javascript Libraries for Browsers
>>>   * Cloud Encryption Gateway (under nascent development)
>>>   * Distributed Trust Authority Crypto App
>>>   * Generic library for IoT cryptographic library
>>> 
>>> The startingpoint for these is the existing MIRACL library and tools at
>>> http://github.com/Certivox/
>>> 
>>> === Distributed Trust Authorities ===
>>> The Milagro project introduces a service concept called a Distributed
>>> Trust Authority, to replace either single-authority certificates or
>>> public key infrastructure.
>>> 
>>> The D-TA splits the functions of a pairing-based key generation server
>>> into three services issuing thirds of private keys to distinct
>>> identities. The shares of the private keys, received by Crypto App
>>> clients or Distributed Key Management Endpoints, become the only
>>> entities that possess any knowledge of the whole key created from the
>>> shares.
>>> 
>>> To effect anything resembling a root key compromise that can occur in a
>>> traditional PKI or commercial certificate authority, ***ALL***
>>> Distributed Trust Authority servers must be compromised.
>>> Cryptographically, one compromise of a Distributed Trust Authority does
>>> not yield an attacker any advantage, all Distributed Trust Authority
>>> master secrets inside each D-TA providing shares must be compromised.
>>> Note that all 3 D-TA's operate independently and are under separate
>>> organizational control.
>>> 
>>> For the following examples, envision a Distributed Trust Authority model
>>> consisting of Cloud Provider (D-TA 1), Cloud Provider end customer (D-TA
>>> 2) and neutral third party (D-TA 3).
>>> 
>>> Under this three participant model, where each member is responsible for
>>> the security of their D-TA, the Cloud Provider can not subvert the
>>> security of the end customer, even with the collusion of the neutral
>>> third party. The end customer will not suffer an internal insider attack
>>> unless the Cloud Provider and neutral third party also collude.
>>> 
>>> === Distributed Key Management API, CLI, Endpoints ===
>>> The core infrastructure that consumes these thirds of private keys and
>>> is responsible for their distribution is a message bus and API (D-KMS
>>> API), a command line interface (CLI) and software (D-KMS Endpoints)
>>> which builds the Crypto Applications from source.
>>> 
>>> Any entity can run any mix or combination of components with other
>>> entities, but there is no restriction on configuration. One party may
>>> operate all three D-TAs, Endpoints and APIs if they wish.
>>> 
>>> The D-KMS CLI communicates securely with the API. The API is responsible
>>> for either creating cryptographic keys and secrets or protecting
>>> existing keys and secrets through cryptographic encapsulation, via a
>>> choice of pairing-based protocols. In either case, the API encapsulates
>>> the keys and secrets for the identity of particular D-KMS Endpoints.
>>> 
>>> The D-KMS Endpoints are server operating systems with D-KMS Endpoint
>>> software installed. The D-KMS Endpoint software, in conjunction with the
>>> D-KMS CLI, has the appropriate pairing-based cryptographic keys to be
>>> able to de-encapsulate secrets and keys received from the D-KMS API.
>>> These de-encapsulated secrets and keys can be stored, distributed or
>>> used in Crypto Applications, such as M-Pin Authentication, Secure
>>> Channel or Encryption Gateway.
>>> 
>>> === SD-DSM / Crypto Applications ===
>>> Software Defined Distributed Security Modules, otherwise known as Crypto
>>> Applications "Crypto Apps" get compiled from source files on-demand.
>>> Crypto App source files will be hosted on major public repositories such
>>> as Github and Apache.
>>> 
>>> Crypto Applications are scaled across the datacenter through the D-KMS
>>> API in conjunction with orchestration tools such as Apache Mesos and
>>> consume the de-encapsulated secrets and keys.
>>> 
>>> ==== M-Pin Authentication and Secure Channel ====
>>> M-Pin is already deployed by such organizations as NTT and Experian in a
>>> two node Distributed Trust Authority model, where MIRACL and its
>>> customer each host a D-TA node. In Experian's case, M-Pin was selected
>>> to provide authentication for Experian's identity assurance platform,
>>> contracted to the UK Government, for secure authentication of online
>>> citizens into UK government websites, including HMRC (tax office). M-Pin
>>> was selected based on its security efficacy and ability to scale to an
>>> Internet scale user population (UK online citizenry).
>>> 
>>> The M-Pin Authentication Platform serves as an example of what is
>>> possible exploiting a pairing based protocol. M-Pin is capable of
>>> running in a native browser mode, delivering two-factor authentication.
>>> M-Pin binds to any identity (as long as it is worldly unique) and
>>> improves the user authentication experience as it can be visualized in a
>>> familiar ATM-style pin pad.
>>> 
>>> It's most unique trait is the exploitation of zero knowledge proof
>>> authentication. The M-Pin Client proves to the M-Pin Server it possesses
>>> its cryptographic authentication key without revealing it to the server.
>>> As a result, the M-Pin Server stores no authentication credentials,
>>> eliminating the possibility of credential (i.e., password) smash n' grab
>>> attacks.
>>> 
>>> M-Pin Secure Channel extends the protocol to include authenticated key
>>> agreement between server and client and mutual client-server
>>> authentication. The 'agreed key' is unique for each session, possessing
>>> perfect forward secrecy.
>>> 
>>> M-Pin Secure Channel takes the agreed key and injects the key into a
>>> TLS-PSK session between client and server, providing mutual
>>> authentication and perfect forward secrecy without the need for PKI.
>>> This cryptographic underpinning can be extended to create secure VPN
>>> sessions over various protocols.
>>> 
>>> In an M-Pin client and server context, clients and servers receive their
>>> shares of their private keys from all three Distributed Trust
>>> Authorities. In the previously mentioned example, this could be Cloud
>>> Provider, end customer and neutral third party or any combination
>>> thereof.
>>> 
>>> M-Pin Client and Server code are already open source, having been
>>> previously released under BSD-Clause-3.
>>> 
>>> The next iteration and revision will be licensed under the Apache
>>> License.
>>> 
>>> ==== Cloud Encryption Gateway ====
>>> Many proprietary solutions have appeared on the information security
>>> market to solve data governance issues about securing data in the cloud
>>> with encryption keys managed by an end customer. To date, most of these
>>> solutions involve purchasing hardware or virtualized appliances to run
>>> in an end customer's datacenter, with nothing more delivered than a
>>> single encryption key under control of the end customer, performing
>>> sub-optimum deterministic encryption on data sent to the cloud.
>>> 
>>> The Milagro Cloud Encryption Gateway will be a virtualized or container
>>> based software, deployed in an end customer's environment. This CEG will
>>> exploit pairing-based capabilities such as attribute-based encryption
>>> (anyone in possession of the correct set of attributes can decrypt) and,
>>> more generally, predicate-based encryption (anyone in possession of the
>>> right set of attributes and a decryption key corresponding to a
>>> particular predicate can decrypt).
>>> 
>>> Doing so increases the flexibility of the solution by being enabled to
>>> address data residency and governance requirements such as geo-location
>>> while allowing key management and rotation protocols to be enforced.
>>> 
>>> == Rationale ==
>>> The benefits of a strong authentication, secure channel and cloud
>>> encryption via an identity framework for people and things are
>>> self-evident, and the plethora of homebrew proprietary solutions and
>>> password nightmares seen today is clear evidence of a need for better
>>> solutions.
>>> 
>>> Milagro's distributed trust model is particularly attractive, by virtue
>>> of dispensing with need for (and potential for abuse of) any central
>>> trust authority without requiring sophistication - such as understanding
>>> a Web of Trust - from end users.
>>> 
>>> A move to incubation at Apache will help the community to grow and take
>>> on new members in an environment that guarantees open development and
>>> protection of participants.
>>> 
>>> This is particularly relevant right now as a second corporate team, NTT
>>> Data, with its own culture joins as core developers. For the outside
>>> world, it offers the strong promise of openness.
>>> 
>>> == Initial Goals ==
>>> Milagro will seek to integrate the existing projects at Certivox (now
>>> MIRACL) and NTT, and will invite participation from a nascent broader
>>> community evidenced by the core MIRACL library's 65 watchers and 29
>>> forks at Github.
>>> 
>>> As well as looking to broaden direct participation, it will seek
>>> synergies with relevant Apache projects, for example by providing
>>> Milagro plugins for HTTPD and Trafficserver.
>>> 
>>> The initial software products will be the current standing M-Pin Core
>>> platform, client libraries and the SD-DSM and Distributed Key Management
>>> API and client CLI (as noted above).
>>> 
>>> == Current Status ==
>>> Certivox (now MIRACL) has developed open source software at Github since
>>> 2014, though the core MIRACL library goes back much further. Projects
>>> currently at Github include the M-Pin Authentication Platform and the
>>> MIRACL cryptographic libraries under BSD-Clause-3 and AGPL licenses.
>>> 
>>> These have attracted both community and corporate interest taking them
>>> beyond the realm of a single-company project, with NTT being the second
>>> corporate team to take a substantial part in development.  The project
>>> now seeks to transition smoothly to a full Open Development model.
>>> 
>>> The core team at Certivox (now MIRACL) is geographically dispersed and
>>> developers are well-accustomed to using online infrastructure and tools
>>> for their everyday work.  The team at NTTi3 and NTT DATA and other
>>> contributing developers are included amongst the initial committers.
>>> 
>>> In addition to MIRACL operating a community D-TA, NTT, Experian and
>>> Dimension Data have all agreed to host no-charge community D-TAs.  Other
>>> cloud providers are considering and have been engaged. An open source
>>> platform from which to offer these services is a necessary component to
>>> finalizing and launching community D-TA's.
>>> 
>>> == Meritocracy and Community ==
>>> The project is moving from a single (startup) company open source
>>> project seeking a wider community, to embrace a second corporate
>>> development team and third-party developers.  The project is committed
>>> to broadening the community through meritocracy, and expects to welcome
>>> contributions and recognize contributors.
>>> 
>>> It is hoped that incubation at Apache will help with this broadening, by
>>> providing a widely-recognised and well-understood framework for working
>>> collaboratively, growing communities, and protecting contributors.
>>> 
>>> == Core Developers ==
>>> Dr. Michael Scott, Chief Cryptographer at Certivox (now MIRACL), has
>>> been a major open source and standards contributor to the field of
>>> elliptic curve cryptography for over twenty-five years.
>>> 
>>> Others include
>>> 
>>> === Existing team at Certivox/MIRACL: ===
>>>  . Patrick Hilt - CTO
>>>  . Kealan Mccusker - Cryptographer
>>>  . Stanislav Mihaylov - Architect
>>>  . Simeon Aladhem - Developer
>>> 
>>> === Existing team at NTT: ===
>>>  . Go Yamamoto - Cryptographer
>>>  . Kenji Takahishi - Developer
>>> 
>>> === Existing ASF Member: ===
>>>  . Nick Kew - Developer
>>> 
>>> == Alignment: ==
>>> Whereas Milagro has no track record of its own, the Certivox (now
>>> MIRACL) team have been working on related projects at Github.  Being
>>> geographically diverse, the team is well-accustomed to day-to-day
>>> working in a similar environment to Apache and with similar tools and
>>> processes. The anticipated role of Apache is to help the community to
>>> grow without fragmentation of communities, code, or intellectual
>>> property.
>>> 
>>> We are not aware of any link with existing Apache projects.  However, it
>>> is likely that several Apache projects may be interested in working with
>>> Milagro to provide distributed identity services.  Plugins for HTTPD and
>>> Trafficserver are already anticipated.
>>> 
>>> == Known Risks ==
>>> === Orphaned products ===
>>> Milagro, as successor to the existing MIRACL and M-Pin software at
>>> github, is at the core of Certivox (now MIRACL)'s business and important
>>> to NTT, Experian, and other platform adopters who are in the process of
>>> coming online.
>>> 
>>> Interest, and with it both developer and user communities, are expected
>>> to grow strongly.  There is little risk of the project losing momentum
>>> in the foreseeable future.
>>> 
>>> === Experience with Open Source ===
>>> The software has a history as open source, developed until recently by a
>>> geographically distributed team within a single company. Github activity
>>> shows some evidence of a wider community.  The major new development
>>> that leads the proposers to seek incubation at Apache is the coming of
>>> new corporate interest: while both corporate teams have open-source
>>> experience, their cultures and backgrounds differ.
>>> 
>>> We hope that incubation at Apache may help the teams collaborate in an
>>> environment of mutual benefit, as well as attract independent developers
>>> to play a full part.
>>> 
>>> === Homogenous Developers. ===
>>> The established corporate teams are dispersed across several European
>>> countries and Japan.  Prospective developers (whose companies are
>>> interested in Milagro) are located in other countries, and we anticipate
>>> a global community.
>>> 
>>> === Reliance on Salaried Developers ===
>>> Most of the initial committers are salaried developers from the core
>>> corporate teams.  Github activity, including 29 forks of the Miracl
>>> library, indicates wider community interest, and it is hoped that the
>>> developer community will grow substantially at Apache.
>>> 
>>> === Apache Brand ===
>>> The Apache brand is of course seen as an advantage.  However, the
>>> project is more directly concerned with the Apache platform and
>>> environment to unite diverse teams.
>>> 
>>> == Relationships with Other Apache Products ==
>>> See Alignment above.
>>> 
>>> == Documentation ==
>>> Milagro derives from Certivox's existing M-Pin, MIRACL and associated
>>> tools at github.com/Certivox/ Documentation at http://docs.certivox.com/
>>> may also inform and feed into the Milagro project.
>>> 
>>> == Initial Source and Intellectual Property ==
>>> As soon as Milagro is accepted into the Incubator, Certivox (now MIRACL)
>>> will transfer the source code and trademark to the ASF with a Software
>>> Grant, and licensed under the Apache License 2.0. Certivox/MIRACL
>>> retains rights to its existing MIRACL mark.
>>> 
>>> == External Dependencies ==
>>> There are no external dependencies and all software is under the sole
>>> ownership of Certivox/MIRACL.
>>> 
>>> == Cryptography ==
>>> This is advanced cryptographic software, and as such may be subject to
>>> government interest and red tape in some countries. However, the
>>> architecture by which SD-DSM / Crypto Apps are distributed, via open
>>> source freely available code repositories, is intentional to exploit the
>>> near universal interpretation of the Wassenar agreement to permit export
>>> of open source cryptography without restriction (in most cases).
>>> 
>>> == Required Resources ==
>>> Mailinglists:
>>> 
>>>  * private
>>>  * dev
>>>  * users
>>> 
>>> Git repository (to mirror existing github repo)
>>> 
>>>  * https://git-wip-us.apache.org/repos/asf/incubator-milagro.git
>>> 
>>> Issue Tracking
>>> 
>>>  * JIRA repository to be requested
>>> 
>>> ==== Trust Authority Service ====
>>> The podling would like to request a VM at
>>> "ta.milagro[.incubator].apache.org" with which to run a Community Trust
>>> Authority.  It is anticipated that this will serve as a test facility
>>> for developers and may become a Trust Authority for the community of ASF
>>> committers.
>>> 
>>> == Initial Committers ==
>>>  * Akira Nagai             (NTT)
>>>  * Brian Spector           (Certivox/MIRACL)
>>>  * Fuji Hitoshi            (NTT)
>>>  * Genoveffa Pagano        (Certivox/MIRACL)
>>>  * Go Yamamoto             (NTT)
>>>  * Jordan Katserov         (Certivox/MIRACL)
>>>  * Kealan Mccusker         (Certivox/MIRACL)
>>>  * Kenji Takahishi         (NTT)
>>>  * Michael Scott           (Certivox/MIRACL)
>>>  * Milen Rangelove         (Certivox/MIRACL)
>>>  * Mitko Yugovski          (Certivox/MIRACL)
>>>  * Michael Scott           (Certivox/MIRACL)
>>>  * Nick Kew                (Apache)
>>>  * Nick Pateman            (Certivox/MIRACL)
>>>  * Patrick Hilt            (Certivox/MIRACL)
>>>  * Simeon Aladhem          (Certivox/MIRACL)
>>>  * Stanislav Mihaylov      (Certivox/MIRACL)
>>>  * Tetsutaro Kobayashi     (NTT)
>>> 
>>> == Sponsors ==
>>> === Champion ===
>>>  . Nick Kew
>>> 
>>> === Mentors ===
>>>  * Sterling Hughes
>>>  * Jan Willem Janssen
>>>  * Nick Kew
>>> 
>>> === Sponsoring Entity ===
>>>  . The Apache Incubator
>>> 
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
> 
> 
> -- 
> Colm O hEigeartaigh
> 
> Talend Community Coder
> http://coders.talend.com

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message