Re: [openpgp] Requesting the editor to step down2020-04-17 05:44:15I haven't worked deeply in crypto or PGP related code in many years, so feel free to discard my comments. I do work extensively in a large number of open source projects still, often as a member of the management team, so perhaps my perspective has some merit. I'll note that you had two main points here, and they are somewhat muddled together - the working group suffered from scope creep - Werner isn't doing a good job as editor I think these topics would be best separated. On the scope creep model, you propose throwing out 4880bis and replacing it with a new draft, and a whole new process for effectively creating feature branches around a specific feature proposal. You further suggest limiting the scope to the originally envisioned scope of 4880bis. I have no comment on whether narrowing scope to the "crypto refresh" scope. I'm not enough of a cryptogrphy coder anymore to have an informed opinion. So to deal with scope creep, you suggest discarding this draft. That seems extreme, and seems like it would greatly slow what little momentum the working group has. You also suggest moving to a feature branch model, where individual described features would exist in a branch, and the branch would garner comments and fixes from the working group before being merged to master. This is a common pattern among open source projects, so I doubt many would disagree that it has merit. On your second point, that Werner isn't adequately fulfilling his duties as editor, you propose that he give up the title. I have no comment on this, as I am not following the details closely enough to have an informed opinion. You further give as a reasons that the editor should be "fostering cooperation" ... I'm not sure that usually falls to the editor, but rather to the Chair of the working group. I have little comment on your desire for better communication. Different teams communicate very differently. You want more formal communication of planned merges of features. That is a proposal worth discussion. The IETF process alllows for multiple co-chairs, but formally has only one Document Editor. I'll note that this process predates the wide deployment of distributed version control systems or distributed text editors. In many modern open source projects, more than one person has the authority to merge changes to master. I would suggest that perhaps this is a simpler solution... - give more than one individual 'co-editor' status to merge changes to master - revise the process to a formal feature branch model, one feature per branch,for all committers - revise the process to communicate on this list the intended merge of a given feature branch, and offer opportunity for review, patches, and comment Regards, Brian On Fri, 2020-04-17 at 12:18 +0200, Vincent Breitmoser wrote: Hi OpenPGP folks, Five years ago, the OpenPGP working group was reopened. It was chartered asa "crypto refresh" of OpenPGP, and a decision was consciously made to not addfeatures beyond that. The newly reopened working group strayed from this goalquite a bit, got lost in a confused silence, and was closed again due to inactivity.Despite the formal status of the working group as closed, rfc4880bis is stillbeing worked on. This work happens on this mailing list, but most of the actualprogress happens on the openpgp-wg/rfc4880bis repository on gitlab:https://gitlab.com/openpgp-wg/rfc4880bis There have also been a couple ofreleases of this spec as I-Ds, and it is used in practice as a reference byimplementors. Since the original reopening, the role of the editor has been held by WernerKoch. The formal description of the Document Editor is described in [BCP25] as"The Document Editor is responsible for ensuring that the contents of thedocument accurately reflect the decisions that have been made by the workinggroup." Following this, I believe the following to be a reasonable set ofexpectations towards an editor: 1. Communicate decisions and updates to the working group.2. Foster cooperation.3. Work out specification content from group consensus. Myself and others have been increasingly dissatisfied with the way that all ofthese expectations have not been met in the editing process of RFC4880bis. Moresubtle attempts at communicating this have failed, which is why I am bringingthe issue up on this list. I'd rather spare everyone the exercise, but it seems necessary to give a fewconcrete examples of this dissatisfaction. Feel free to skip ahead. == The repository on gitlab currently has seven open merge requests, that have beenopen for many months. Those range from trivial fixes for typos, to dkg's work onUser IDs and replacement of Revocation Keys, and a fix for a test vector(!) thatreceived no attention in six months. On the other side of things, Werner commits his own changes directly to master,sometimes without any communication. A recent example from two weeks ago, wasthe introduction of a new "key block subpacket": https://gitlab.com/openpgp-wg/rfc4880bis/-/commit/30d8397c9fd304691d5628813a38cd61389c76c7 Regardless of whether this mechanism is a good idea (it probably is), or whetherthe spec wording is good (is "key block" the best term?), there was no attemptmade to find consensus about it, on this list or elsewhere. (This feature wasalso implemented into GnuPG on the same day it was pushed to master in the spec,and released as a backport into GnuPG 2.2.20 just a few days later.) As noted above, the decision process of whether a proposal makes it into thespec seems arbitrary at best. But even when consensus is achieved, the actualediting process is haphazard. In August of 2019, dkg and myself worked outa draft for "attested certifications". This work found some consensus on the ml(including from Werner), and eventually led to a merge request: https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/20 When Justus Winter and Heiko Stamer reviewed this MR, they found an oddity aboutthe way that signatures were made, and also two typos. Despite those issuesthat obviously still required attention, Werner merged the MR, leaving nocomment and offering no follow- up. The typos and cryptographic oddity of thesignature remain to this day. Facilitation of cooperation has failed as well. On March 19th last year, JustusWinter opened an issue on the repository saying that he could not build the specin its current form: https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/7 Six months after the issue was posted, Werner closed it with the single remark"I can't replicate that." dkg reopened the issue, noting that the toolchainworks only on Debian stretch (then already oldstable by a few months), but didnot in fact work on Debian stable. The ticket remains open to this day, eventhough the issue itself was eventually resolved with a merge request from dkgthat converted the toolchain to kramdown. This is not an exhaustive list. I tried to pick examples that illustrate theirpoints in a clear way, and hopefully relatively free of personal bias. == I appreciate the work Werner has put into RFC4880bis, and of course into OpenPGPin general. However, a document that is published under the ietf-* namespacebears a quality of officialness, and thus an expectation to reflect consensus ofthe working group. The draft-ietf- openpgp-rfc4880bis-* documents do not, in myopinion and that of several others I have talked to, meet this expectation. In consequence, I formally request Werner Koch to step down from his position aseditor for the OpenPGP specification. Of course, this means we will need a new editor. I'm confident that we can findsomeone for this role, once the air has cleared a bit. As a general thought for a way forward, I would suggest to restart work onRFC4880bis conceptually, in the way it was originally chartered as a pure cryptorefresh. A good starting point would be for a new editor to bring the originalRFC4880 into a modifiable state with a modern toolchain, to allow work on actualset of patches going from 4880 to 4880bis. A portion of the changes made onRFC4880bis so far certainly don't match the chartered "crypto refresh", so itmakes sense to cherry-pick from them in an ordered fashion, with a check forconsensus and implementation status. I would further suggest to orient future work more on concrete proposals, i.e.diffs against the spec. By explicitly asking contributors to submit and maintainconcrete patches as a basis for discussion, we encourage contributions that arebetter thought out, continuously reflect the state of thinking, and can beweighed against one another - or combined on their merits - more easily. I apologize for bringing up this unpleasant topic. Thanks for reading, andconsidering. - Vincent Breitmoser [BCP25]: https://tools.ietf.org/html/bcp25#section-6.3 _______________________________________________openpgp mailing listopenpgp(_at_)ietf(_dot_)org https://www.ietf.org/mailman/listinfo/openpgp -- Brian G. Peterson ph: +1.773.459.4973 im: bgpbraverock _______________________________________________ openpgp mailing list openpgp(_at_)ietf(_dot_)org https://www.ietf.org/mailman/listinfo/openpgp
|
|