Re: crypto-lib Proposal Update


Geater, Jon <Jon.Geater@...>
 

Hi Hart, all,

Hope this is the right forum for feedback: if I should be on the wiki or inside the Google Doc just let me know and I’ll shift over.

By and large, looks great, and I appreciate the clear thought that has gone into making this a practical and actionable structured project.  

I have a handful of comments/questions:

1. The tiering between 2 and 3 is not completely clear to me in one regard: specifically, we’re talking firmly in tier 2 about things in that are used (widely?) in practise, but then tier 3 goes right to science experiments.  What do we do with things like leading post-quantum algorithms that are relatively well known and trod but are not yet standards approved and are still being refined?  Would such things default to tier 3 and then be promoted when we’re happy with the implementation?  Or default to tier 2 and then be taken out if they’re judged dangerous?

2. I appreciate (and agree with) the intent of the ‘overwhelming consensus’ requirement for doing important things, but as time goes on and people come and go I’m concerned that such loose language could cause unnecessary controversy at some point.  Why not define this more concretely as 2/3 super majority or similar as it is later on in the doc? Note that this also implies a requirement to manage the voting eligibility of members, but ‘twas ever thus.

3. Since sub-projects are defined essentially as creating code modules for people to incorporate into their super projects, we should assume that dependent super projects will incorporate a number of these modules in order to satisfy all their Crypto-related needs.  It follows therefore that there’s a clear need to ensure that (most of) those modules follow a consistent architectural pattern, implement the same API Design philosophy, and very strictly agree on the semantics and data typing of parameters that may be shared, or at least commonly expressed, between them.  Apart from the obvious programming sanity requirement here, we’ve all seen plenty of cases where plugging together 2 secure things makes one big insecure thing.  Who/what role will do this?  It’s good that the sub projects are independent and self-governing most of the time but Inthink something like an API Council is required here. 

4. Assuming this proposal will at some point become  enshrined and semi-public, it would probably be polite to replace the “incredibly foolish” language.  You’re right, but still.  Optics.

5. I want a Golang version.  Would that be a subproject shim, or just a separate output of the one base lib project?

5a. I’d like a discussion about safe languages in general, but that can happen in slower time.

6. What tier of Project is the dunking booth?  It doesn’t seem to quite fit any consistent set of the criteria for any band.

Jon






 
Jon Geater
CTO
Tel: +44 1223 703479
Mob: +44 7966 995312
@thalesesecurity

Thales eSecurity
One Station Square
Cambridge CB1 2GA
United Kingdom



www.thalesesecurity.com

On Mon, Oct 29, 2018 at 11:55 PM +0100, "hmontgomery@..." <hmontgomery@...> wrote:

Hi Everyone,

 

First of all, thank you all for the feedback during and after the TSC meeting last week.  It was good to hear suggestions from people, particularly those that are open source veterans. 

 

We have incorporated most of these suggestions into a new draft of our crypto-lib proposal.  Please take a look—we’d love more feedback.  In particular, we thought Chris Ferris’s suggestion to eliminate the steward position and instead rely on maintainer lists was a good one, and it is reflected in the current proposal.

 

Here is the link:  https://docs.google.com/document/d/1JtFT5L-82egj6shgGXzTsNAg6_UHuMheKfsst6NS_Xo/edit?usp=sharing

 

Thanks a lot for your time, and have a great day.

 

Thanks,

Hart

Join tsc@lists.hyperledger.org to automatically receive all group messages.