GitHub

Project is hosted in the Eclipse organization at GitHub.

Eclipse Project for JAX-RS

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Parent Project
Proposal State
Created
Background

This project is created as part of the process of transitioning Oracle Java EE 8 and GlassFish technologies to the Eclipse Foundation as described in The Eclipse Enterprise for Java Project Top Level Project Charter (https://projects.eclipse.org/projects/ee4j/charter).

Scope

Eclipse Project for JAX-RS provides the API and TCK for Java API for RESTful Web Services (JAX-RS), starting from the specification defined by JSR-370.

An implementation for JAX-RS is part of the proposal for Eclipse Jersey.

Description

JAX-RS: Java API for RESTful Web Services (JAX-RS) is a Java programming language API spec that provides support in creating web services according to the Representational State Transfer (REST) architectural pattern.

Why Here?

The top level EE4J project was created consistent with the direction described in The Eclipse Enterprise for Java Project Top Level Project Charter (https://projects.eclipse.org/projects/ee4j/charter).   This project is created under the top level EE4J project as one of Oracle Java EE 8 and GlassFish technologies being transitioned to the Eclipse Foundation.

Initial Contribution

JAX-RS API repository from https://github.com/jax-rs/api

Source Repository Type

The starting point should be JSR 370 (JAX-RS 2.1) but not JSR 339 (JAX-RS 2.0), otherwise we would end up with a lot of confusion in the community as JAX-RS 2.1 is publicly available since months.

I've been working on an implementation of the Jax Rs 2.1 specifications that I would like to publish as an open source project. Any idea when the TCK will be open sourced?

Eclipse Jersey

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Project
Parent Project
Proposal State
Created
Background

This project is created as part of the process of transitioning Oracle Java EE 8 and GlassFish technologies to the Eclipse Foundation as described in The Eclipse Enterprise for Java Project Top Level Project Charter (https://projects.eclipse.org/projects/ee4j/charter).

Scope

Eclipse Jersey provides an implementation for Java API for RESTful Web Services (JAX-RS), starting from the specification defined by JSR-370.

The JAX-RS API and TCK are being proposed as part of the Eclipse Project for JAX-RS project.

Description

Eclipse Jersey is a REST framework that provides a JAX-RS (JSR-370) implementation and more. Jersey provides its own APIs that extend the JAX-RS toolkit with additional features and utilities to further simplify RESTful service and client development. Jersey also exposes numerous extension SPIs so that developers may extend Jersey to best suit their needs.

 

Goals of Jersey project can be summarized in the following points:

  • Track the JAX-RS API and provide regular releases of production quality implementations that ships with GlassFish;
  • Provide APIs to extend Jersey & Build a community of users and developers; and finally
  • Make it easy to build RESTful Web services utilising Java and the Java Virtual Machine.
Why Here?

The top level EE4J project was created consistent with the direction described in The Eclipse Enterprise for Java Project Top Level Project Charter (https://projects.eclipse.org/projects/ee4j/charter).   This project is created under the top level EE4J project as one of Oracle Java EE 8 and GlassFish technologies being transitioned to the Eclipse Foundation.

Initial Contribution

Actual and up to date source code repository from https://github.com/jersey/jersey.

Source Repository Type

I am not able to install Jersey Restful api in Eclipse IDE 4.9.0. It is giving me the error "No repository found at http://oneclicklabs.io/repo/eclipse/plugin/jrest/."

Eclipse Tyrus

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Project
Parent Project
Proposal State
Created
Background

This project is created as part of the process of transitioning Oracle Java EE 8 and GlassFish technologies to the Eclipse Foundation as described in The Eclipse Enterprise for Java Project Top Level Project Charter (https://projects.eclipse.org/projects/ee4j/charter).

Scope

Eclipse Tyrus provides an implementation for Java API for WebSocket, starting from the specification defined by JSR-356.

The API and TCK for WebSocket is part of the Eclipse Project for WebSocket proposal.

Description

Eclipse Tyrus is an open source JSR 356 - Java API for WebSocket implementation for easy development of WebSocket applications. WebSocket protocol defined by IETF provides bi-directional communication between the server and the remote host. The pros are mainly the ability to communicate both ways, low latency and small communication overhead. Therefore Tyrus and WebSocket in general are suitable for web applications that require sending a huge volume of relatively small messages like online games or market ticker broadcasting.

Why Here?

The top level EE4J project was created consistent with the direction described in The Eclipse Enterprise for Java Project Top Level Project Charter (https://projects.eclipse.org/projects/ee4j/charter).   This project is created under the top level EE4J project as one of Oracle Java EE 8 and GlassFish technologies being transitioned to the Eclipse Foundation.

Initial Contribution

Actual and up to date Tyrus code repository from https://github.com/tyrus-project/tyrus.

Source Repository Type

Eclipse OpenMQ

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Project
Parent Project
Proposal State
Created
Background

This project is created as part of the process of transitioning Oracle Java EE 8 and GlassFish technologies to the Eclipse Foundation as described in The Eclipse Enterprise for Java Project Top Level Project Charter (https://projects.eclipse.org/projects/ee4j/charter).

Scope

Eclipse OpenMQ provides an implementation for Java™ Message Service (JMS), starting from the specification defined by JSR-914.

The JMS API and TCK are provided as part of the Eclipse Project for JMS proposal.

Description

Eclipse Open Message Queue (OpenMQ) is a complete message-oriented middleware platform, offering high quality, enterprise-ready messaging.

OpenMQ is included in GlassFish.

Why Here?

The top level EE4J project was created consistent with the direction described in The Eclipse Enterprise for Java Project Top Level Project Charter (https://projects.eclipse.org/projects/ee4j/charter).   This project is created under the top level EE4J project as one of Oracle Java EE 8 and GlassFish technologies being transitioned to the Eclipse Foundation.

Initial Contribution

The initial contribution includes Oracle-owned code from an existing GitHub repository.

Where possible, committers on the existing project will remain contributors to this project.

 

Source Repository Type

Eclipse Grizzly

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Project
Parent Project
Proposal State
Created
Background

This project is created as part of the process of transitioning Oracle Java EE 8 and GlassFish technologies to the Eclipse Foundation as described in The Eclipse Enterprise for Java Project Top Level Project Charter (https://projects.eclipse.org/projects/ee4j/charter).

Scope

The Eclipse Grizzly project provides an NIO framework used by the GlassFish application server.  It does not directly implement any Java standards, but provides the underlying support for Glassfish Java Servlet implementation.

Description

Writing scalable server applications in the Java™ programming language has always been difficult. Before the advent of the Java New I/O API (NIO), thread management issues made it impossible for a server to scale to thousands of users. The Eclipse Grizzly NIO framework has been designed to help developers to take advantage of the Java™ NIO API.

Why Here?

The top level EE4J project was created consistent with the direction described in The Eclipse Enterprise for Java Project Top Level Project Charter (https://projects.eclipse.org/projects/ee4j/charter).   This project is created under the top level EE4J project as one of Oracle Java EE 8 and GlassFish technologies being transitioned to the Eclipse Foundation.

Initial Contribution

The initial contribution includes Oracle-owned code from an existing GitHub repository.  Additional Grizzly-related repositories will be contributed at a later date.

Where possible, committers on the existing project will remain contributors to this project.

Source Repository Type

Eclipse Mojarra

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Project
Parent Project
Proposal State
Created
Background

This project is created as part of the process of transitioning Oracle Java EE 8 and GlassFish technologies to the Eclipse Foundation as described in The Eclipse Enterprise for Java Project Top Level Project Charter (https://projects.eclipse.org/projects/ee4j/charter).

Scope

Eclipse Mojarra provides the API, TCK, and an implementation for JavaServer™ Faces, starting from the specification defined by JSR-372.

(Note:  The API and TCK will be parsed into a separate Eclipse project once this initial project population for EE4J is complete.)

Description

Eclipse Mojarra is an implementation for the JavaServer Faces specification (JSR-372). JavaServer Faces (JSF) is a Java specification for building component-based user interfaces for web applications. It is also a MVC web framework that simplifies construction of user interfaces (UI) for server-based applications by using reusable UI components in a page.

Mojarra is included in GlassFish.

Why Here?

The top level EE4J project was created consistent with the direction described in The Eclipse Enterprise for Java Project Top Level Project Charter (https://projects.eclipse.org/projects/ee4j/charter).   This project is created under the top level EE4J project as one of Oracle Java EE 8 and GlassFish technologies being transitioned to the Eclipse Foundation.

Initial Contribution

The initial contribution includes Oracle-owned code from an existing GitHub repository.

Where possible, committers on the existing project will remain contributors to this project.

Source Repository Type

  • Call out that Mojarra is the RI for the 2.3 version of the specification in particular.

Otherwise looks great.

Eclipse Project for JSON Processing

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Parent Project
Proposal State
Created
Background

This project is created as part of the process of transitioning Oracle Java EE 8 and GlassFish technologies to the Eclipse Foundation as described in The Eclipse Enterprise for Java Project Top Level Project Charter (https://projects.eclipse.org/projects/ee4j/charter).

Scope

Eclipse Project for JSON-P provides the API, TCK, and an implementation for Java API for JSON Processing, starting from the specification defined by JSR-374.

Description

Eclipse Project for JSON-P is a Java API to process (e.g. parse, generate, transform and query) JSON documents. It produces and consumes JSON in a streaming fashion (similar to StAX API for XML) and allows to build a Java object model for JSON using API classes (similar to DOM API for XML).

Why Here?

The top level EE4J project was created consistent with the direction described in The Eclipse Enterprise for Java Project Top Level Project Charter (https://projects.eclipse.org/projects/ee4j/charter).   This project is created under the top level EE4J project as one of Oracle Java EE 8 and GlassFish technologies being transitioned to the Eclipse Foundation.

Initial Contribution

Actual and up to date Eclipse JSON Processing code repository from http://github.com/javaee/jsonp.

Source Repository Type

Eclipse Project for MVC

Date Review
never
Date Trademark
never
Date Provisioned
never
Date Initial Contribution
never
Date Initial Contribution Approved
never
This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Parent Project
Proposal State
Draft
Project Scheduling

The initial contribution will be made as soon as practically possible after the transfer has been approved by the JCP Executive Committe.

Committers
Ivar Grimstad

Eclipse Kuksa

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Project
Parent Project
Proposal State
Created
Background

Eclipse Kuksa provides technologies across the connected vehicle domain.

Automotive systems especially lack open technologies that are accessible to developers and enterprises focusing on IoT (Internet of Things) systems or cloud applications. Eclipse Kuksa closes these gaps and provides the comprehensive ecosystem to address related challenges with the help of platforms for (a) in-vehicle, (b) cloud, and (c) connected vehicle applications development. The publicly funded European ITEA research project APPSTACLE forms a basis for addressing such challenges. Eclipse Kuksa will further bring the ecosystem into the Eclipse community in order to widen its applicability and usage amongst and beyond its project partners such as Ericsson, Bosch, NXP and others.

The name Kuksa has its origins in a carved wooden mug from Finland. A Kuksa, with its individual character, has to be shared with and eventually bequeathed by close friends and cannot be bought for oneself. This sharing, as well as the connection that extends across generations, is meant also to reflect the spirit of the open source Eclipse Kuksa project.

Scope

Eclipse Kuksa unifies technologies across the vehicle, IoT, cloud, and security domains in order to provide an open source ecosystem to developers addressing challenges of the electrified and connected vehicle era. In-vehicle and cloud applications as well as their development infrastructure, maintenance approaches, security, and over-the-air (OTA) update and upgrade management are, with a few exceptions, completely within the scope of Eclipse Kuksa.

Currently, vehicle connectivity applies to mobile networks (and related infrastructure such as clouds, servers, etc.), other vehicles, and local infrastructures (traffic lights, local entities cf. edge computing). Although proprietary approaches provide partial solutions, developers have no access to either open source solutions nor comprehensive ecosystems that allow common connected vehicle development initiatives across suppliers, original equipment manufacturer (OEM), and tooling enterprises. Eclipse Kuksa brings comprehensive connectivity solutions to the public while combining diverse technologies of vehicle, IoT, cloud, and security domains.

While safety is out of scope, Eclipse Kuksa addresses maintenance through providing, but not applying, OTA updates or upgrades, Cloud, and in-vehicle applications, as well as state-of-the-art platforms and technologies for in-vehicle communication and data transmission. Demonstration applications will be made available, but sophisticated cloud and in-vehicle applications are generally subject to community or closed-source development processes. Working with this premise, Eclipse Kuksa will support all the necessary development technologies required for such applications.

Description

Because today's software-intensive automotive systems are still developed in silos by each car manufacturer or OEM in-house, long-term challenges in the industry are yet unresolved. Establishing a standard for car-to-cloud scenarios significantly improves comprehensive domain-related development activities and opens the market to external applications, service provider, and the use of open source software wherever possible without compromising security. Connectivity, OTA maintenance, automated driving, electric mobility, and related approaches increasingly demand technical innovations applicable across automotive players.

The open and secure Eclipse Kuksa project will contain a cloud platform that interconnects a wide range of vehicles to the cloud via in-car and internet connections. This platform will be supported by an integrated open source software development environment including technologies to cope especially with software challenges for vehicles designed in the IoT, Cloud, and digital era.

This ecosystem will provide a comprehensive environment across various frameworks and technologies for (a) the in-vehicle platform, (b) the cloud platform, and (c) an app development IDE - that is, the complete tooling stack for the connected vehicle domain (see Figure 1 below). Essential to this environment will be the capabilities for collecting, storing, and analysing vehicle data in the cloud as well as the transmission of diverse information such as cloud calculation results (e.g. improved routing), software maintenance updates or even complete new applications. While many IoT solutions exist in the Eclipse IoT ecosystem, Eclipse Kuksa combines the necessary existing technologies and fills the gaps for the specific requirements of the connected embedded real-time nature of the automotive domain.

Why Here?

Eclipse is widely used in the automotive software industry as well as the IoT domain. Eclipse Kuksa will add value to the Eclipse community by establishing a connected vehicle ecosystem consisting of three major platforms. The ecosystem will be a basis for building customized, proprietary, open- and closed source systems. The Eclipse Kuksa project expects to benefit from wider visibility in the community and an extended open collaboration with interested parties.

Technical details and cooperation:

  • The Eclipse Kuksa ecosystem is built on existing Eclipse Frameworks such as:
    • Eclipse Hono (Cloud backend and frontend, message routing)
    • Eclipse Hawkbit (device management, OTA)
    • Eclipse Ditto (digital twins: abstraction levels, synchronization, state,....)
    • Eclipse Leshan (IoT management, lightweight m2m)
    • Eclipse MosQuitto (MQTT)
    • Eclipse Keti (Security)
  • More technologies likely to be used:
    • Eclipse Sumo (traffic simulation)
    • Keycloak (identity access management, security)
    • Automotive Grade Linux (AGL, in-vehicle basis platform)
    • Eclipse BIRT (Dev IDE visualizations)
    • InfluxDB, REST API, ...
Project Scheduling
  • Initial contribution expected by Q1 2018 (Kuksa 0.1)
  • Release cycle for the cloud platform is planned every 6 months (Kuksa 0.2 by Q3 2018, etc.)

  • With the end of the publicly funded APPSTACLE project, the first major release Eclipse Kuksa 1.0 is expected

  • In-vehicle and APP Dev IDE development activities are not planned yet

Future Work

Eclipse Kuksa will combine the technologies mentioned in the 'Why Here?' section in order to establish the comprehensive ecosystem that securely allows using vehicle data and transmitting generated cloud results. Concurrent work packages thereby address connectivity challenges, demonstrations, as well as cloud and in-vehicle implementations. By Q4 2018, the infrastructure should be complete and by Q4 2019 the ecosystem should be fluently working with the demonstrators and libraries and APIs should allow tailoring cloud applications towards individual needs.

In order to grow the community around Eclipse Kuksa, its development will be spread across research publications at conferences, workshops, booths, or similar events as well as newsletters around the cloud, IoT, and automotive domains. Consequently, interested and related developers will clearly notice Eclipse Kuksa's benefits and hopefully participate at its open source basis. Already its close relationship with other projects will strengthen Eclipse Kuksa's dissemination. Additionally, the involved partners of the publicly funded APPSTACLE project will utilise Eclipse Kuksa around their developments and include it for customer related projects.

Committers
Johannes Kristan
Lukas Krawczyk
Ahmad Bani Jamali
Steffen Evers
Susan Iwai
Peer Adelt
Mentors
Interested Parties
  • Robert Bosch GmbH

  • Dortmund University of Applied Sciences and Arts

  • NXP Semiconductors

  • Technical University Eindhoven

  • Ericsson

  • Behr-Hella Thermocontrol GmbH

  • Paderborn University

  • SecurityMatters

  • University Oulu

  • taskit GmbH

  • Technolution

  • Halian Ltd

  • Link Motion

  • Tieto

  • Assystem GmbH

Initial Contribution

 Eclipse Kuksa will be divided into several repositories:

Github (basically for in-vehicle developments)

  1. Kuksa.AGL (wrapper: scripts, separate builds for different licenses)
  2. Kuksa.meta (recipes to utilize basic Kuksa technologies, e.g., regarding Eclipse Hono, Eclipse Mosquitto, ... )
  3. Kuksa.meta-dev (recipes to utilize development tooling such as debugging, tracing, logging, ...)
  4. Kuksa.meta-rover (available at https://github.com/mozcelikors/meta-rover)
  5. Kuksa.docs (rst - sphinx - travis CI to build documentation webpage)

  6. More Kuksa layers subject to community

 

Eclipse (IDE and bindings / libs)

  1. org.eclipse.kuksa (IDE - plugins and build to support cloud and in-vehicle application development activities)

  2. org.eclipse.kuksa-apps (e.g. for cloud related components. The initial contribution will contain a Spring Boot application with docker scripts to connect an Eclipse Hono instance with a consumer to allow parsing, storing, and visualizing any registered client's raw data)

  3. org.eclipse.kuksa-hono (AGL bindings for Hono)

  4. org.eclipse.kuksa-mqtt (AGL bindings for MQTT)

  5. More binding repos very likely to be required

Source Repository Type

Eclipse CogniCrypt

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Parent Project
Proposal State
Created
Background

For years, cryptography experts have been working on providing software developers with novel cryptographic algorithms that are more long-term secure [1] and/or provide additional functionality such as schemes that allow certain planned alterations to encrypted data [2]. Unfortunately, despite those efforts, recent studies have shown that even applications that use rather basic cryptography are still by and large inherently insecure [3]. This is not because the vulnerabilities in those applications are rooted in the cryptographic algorithms they use but instead in how those applications use those algorithms [4]. Most algorithms are hard to configure correctly, and the appropriate application interfaces (APIs) allow for many insecure usages, while only few are secure. It should not be a huge surprise then that cumulative NVD statistics for years 2013-2015 ranks Cryptographic Issues as the fourth largest category of problems, only slightly behind Access Control issues [5].

The problem is caused by a mismatch in expertise: crypto libraries are written by crypto experts, and use a terminology mostly accessible to such experts but not to general code developers. The goal of this project is to help bridge this gap through dedicated tooling.

In 2014 the German Research Foundation (DFG) has established at Technische Universität Darmstadt the Collaborative Research Center CROSSING (Cryptography-Based Security Solutions: Enabling Trust in New and Next Generation Computing Environments). Within this center, which will be publicly funded for up to 12 years, researchers of around the research groups of Prof. Mira Mezini and Prof. Eric Bodden (now at Paderborn University) have taken on the problem of Secure Integration of Cryptographic Software. Within the past years, those researchers have sought to develop a tool-based approach that will support developers in integrating off-the-shelf cryptographic components in the form of cryptographic APIs securely into application code, using features spelled out below. To make this functionality widely available to (Java) developers the team now seeks to offer it through the Eclipse platform.

[1] An Unconditionally Hiding and Long-Term Binding Post-Quantum Commitment Scheme, Cabarcas et al., Technical Report, June 2015.

[2] Homomorphic Signature Schemes - A survey, Traverso et al, SpringerBriefs in Computer Science, June 2015.

[3] An empirical study of cryptographic misuse in Android application. Egele et al. CCS 2013, November 2013; Why eve and Mallory love Android: an analysis of Android SSL (in)security, Fahl et al., CCS 2012

[4] Jumping Through Hoops: Why do Java Developers Struggle With Cryptography APIs? (Sarah Nadi, Stefan Krüger, Mira Mezini, Eric Bodden), In International Conference for Software Engineering (ICSE), pages 935–946, 2016.

[5] Why does cryptographic software fail?, Lazar et al., APSys 2014, June 2014. [5] https://nvd.nist.gov/cwe.cfm

 

 

Scope

Eclipse CogniCrypt will be restricted to supporting developers in using existing cryptographic APIs. The development of novel cryptographic APIs (or novel versions of existing crypto APIs) will be out of scope for this project.

The project will be specific to cryptographic libraries for popular programming languages, initially for Java, later maybe also for C/C++. The secure integration of security APIs that are not related to crypto is out of scope for this project.

The secure integration will be supported by development-time tooling including code generation and static analysis. The tooling is meant to work on incomplete programs. Hence, dynamic techniques such as dynamic analysis or dynamic security testing are out of scope for this project, as they would require a runnable program.

Description

Eclipse CogniCrypt is planned as a set of Eclipse plugins, which to developers ultimately are meant to provide the following features:

  • Generation of secure crypto-integration code
  • Static analysis of existing crypto-integration code (to automatically and instantly highlight insecure integrations)
  • Suggest better/more secure integrations via quick fixes
  • Alert developers of security breaches of cryptographic algorithms

The project will initially support Java and Android projects only, through an integration with the JDT/ADT projects. In the future we might add support for C/C++ through an integration with CDT.

CogniCrypt's code-generation and static-analysis features are configured through crypto-library specifications, which are written in a domain-specific language called CrySL (Crypto Specification Language). CrySL specifications are written once, and then regularly maintained over time, by cryptography experts. This is supported by additional Eclipse plugins who support an XText-based editor for CrySL.

Initially, the project will provide built-in CrySL specifications for the Java Cryptographic Architecture (JCA), the default crypto API that ships with the Java Development Kit. At a later point in time, we plan to also provide CrySL specifications for other widely used crypto libraries such as BouncyCastle. The way CogniCrypt's tool support is designed, this will then automatically allow CogniCrypt to also support developers using those crypto libraries with targeted code generation and static analysis. CogniCrypt will be designed as an open framework, providing extension points allowing others to plug in CrySL specifications for other libraries as well. In particular, other researchers of CROSSING (see above) have signalled an interest in providing specifications for crypto libraries they themselves are developing as part of the CROSSING project. 

Lastly, we might want to extend CogniCrypt with functionality to discover, download and install cryptographic libraries into Java/Android/C/C++ projects, jointly with their respective CrySL specifications, and to update them in cases where CogniCrypt has learned that a paritcular version of their implementation has been broken. This would require the CogniCrypt plugins to communicate with a web service giving information about those cryptographic libraries (and potentially even hosting copies of them).

Why Here?

Eclipse CogniCrypt, albeit in a rather mature state already, is currently an academic project, and its development is currently dependent on funding by the German Research Foundation (DFG). For 2017-2018, the project receives additional funding through an Oracle Collaborative Research Award. As we see the functionality provided by CogniCrypt as an essential one, we hope to sustain it for a long period of time. Sustainable development, however, could best be achieved by having others join into CogniCrypt's collaborative development.

We particularly hope that in the future external contributors will help provide CrySL specifications for cryptographic libraries that CogniCrypt does not currently cover, but, of course, we invite others to contribute to the further development of CogniCrypt itself as well.

By transitioning this project into the Eclipse ecosystem, we hope to create a win-win situation in which the project itself will gain visibility and attract external contributors, and where the project itself can yield a useful addition to the Eclipse IDE, protecting potentially millions of Java developers from security-critical programming mistakes.

Project Scheduling

The initial contribution is planned for December 2017. We hope to have a first stable version ready for release by February 2018.

Future Work
  • Add support for the generation of secure crypto-integration code
  • Add support for suggesting better/more secure integrations via quick fixes
  • Add support for alerting developers of security breaches of cryptographic algorithms
  • Enhance the XText-based CrySL editor, for instance with more comprehensive type checks

Potentially also:

  • Add support for C/C++ projects. This will require the integration of another static analyzer (different from Soot).
  • Add support for other cryptographic libraries (in the form of appropriate CrySL specifications), besides the JCA. We hope that others will provide such support as well.
  • Add support for discovering, downloading and installing cryptographic libraries into Java/Android/C/C++ projects, jointly with their respective CrySL specifications, and to update them in cases where CogniCrypt has learned that a paritcular version of their implementation has been broken.
Project Leads
Committers
Stefan Krüger
Johannes Späth
Interested Parties
Initial Contribution

The initial contribution will include first implementations of the following components:

  • A static analyzer able to detect misuses of Java crypto APIs in Java (and Android) projects. The analyzer will be able to detect misuses of any crypto library for which a CrySL specification exists.
  • An Eclipse plugin, based on XText, which allows one to create and edit CrySL specifications.
  • An initial, comprehensive CrySL specification for the Java Cryptographic Architecture (JCA), the default crypto API that ships with the Java Development Kit.
  • An Eclipse plugin, integrating with the JDT, that will invoke the static analyzer whenever saving a source-code file within a Java project that makes use of the JCA. The plugin will show erros/warnings as gutter annotations and in the appropriate problems view.
  • A documented extension point that lets others add support for additional crypto libraries (besides the JCA). Our own JCA support will plug into this extension point, thus providing an example for others who seek to implement such an extension.
Source Repository Type