Contributors guidance
The application process consists of next steps:
- Become acquainted with application process for GSoC.
- Join to gsoc mailing list: https://groups.google.com/group/google-summer-of-code-announce
- Join libssh mailing list: https://www.libssh.org/communication/
- Search mentor for chosen project in mailing list discuss or propose your own project and find a mentor for it.
- Submit the application/proposal including all requirements at the Google Summer of Code Site.
Requirements before starting search for mentor:
- Clone and build libssh sources: https://www.libssh.org/development/
- Review existing issues in bug tracker and try to solve some simpler one, providing a merge request on gitlab mirror https://gitlab.com/libssh/libssh-mirror/-/issues
- Prepare answers to questions about own participation in project.
Application requirements/recommendations:
- All applications must go through Google’s application system; we can’t accept any application unless it is submitted there.
- Use a descriptive title in Google’s system. Good example: “libssh: Improve SSH connection fuzzing” Bad example: “My gsoc project”
- Make it easy for your mentors to give you feedback. If you’re using Google docs, enable comments and submit a “draft” (we can’t see the “final” versions until applications close). If you’re using a format that doesn’t accept comments, make sure your email is on the document and don’t forget to check for feedback!
- Use the following template for the your project application. It will help you to answer the questions we want to hear answers for and prepare yourself for the project itself: https://docs.google.com/document/d/1H1BDf0gZZkPwTOKuu7cOsPq40DBuOCY8qcF8e49pXUY
GSoC libssh organization administrators:
- Jakub Jelen (jjelen or jakuje on IRC or Matrix)
- Anderson Sasaki (toshisasaki on Matrix)
- Andreas Schneider (asn on Matrix)
Project ideas
async SFTP client
The SFTP implementation in libssh requires application to call libssh API to send each chunk of data, which is not the fastest option. Our idea is that libssh should provide an API similar to io_uring, where you set up the transfer of the file and libssh will take care of the rest.
- Difficulty: hard
- Project length: 350 hours
- Language(s): Good knowledge of C, network programming and IO handling
- Possible Mentors: ??
- References:
Support for OpenSSH connection multiplexing
The OpenSSH supports sharing several sessions over a single TCP connection, which makes opening new channels faster from cli. The usage of the same MUX protocol is not mandatory, but as we already work with openssh configuration files so, it would probably make sense to implement it in compatible way.
- Difficulty: medium/hard
- Project length: 175 hours
- Language(s): Good knowledge of C, knowledge about communication between processes is a plus 😉
- Possible Mentors: Jakub Jelen
- References:
Support for fetching keys from popular secret management apps
The libssh can already use any authentication keys through OpenSSL PKCS #11 engines, which should cover most common secrets management systems. One of these might be TPM 2.0, which bounds the key to particular machine with all its pros and cons. These days, there are different and more modern ways of accessing secrets, for example libsecret, which might be an alternative to PKCS #11.
- Difficulty: Medium
- Project length: 175 hours
- Language(s): Good knowledge of C, knowledge about TPM is a plus
- Possible Mentors:
- Anderson Sasaki
- Jakub Jelen
- References:
Support for OpenSSH certificates
The libssh supports OpenSSH certificates as opaque blobs alongside the client keys only to pass them along with the key to some compatible server to verify the authentication. This is ok for basic interoperability with OpenSSH servers configured to accept certificates signed with Users CA, but it does not cover the server use cases (authenticating users), nor the Hosts CA (authenticating servers to clients) use case at all.
- Difficulty: Medium
- Project length: 350 hours
- Language(s): Good knowledge of C, knowlege about certificates is a plus
- Possible Mentors: Jakub Jelen
- References:
Support for FIDO/U2F keys on the client side
The server side support (signature verification) and key type definitions are in place so authenticating using these keys from openssh client to libssh server should already work. But the libssh clients can not use the U2F based keys as well as it can not be used to enroll the hardware for authentication with ssh.
- Difficulty: Medium
- Project length: 175 hours
- Language(s): Good knowledge of C, knowledge about elliptic curves cryptography or u2f is a plus 😉
- Possible Mentors: Jakub Jelen
- References:
- https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.u2f
- for testing, openssh provides sk-dummy.so, which can simulate fido/u2f devices
Completed projects
Callback based sftp server (2022)
Currently, the sftp server implementation is based on a huge switch handling all the possible messages. Changing to callback-based model can provide much better customization by the library users
- Difficulty: medium
- Project length: 175 hours
- Language(s): Good knowledge of C and network programming
- Possible Mentors: Jakub Jelen
- References:
- The ssh server in libssh is using callback to handle various SSH protocol messages or authentication types
- Student: Zeyu Sheng
- https://summerofcode.withgoogle.com/programs/2022/projects/Hm79LwKE