Contributing to OpenConnect

Contributions to OpenConnect are very welcome. You don't need to be able to write code. Testing, documentation improvements and especially translations are all extremely useful. Some specific suggestions and requests for help can be found below.

Submitting Patches

Patches can be sent to the mailing list or directly to the author in private email. We are also experimenting with using GitLab, so please feel free to file issues and submit merge requests at https://gitlab.com/openconnect/openconnect.

When submitting patches to be included in OpenConnect, please certify that your patch meets the criteria below by including include a sign-off line in your email which looks like this:

Signed-off-by: Random J Developer <random@developer.example.org>

This confirms that you are permitted to submit the patch for inclusion in OpenConnect under the LGPLv2.1 licence. The full text of the certificate is as follows:

What needs doing?

Translations

One of the main things needed at the present time is translations into languages other than English. All contributions will be gratefully received.

Translations for OpenConnect are maintained in the GNOME NetworkManager-openconnect module. Translations can be contributed by joining the GNOME team as described on their TranslationProject wiki page, or simply by editing one of the language files in the po/ directory and sending the resulting patch (or file) to the mailing list.

If there are questions about the messages because the intent is not clear, or if the messages could be improved to make translation easier or better, please also feel free to ask or make suggestions on the mailing list.

Documentation / Web Site

OpenConnect is designed with the principle that "if it needs documenting, fix it instead". That isn't to say that we don't have documentation. But if a user finds something non-obvious and has to look it up in the documentation, then that in itself is a little bit of a usability failure. Software should Just Work™.

So if you find something that is more complex than it needs to be, and you think it should Just Work™ then please don't hesitate to tell us bout it.

Any improvements to the documentation are most welcome. In particular:

Testing

All testing is valuable, and please do let us know if anything doesn't work when you think it should. There are some things which the regular developers don't have easy access to test, some help with testing these would be particularly welcome:

New Protocols

There are some other protocols which would be good to add to OpenConnect. Getting a new protocol to the point where it basically works to send and receive traffic is only a few hours of work, and can be very rewarding.

For some protocols we already know how they work on the wire and it's mostly just a matter of writing the code. For others we might have to observe the existing clients to learn how they work.

These would be great projects for someone to take on as a learning exercise, or perhaps even Google Summer of Code projects.

Suggestions for other protocols which OpenConnect could usefully implement are also welcome.

Other enhancements

One of the main other improvements that would be welcome, is implementing a full WebView in the graphical clients. Currently for protocols like Juniper, OpenConnect screen-scrapes the HTML pages used for login, and attempts to make sense of them. This is The main thing that would be Other items on the TODO list include:

Simplify OpenConnect's approach to interacting with external scripts and program

Currently we have a vast proliferation of slightly different interfaces for OpenConnect to call scripts with slightly different interfaces, despite serving similar purposes.

Routing and DNS configuration

Trojans / security scanners

External/SAML/SSO authentication scripts

Most VPN protocols have some authentication modes which OpenConnect cannot handle on its own using its usual techniques of creating and submitting authentication forms from server-provided data (or screen-scraping). These essentially require running a full web browser environment, due to requiring JavaScript or browser plugins for the authentication to complete.

The individual VPN protocols vary substantially in how the VPN client is expected to communicate with the web browser doing the authentication:

The open_webview hook needs implementing for Qt/KDE and Windows GUIs.

The webview/external-browser options and API functions should perhaps be renamed to something like "external auth handler", since one of the goals and strong points of OpenConnect is to make VPN login interfaces scriptable without relying on a graphical browser in many cases.