Botan Cryptography Community Project Proposal Extension #64
Conversation
|
This proposal has been updated with a retrospective, the addition / refinement of several goals, and improved clarity / detail of expected deliverables. |
|
Minor update regarding mitigating factors. |
|
|
||
| Another feature missing from the Botan C FFI is Stream Ciphers, and like the X509 bindings, it will require effort to extend the Botan C++ library in order to expose it to Haskell. | ||
|
|
||
| A third feature missing from the Botan C FFI is TLS, as Botan provides a full TLS server implementation, which will also require effort to expose to the FFI. |
There was a problem hiding this comment.
I understand the rationale, but essentially the proposal asks HF to sponsor a development of a third-party C library, which we have no control of / do not gain any stake in / are at mercy of its leadership. This is a high risk investment, extremely difficult to manage. Could we rather focus on lower-hanging fruits and wait (potentially indefinitely) until someone else does Botan C FFI?
|
|
||
| ## Improvements to installation / CI / Unit tests | ||
|
|
||
| One of the largest warts in using these libraries is the installation of the Botan C++ library. Package distributions are available for some users and operating systems via `pkg-config`, but other users currently require manual installation. |
There was a problem hiding this comment.
I think at the moment the only OS which can install Botan via package manager is macOS (brew install botan), while everyone else has to build from sources.
| - Weekly major update that includes github push | ||
| - Monthly report that summarizes what specific items have been or will be worked on, and what challenges have arisen, if any. | ||
|
|
||
| The following are stretch goals / optional deliverables to be looked into only after required deliverables are met: |
There was a problem hiding this comment.
How many stretch goals could be completed, assuming an optimistic scenario? I feel like 5 goals are beyond possible even if everything goes very smooth, so I'd suggest to whittle down the list to a more realistic shape.
|
My overall preference would be to focus on a specific, user-facing, tangible deliverable. For example, can we name X such that "upon the completion of this proposal package X could switch from |
|
I think when I read this proposal it isn't clear to me what the community benefit of such a project is. It sounds like the initial funding has been used to complete the original goals, so now I presume that the library can be used by the original stakeholders. Job done? I agree with @Bodigrim that any more horizontal expansion seems a bit premature. Without users already using the existing library, it begs the question, at which point is the community going to benefit from investing a very significant amount of money into this project? Perhaps we shouldn't engage in what-aboutery, as you have taken the effort to write this proposal and get this work funded, but I can think of many other projects which would benefit from $20k USD which would have a more immediate community impact. |
|
I don't see that Botan is in a state where it doesn't need active development anymore. This is a crypto library and not some PoC that should be abandoned half way in. Wrt the concrete goals I agree with @Bodigrim that working towards making it a drop-in replacement with good documentation/guides and comparisons is reasonable. That, however, may also require working on new features. |
|
Appreciations for your patience, I have taken a week off for rest, and have not yet had a chance to respond yet. This feedback is being paid attention to, and I will be updating this proposal with more concrete details about what I intend to accomplish in the near-term future / within the scope of this proposal. |
I think the original proposal had a much more thorough motivation and this should just be seen as add-on work which was already motivated as possible stretch goals or long term goals in the original proposal. The overall reason this work is important and impactful is we have crypto libraries sitting at the root of a lot of production haskell code and more generally dependency trees for anything involving networking, the web, apis, etc. The existing libraries are idiosyncratic, not audited, and not well maintained. Having solid reliable well maintained crypto libraries is a huge benefit to the ecosystem, and having some working libraries at all is necessary for essentially every industrial use case. |
|
This proposal was updated significantly in tandem with a pending First Milestone blog post of the same subject, but for a different audience / the general community. |
|
Minor updates to the proposal: reducing libsodium interface to long-term goal, clarified CI improvements / |
|
I like the proposal, and I do think it is worthwhile. However, you speak of "continued maintenance" for parity with the Botan C++ library, but still you only seek funding for 3 months of work. Can we assume that a further proposal for "continued maintenance" past these 3 months for later? Or we could possibly have some sort of "maintenance" clause or similar in this one. Just thoughts! I'm still in favour for accepting this one for the other parts of the work. |
@haskellfoundation/tech-proposals
@Kleidukos
@LaurentRDC
@silky
(mentioning a few specific people just in case I didn't do the team label properly)
This is a draft proposal for the extension of funding for the previously-accepted Botan Cryptography Community Project.
The TWG may make comments and feedback as necessary, or may vote immediately if they wish.
rendered