Subject: Re: [Tools-discuss] Auto-posting IESG ballots

From: Eric Rescorla <[email-masked]>
Date: Thu, 5 Apr 2018 14:32:30 -0700

Thanks, Henrik,

I got this working and can now mechanically post reviews from Phabricator
to the datatracker (at least to the sandbox).

Happy to share the code once I get it more polished.

-Ekr

On Tue, Dec 19, 2017 at 2:03 AM, Henrik Levkowetz <[email-masked]>
wrote:

> Hi Ekr,
>
> In yesterday's datatracker release 6.68.0, now deployed, an API to auto-
> post iesg ballot positions was included.
>
> A brief description of usage, with an example, is available here:
>
>   https://datatracker.ietf.org/api/#iesg-position-api
>
> The limitations on the API keys follow what we discussed below.  For
> testing
> purposes, you may want to use the datatracker sandbox,
>
>   https://sandbox.ietf.org/
>
> where your password is 'password' (as is that of everybody else).
>
> Any personal API keys you create on the sandbox server will not carry over
> to the production site, and will be overwritten within 24 hours when the
> next database update comes in from the production site (just after 5 in the
> morning, PST).  The same goes for positions and other changes you may make.
>
> Please let me know when you've had time to try it out, and of course if you
> have comments and questions about the API endpoint.
>
>
> Best regards,
>
>         Henrik
>
>
> On 2017-10-18 20:50, Eric Rescorla wrote:
> > On Wed, Oct 18, 2017 at 11:43 AM, Henrik Levkowetz <[email-masked]
> >
> > wrote:
> >
> >>
> >> On 2017-10-18 17:37, Eric Rescorla wrote:
> >> > On Wed, Oct 18, 2017 at 8:31 AM, Henrik Levkowetz <
> [email-masked]>
> >> > wrote:
> >> >
> >> >>
> >> >> On 2017-10-18 16:58, Eric Rescorla wrote:
> >> >> > On Wed, Oct 18, 2017 at 7:54 AM, Henrik Levkowetz <
> >> [email-masked]>
> >> >> > wrote:
> >> >> >
> >> >> >>
> >> >> >> On 2017-10-18 16:47, Eric Rescorla wrote:
> >> >> >> > Thanks. I would actually be fine with replicating the existing
> API
> >> >> >> surface
> >> >> >> > (it's not that hard to generate form fills), as long as I could
> >> use an
> >> >> >> API
> >> >> >> > key rather than a cookie, because it's a real pain to replicate
> the
> >> >> >> > anti-CSRF logic.
> >> >> >>
> >> >> >> I'm fine with an API key as alternative to anti-CSRF, but would
> not
> >> >> like to
> >> >> >> rely on only that for authorization.
> >> >> >
> >> >> >
> >> >> > I was thinking a per-user API token
> >> >>
> >> >> Yes, I assumed that.
> >> >>
> >> >> > the way that (say) the Github API works.
> >> >> > Would that be a problem?
> >> >>
> >> >> I'll go and check the github API key details and the way they are
> used.
> >> >>
> >> >> Essentially, what you're proposing is to use a combined
> authentication
> >> >> and authorization token instead of username+password.  If that token
> >> >> doesn't leak, it should not be a problem.  If it leaks, it's of
> course
> >> >> a potential problem.
> >> >>
> >> >
> >> > Right, but of course that's the situation for a password as well.
> >>
> >> Agreed, but you clearly aim to limit exposure of the password more
> >> strongly than the API key.  To counterbalance this, I believe the
> >> API key should be limited in what it authorizes the holder to do.
> >> More below.
> >>
> >
> > This seems conceptually fine.
> >
> >
> >>> One property of API keys is often that they have a limited lifetime,
> >> >> in order to reduce the impact of leakage.  Given what you write
> below,
> >> >> I guess that's a property you would like to avoid, too?  Or would
> that
> >> >> be acceptable?
> >> >>
> >> >
> >> > Yes, I would like to avoid that. The invariant I want to have here is
> >> that
> >> > I can provision the bridging server (the one that moves data back and
> >> > forth between phabricator and the data tracker) with credentials for
> >> > each side and then let it run indefinitely. At the end of the day,
> >> > one might imagine merging that logic into phab or the datatracker
> >> > or both, but because you want to avoid polling, the upshot will
> >> > still be distribution of credentials.
> >>
> >> Right.
> >>
> >> Ok, so in order to limit the damage an exposed API key can do, here are
> >> some thoughts:
> >>
> >>  * Provide a GUI to revoke a key (necessary in any case) and give
> >>    an overview of existing keys and their usage.
> >>
> >
> > This seems like a good plan.
> >
> >
> >  * Time limit the validity of the key to N days (30?) from the time of
> >>    the latest login to the datatracker using username+password.
> >>
> >
> > Yeah, this seems like it would probably work though might be brittle.
> >
> >
> >  * Limit the key to a given URL path prefix (e.g., /api/iesg/ballot/)
> >>    This means having multiple keys if we evolve additional API
> endpoints,
> >>    which I expect to happen.
> >>
> >>  * Provide regular information in the datatracker GUI about API key
> >>    activity in a manner easily digested and minimally distracting.
> >>    Maybe a message once a week, summarising the activity?
> >>
> >
> > Both of these seem like good ideas.
> >
> > -Ekr
> >
> >
> >>
> >> Thoughts?
> >>
> >>         Henrik
> >>
> >>
> >> >
> >> > -Ekr
> >> >
> >> >
> >> >> > Are you ok with doing a regular login
> >> >> >> cycle to cookie storage ahead of posting to the form with the API
> >> key?
> >> >> >>
> >> >> >
> >> >> > I could also do this as long as the cookie was perpetual so I could
> >> >> > log in through my browser and then store the cookie on the server.
> >> >> > I'd like to avoid having my password on the server.
> >> >>
> >> >> Understood.
> >> >>
> >> >>         Henrik
> >> >>
> >> >> >
> >> >> > -Ekr
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >>
> >> >> >>         Henrik
> >> >> >>
> >> >> >> > -Ekr
> >> >> >> >
> >> >> >> >
> >> >> >> > On Wed, Oct 18, 2017 at 5:19 AM, Henrik Levkowetz <
> >> >> [email-masked]>
> >> >> >> > wrote:
> >> >> >> >
> >> >> >> >> Hi Ekr,
> >> >> >> >>
> >> >> >> >> On 2017-10-17 15:52, Eric Rescorla wrote:
> >> >> >> >> > Hi folks.
> >> >> >> >> >
> >> >> >> >> > I've been working some more on my IETF review tools and I'm
> now
> >> at
> >> >> the
> >> >> >> >> point
> >> >> >> >> > where I want to take an external review and hoist it into the
> >> IESG
> >> >> >> >> Ballot.
> >> >> >> >> > Is there
> >> >> >> >> > an existing API surface for this kind of thing? Perhaps one
> >> which
> >> >> >> takes
> >> >> >> >> an
> >> >> >> >> > auth token
> >> >> >> >> > so no CSRF/cookie nonsense?
> >> >> >> >>
> >> >> >> >> No, there isn't, but adding an endpoint for this isn't that
> hard.
> >> >> There
> >> >> >> >> are things ahead of it in the queue, though ,:-)
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> Best regards,
> >> >> >> >>
> >> >> >> >>         Henrik
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >> >>
> >> >
> >>
> >>
> >
> >
> >
>
>

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 8 Apr 2018 14:45:00 +0200

Hi Ekr,

> to the datatracker (at least to the sandbox).

Oh, good :-)

> Happy to share the code once I get it more polished.

Ack; hopefully that will be helpful to other ADs.

	Henrik

> ___________________________________________________________
> Tools-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-discuss
> 
> Please report datatracker.ietf.org and mailarchive.ietf.org
> bugs at http://tools.ietf.org/tools/ietfdb
> or send email to [email-masked]
> 
> Please report tools.ietf.org bugs at
> http://tools.ietf.org/tools/issues
> or send email to [email-masked]
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Apr 2018 12:54:52 -0700

Hi Henrik,

The ballot submission API is working great, but it doesn't seem to send
email when I ballot. Would it be possible to add a parameter for that. or
just have it always happen?

-Ekr

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 16 Apr 2018 21:57:03 +0200

Hi Eric,

> just have it always happen?

Sure.  The latter seems best.  I'll make it so.

	Henrik

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Apr 2018 12:58:21 -0700

Thanks!

On Mon, Apr 16, 2018 at 12:57 PM, Henrik Levkowetz <[email-masked]>
wrote:

> >> >> next database update comes in from the production site (just after 5
> in
> >> the
> >> >> Please let me know when you've had time to try it out, and of course
> if
> >> you
> >> >> >> > Yes, I would like to avoid that. The invariant I want to have
> here
> >> is
> >> >> >> that
> >> >> >> > I can provision the bridging server (the one that moves data
> back
> >> and
> >> >> >> Ok, so in order to limit the damage an exposed API key can do,
> here
> >> are
> >> >> >> some thoughts:
> >> >> >>
> >> >> >> >> >> cycle to cookie storage ahead of posting to the form with
> the
> >> API
> >> >> >> key?
> >> >> >> >> >>
> >> >> >> >> >
> >> >> >> >> >> >> > where I want to take an external review and hoist it
> into
> >> the
> >> >> >> IESG
> >> >> >> >> >> >> Ballot.
> >> >> >> >> >> >> > Is there

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 17 Apr 2018 14:10:33 +0200

Hi Ekr,

A fix has been committed as changeset [15049]:
  https://trac.tools.ietf.org/tools/ietfdb/changeset/15049 .

I've patched production.

Best regards,

	Henrik

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 17 Apr 2018 06:40:23 -0700

Great! Thanks again for the quick response.

On Tue, Apr 17, 2018 at 5:10 AM, Henrik Levkowetz <[email-masked]>
wrote:

> > On Mon, Apr 16, 2018 at 12:57 PM, Henrik Levkowetz <[email-masked]
> >
> > wrote:
> >
> >> Hi Eric,
> >>
> >> >> >> Any personal API keys you create on the sandbox server will not
> carry
> >> >> over
> >> >> >> to the production site, and will be overwritten within 24 hours
> when
> >> the
> >> >> >> morning, PST).  The same goes for positions and other changes you
> may
> >> >> make.
> >> >> >>
> >> >> >> >> >> >> > (it's not that hard to generate form fills), as long
> as I
> >> >> could
> >> >> >> >> use an
> >> >> >> >> >> >> API
> >> >> >> >> >> I'll go and check the github API key details and the way
> they
> >> are
> >> >> >> used.
> >> >> >> >> >>
> >> >> >> >> >> and authorization token instead of username+password.  If
> that
> >> >> token
> >> >> >> >> > forth between phabricator and the data tracker) with
> credentials
> >> >> for
> >> >> >> >> >> > I could also do this as long as the cookie was perpetual
> so I
> >> >> could
> >> >> >> >> >> >> >> > I've been working some more on my IETF review tools
> and
> >> >> I'm
> >> >> >> now
> >> >> >> >> at
> >> >> >> >> >> the
> >> >> >> >> >> >> >> point
> >> >> >> >> >> >> >> > an existing API surface for this kind of thing?
> Perhaps
> >> >> one
> >> >> >> >> which
> >> >> >> >> >> >> takes
> >> >> >> >> >> >> >> an
> >> >> >> >> >> >> >> > auth token