@henrik@levkowetz.com commented

Hi Martin,

We have somewhere between 6000 and 10000 datatracker accounts which most likely does not belong to actual IETF participants. Even if we've added heuristics which makes nuisance account creation much harder after the bulk of these were created, we still have to assume that anyone who would like to do something annoying would be able to do so. I would hesitate to permit posting of new draft versions other than by one of the authors, without replacing that restriction with something else.

One possibility would be to generate an API key per document, in lieu of the author email, and make the key visible to the authors on the draft page when logged in; and then tweak the current API to accept such a key. The presence of the key would permit a user to post a draft without being the author. Would that work for you? Or do you have other suggestions?

Henrik

@mt@lowentropy.net commented

That would be quite inconvenient.

I'm only asking for parity with the web UI. Anyone (without even logging in) can post anyone else's draft.

The nuisance factor is no worse here than today really. As the genuine draft author, it might be annoying to cancel a nuisance draft posting, but the way the system works means that you can only ever upload one replacement draft at a time anyway. So you get at most one nuisance revision per draft that you have. That doesn't seem like a big deal.

@henrik@levkowetz.com commented

There's a large difference in the ease of scripting the manual submission and the ease of scripting the API endpoint; and the automation API has already increased our vulnerability to malicious use. So yes, the potential nuisance factor is really greater than today. I'm not willing to increase that further. Please propose some other effective mitigation, if you find the per-draft API key proposal so inconvenient that it's not going to work in practice.

@mt@lowentropy.net commented

Is this based on real experience with denial of service or abuse?

I spent some time trying to work out how to manage API keys. The best option I can think of involves storing a per-draft key in a file in the repository. That said, it would be more convenient for me to build a submission option that used the existing web forms than that. Acquiring the keys and populating the file would be more time-consuming.

@henrik@levkowetz.com commented

Replying to ietf-svn-conversion/datatracker#2390 (comment:4):

Is this based on real experience with denial of service or abuse?

Automated account creation and wiki spam, yes. Both on tools.ietf.org and on ietf.org

Abuse of the draft submission tool, no; and I don't want to have it happen. If you look at RFC4228 you'll find we took some care in limiting the attack possibilities of the tool when it was first proposed.

I spent some time trying to work out how to manage API keys. The best option I can think of involves storing a per-draft key in a file in the repository. That said, it would be more convenient for me to build a submission option that used the existing web forms than that. Acquiring the keys and populating the file would be more time-consuming.

Ok, fair enough. Please let me know if you want me to go ahead with the API keys.

@rjsparks@nostrum.com changed priority from n/a to major

@rjsparks@nostrum.com changed status from new to closed

@rjsparks@nostrum.com changed resolution from `` to duplicate

@rjsparks@nostrum.com commented

For the act of submission (the creation of Submission objects) this is essentially #2639. I'm going to close this ticket as a duplicate. If that's not right, reopen it.