TDF Community Blog

Note: for questions asked about this tender and their respective answers, please see the bottom of this page

We are extending the application deadline.

The deadline for questions stays as in the original tender: June 15, 2021
The deadline for applications has been extended to: June 24, 2021

The Document Foundation (TDF) is the charitable entity behind the world’s leading free/libre/open source (FLOSS) office suite LibreOffice.

We are looking for an individual or company to implement Curl based HTTP/WebDAV UCP.

The work has to be developed on LibreOffice master, so that it will be released in the next major version.

The task consists of addressing two problems. All of the mentioned features and requirements are a mandatory part of this tender and therefore have to be part of the bid. This tender does not contain any optional items.

Problem description #1 – Currently we need to bundle crypto libraries

• TDF releases of LibreOffice bundle both OpenSSL and NSS, but both libraries have a high number of security issues.
• On macOS and Windows, neither OpenSSL nor NSS integrate with the crytographic APIs supplied by the operating system, so they will use a bundled hard-coded set of trusted certificate authorities (CAs), that is different from what the operating system itself would trust. This hard-coded set of trusted certificates is also not user-modifiable.
• Additionally, OpenSSL cannot ever be used from the system because it has no application binary interface (ABI).

Problem description #2 – Currently we duplicate and use different HTTP/WebDAV UCPs

• One which is used by everybody, including TDF releases, using a bundled Neon WebDAV library. This requires OpenSSL and cannot be used on a hypothetical Apple iOS port.
• Another (for a hypothetical Apple iOS port) using a bundled Serf library. This requires OpenSSL.
  • Serf does not actually support WebDAV directly, only HTTP, so the UCP itself implements the additional WebDAV protocol features.
  • It is complicated to build, as it drags in two other bundled external libraries.
  • Additionally, this cannot be upgraded to a current version without introducing a new build dependency on the “scons” tool.
• TDF releases also bundle the Curl library.
  • This can can do HTTP, likely similar to Serf.
  • Also, it can use native operating system cryptographic APIs and trusted certificate authorities (CAs) on Windows, macOS and Linux.
  • It can be used on Apple iOS without problems. (iOS deliverables are not part of this tender.)

The solution we seek, and as such the scope of this tender, is to implement a HTTP/WebDAV UCP with Curl, possibly based on code from the Serf UCP, to solve these issues, by getting rid of four bundled external libraries and one hard OpenSSL dependency. Besides addressing the above issues, the new Curl-based implementation needs to be at least as functionally complete as the existing Neon-based one.

All technology standards of relevance, as well as their targeted versions for this tender should be declared or defined in the offer’s description of implementation (e.g. name and version of the cryptographic API on the respective operating systems).

A key item of the deliverables for this tender, and therefore also a decision criteria – besides qualification, references, price, and completeness of fullfilment – is extensive documentation about the approach chosen to implement the above items, covering more than just the pure implementation. We expect bidders to provide documentation on both the code and the non-code parts of this tender, e.g. methodology, structure and technical aspects.

The Document Foundation will publish this under a free and open source license and make it available to the general public. Another criteria for the evaluation of the bids will be the description of the required test activities and the delivery of (automated) tests supporting work items for the described tender implementation or feature specification.

Required skills

• Extensive knowledge of C++
  Experience working on the LibreOffice source code

Other skills

• English (conversationally fluent in order to coordinate and plan with members of TDF)

We use free, libre and open source (FLOSS) software for development wherever possible, and the resulting work must be licensed under the Mozilla Public License v2.0.

TDF welcomes applications from all suitably qualified persons regardless of their race, sex, disability, religion/belief, sexual orientation or age.

Bidders will get a preference for including a partner or independent developer who has not been involved in a successful tender before. For such developers, who have not yet been part of a successful tender bid, we aim on a best-effort basis, but without any guarantees whatsoever, to provide some mentoring in understanding the code base and the process in contributing to the code. We expect that time and efforts on the bidder’s side for this should not be part of the paid work for this tender. Please mention such need of LibreOffice development mentoring in your offer.

As always, TDF will give some preference to individuals who have previously shown a commitment to TDF, including but not limited to certified developers and/or members of TDF. Not being a member, or never having contributed before, does not exclude any applicants from consideration.

The task offered is a project-based one-off, with no immediate plans to a mid- or long-term contractual relationship. It is offered on a freelance, project basis. Individuals and companies applying can be located anywhere in the world.

When budgeting, we anticipated that this project (all items combined) to take in the region of 40 days of work. Should bidders’ assessment result in a significantly different number, please reach out to us before sending your bid, so we can clarify upfront.

TDF is looking forward to receiving your applications for the aforementioned tasks, your offer in form of a fixed-time, fixed-budget approach, and the duration period for the implementation in calendar weeks after the final awarding of the tender, via e-mail to a committee at tender20210401@documentfoundation.org no later than May 31, 2021.

Applicants who have not received feedback by June 30, 2021 should consider that their application, after careful review, was not accepted.

All bidders are invited to ask their questions on this tender until June 15, 2021. Questions can be sent informally to the above e-mail address, and answers will be made public in a collected and anonymized form.

We received the following question:

“getting rid of four bundled external libraries” – Could you please clarify what these four libraries are?

Answer: the text only indirectly mentions that serf “is complicated to build, as it drags in two other bundled external libraries”, which are apr and its dependency apr_util (both in external/apr/). So the “four bundled external libraries” would be apr, apr_util, neon, and serf. (There are still other dependencies on openssl, like ExternalProject_python3 and ExternalProject_xmlsec, so we will not get rid of it through this tender.)

We received the following question:

Could you please expand a bit on:

1. the meaning of ‘extensive documentation’, e.g. number of pages or words, and level of detail (classes, functions, line-by-line) that would meet the acceptance criteria?

2. the target audience (e.g. certified LibreOffice developers, or more general?) and purpose of the documentation (e.g. teaching, reference, new implementations, maintenance), as well as form (document format) and acceptable publishing location (e.g. inline, separate-but-within-the-code-base, wiki, or elsewhere)?

Answer: There is no fixed criteria for the documentation. Our goal is to share the knowledge about the approach chosen to address the problem and/or implement the feature, in order to make that information available to the general public.

The target audience is a suitably skilled developer. As such, industry-standard inline documentation in the code, targetting experienced and/or certified LibreOffice developers, plus documenting any non-obvious design choices in an accompanying README file, would be sufficient.