From nobody Fri Dec 15 06:07:54 2017 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC9612871F for ; Fri, 15 Dec 2017 06:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QStBUcCvi2M for ; Fri, 15 Dec 2017 06:07:51 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E4DF126C25 for ; Fri, 15 Dec 2017 06:07:51 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C0D1720090 for ; Fri, 15 Dec 2017 09:11:15 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 57043814B3 for ; Fri, 15 Dec 2017 09:07:50 -0500 (EST) From: Michael Richardson To: tools-discuss@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Tools-discuss] text/plain wrapping in HTML formatting for MHonarc vs mailarchive X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 14:07:53 -0000 --=-=-= Content-Type: text/plain I sure wish I could convince people that text/plain email should be wrapped, but Apple Mail and LookOut disagree with me, and so be it. It does result in really hard to read archives, such as: https://www.ietf.org/mail-archive/web/ietf-announce/current/msg17252.html (I still use the MHonarc interface, because it's just easier for me) Kudos for wrapping the mailarchive one: https://mailarchive.ietf.org/arch/msg/ietf-announce/Bx4JgxWiIJ-O9zi_bf14vaKtk30 I notice that it's responsive to browser width, but seems to have a maximum width. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloz1zYACgkQgItw+93Q 3WXckwgAkZ9Dn5L6/7BHmt1xe7y0x61ut6N7gvFY6cXBOkzmISEJJCpP6DKU0LIs eg+G2PEGlToM7DEreuQKzta9LIic1+QOR4fEt6sTtQJSPHensZhzbT/WY23/irZy oS2qH0a1z+osGT+PwKcR1svKd4LtkmFmzAE5V/jN4eiLtVgsjKOMZsrnrHhm47NF 0GTyyie5OSDHxwr+JAs2zICpbM5EK0EX3XV/gTtGDHngP2l0U5mif/KnFCM76aCT 5HE6R79I1jdSxqg4UDcks3ii6g9705lKNUrDbZMRO/xhltKz03HNHV3Jfym+ltAO bBkdCHPvST/ytog6tJ0bttOmcXjD+A== =3gWX -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Dec 19 02:03:57 2017 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7BF12DA15 for ; Tue, 19 Dec 2017 02:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbzBSCyEOaqB for ; Tue, 19 Dec 2017 02:03:53 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFC5A12D96B for ; Tue, 19 Dec 2017 02:03:52 -0800 (PST) Received: from h-99-61.a357.priv.bahnhof.se ([82.196.99.61]:56787 helo=[192.168.1.120]) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1eREkX-0000cW-9Y; Tue, 19 Dec 2017 02:03:50 -0800 To: Eric Rescorla References: <2da19e94-bf94-0956-e053-1bb4bd5605c0@levkowetz.com> <52c39da2-6457-d43d-912e-cdfbea7d687b@levkowetz.com> <7dce0eb9-b26a-46eb-124f-f6c0e17f010a@levkowetz.com> Cc: tools-discuss From: Henrik Levkowetz Message-ID: <3010c065-91aa-a689-5bc3-2d3d20292a70@levkowetz.com> Date: Tue, 19 Dec 2017 11:03:31 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1tI7UXXlk73abVEf4P7mRGsKPKjCXrOis" X-SA-Exim-Connect-IP: 82.196.99.61 X-SA-Exim-Rcpt-To: tools-discuss@ietf.org, ekr@rtfm.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Tools-discuss] Auto-posting IESG ballots X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 10:03:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1tI7UXXlk73abVEf4P7mRGsKPKjCXrOis Content-Type: multipart/mixed; boundary="jtjX17pJgGmWJhmfEE4Ll1g3Pl2WiKJS3"; protected-headers="v1" From: Henrik Levkowetz To: Eric Rescorla Cc: tools-discuss Message-ID: <3010c065-91aa-a689-5bc3-2d3d20292a70@levkowetz.com> Subject: Re: [Tools-discuss] Auto-posting IESG ballots References: <2da19e94-bf94-0956-e053-1bb4bd5605c0@levkowetz.com> <52c39da2-6457-d43d-912e-cdfbea7d687b@levkowetz.com> <7dce0eb9-b26a-46eb-124f-f6c0e17f010a@levkowetz.com> In-Reply-To: --jtjX17pJgGmWJhmfEE4Ll1g3Pl2WiKJS3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 test= ing 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 ove= r 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 t= he morning, PST). The same goes for positions and other changes you may mak= e. Please let me know when you've had time to try it out, and of course if y= ou 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 > wrote: >=20 >> >> On 2017-10-18 17:37, Eric Rescorla wrote: >> > On Wed, Oct 18, 2017 at 8:31 AM, Henrik Levkowetz >> > wrote: >> > >> >> >> >> On 2017-10-18 16:58, Eric Rescorla wrote: >> >> > On Wed, Oct 18, 2017 at 7:54 AM, Henrik Levkowetz < >> henrik@levkowetz.com> >> >> > 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 coul= d >> use an >> >> >> API >> >> >> > key rather than a cookie, because it's a real pain to replicat= e 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 u= sed. >> >> >> >> Essentially, what you're proposing is to use a combined authenticat= ion >> >> and authorization token instead of username+password. If that toke= n >> >> doesn't leak, it should not be a problem. If it leaks, it's of cou= rse >> >> 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. >> >=20 > This seems conceptually fine. >=20 >=20 >>> 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 bel= ow, >> >> I guess that's a property you would like to avoid, too? Or would t= hat >> >> be acceptable? >> >> >> > >> > Yes, I would like to avoid that. The invariant I want to have here i= s >> that >> > I can provision the bridging server (the one that moves data back an= d >> > 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 ar= e >> some thoughts: >> >> * Provide a GUI to revoke a key (necessary in any case) and give >> an overview of existing keys and their usage. >> >=20 > This seems like a good plan. >=20 >=20 > * Time limit the validity of the key to N days (30?) from the time of >> the latest login to the datatracker using username+password. >> >=20 > Yeah, this seems like it would probably work though might be brittle. >=20 >=20 > * Limit the key to a given URL path prefix (e.g., /api/iesg/ballot/) >> This means having multiple keys if we evolve additional API endpoin= ts, >> 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? >> >=20 > Both of these seem like good ideas. >=20 > -Ekr >=20 >=20 >> >> Thoughts? >> >> Henrik >> >> >> > >> > -Ekr >> > >> > >> >> > Are you ok with doing a regular login >> >> >> cycle to cookie storage ahead of posting to the form with the AP= I >> key? >> >> >> >> >> > >> >> > I could also do this as long as the cookie was perpetual so I cou= ld >> >> > log in through my browser and then store the cookie on the server= =2E >> >> > 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 < >> >> henrik@levkowetz.com> >> >> >> > 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 t= he >> 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 h= ard. >> >> There >> >> >> >> are things ahead of it in the queue, though ,:-) >> >> >> >> >> >> >> >> >> >> >> >> Best regards, >> >> >> >> >> >> >> >> Henrik >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> >> > >> >> >> >> >> > >> >> >=20 >=20 >=20 --jtjX17pJgGmWJhmfEE4Ll1g3Pl2WiKJS3-- --1tI7UXXlk73abVEf4P7mRGsKPKjCXrOis Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJaOOP6AAoJEE6bV0uPuxcaEfoP/i7Fu7kfzwHRKprYzolUsbRy YdeuT5ONT7B5FbJpl4C5Iy67EagmSN+O+0ByS6+BzsEDqetXuZB0Y4zM1wO7xJKg q4CKszuhYmv6ItMl1LAcPBHVqA0AfframY/5KUapThwRyr7fuEO/KgmPvuRb7+xV CIRTheJrbhf4S68bQqdNDa912UZAg+cQ/IpOiwXbpRaCs6f430BMNMyxHMjR3Tdh 03kama172sdALFjO7MNLltaC5hJwlrc+dEDxJ7FMGxVVgiafpgnuTZEEzIwkyjeU XRSOpjmw5yZd4Z7F17Ckb4rDQpTChmELYFj+E4pB9TYoKVx9fJLl8tify6jpzEcB CX6E9lfvg51k5K5mDEINtS7WvXTi7AQx+CZ/XyIqC9RJLnGfOyRs9jxf0RMHnVvw NrKRDby8USNsGUQwdZvBI0mDVoWXcON4luMmLdm8QUuFa6t3D3ZQK+OHUIpuI5aR qS1mS3WYIIJSY5jhGgD1lDuhYxJlgu5j7WkSXwtK9jZ5HAgF6z3nfCWy0xkHEqcf 9LITouvcE/0DJ7SIJeqCEfT1FDOr0hOzwrySxe3ByJTD0FCzubovsTwLhqy4Tnov 34haj8MzwOVJCb4YBwo0AsmKhMLuFDZSOTjS3FL0nKbL6F2DzaXAfrUhvK3NZ6i5 Qepd79anEOKFtOhb74Oq =vo2L -----END PGP SIGNATURE----- --1tI7UXXlk73abVEf4P7mRGsKPKjCXrOis-- From nobody Tue Dec 19 05:56:16 2017 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6613E126C19 for ; Tue, 19 Dec 2017 05:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xht0IcG8-ot for ; Tue, 19 Dec 2017 05:56:11 -0800 (PST) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3191B126579 for ; Tue, 19 Dec 2017 05:56:11 -0800 (PST) Received: by mail-yb0-x230.google.com with SMTP id c15so4859763ybl.0 for ; Tue, 19 Dec 2017 05:56:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=guKVPB3+upgrsDlshBVuvNh8MNx0KjA922eBAw4lGQ8=; b=U9VMNVTcMkAunGsqz6GUnYqpCE+cgG09Ra79QuTPQJnq0x+/SCpjGLYTOJahTuIvHe lj+N6TzMkY9QgBcgKbyKyrSK3bc7ntobGvRs/KHs1D0I6tnbSm5MiPfwF8W3eFvcLtKs hNYegzXQZxXOjRthQzWpDWdt2QN0Kl9ZRl2MkGaX34NOEQkrJUh0Ca2LKBjIrcTEWT0H 8xumVOWmJQ/J1Z5vT1hsPmSCO3u6chipCNJrHhMLHeeqjxfGOR9VEEDEXFRnmr6dvxdl /5YlpkmuvQ59tg+rbTyNcaGvoJrkymDGc8KDqKY51qpGR0Ms+fGhis2QSFI7doJEgxKz VyYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=guKVPB3+upgrsDlshBVuvNh8MNx0KjA922eBAw4lGQ8=; b=OHhs9ZZcXq2zLmAwwKf3VTc2I/KDVhRvYqfTQg7sVeG7o5zuiTJu7PwjcE5mqHfDbg 8kSFTaQxIGR7soWKl5SvWdYmnYOvWOwpAfB22oaMxuWEMGVCKxkowEnr0EG6UQ2dQ5Kc 3qi5OD/2pPP0SJODCIi30WERGE2QpQcQRUrnX8JZei6Y1+JLxN6q0HPOTOj3JAXxyG76 A87Bz/Yt8SBy1ckdWVH9HB8TQhglbPdU5btrNrKom7NARdKbZIWreoxTV/UFc+K050VZ chbVyzqWP3dKpRKP/ZeDlfh1i85WTGDdELYROB5uAg3J7B4wl3vnt6m7xokiCwqoESmN gdMQ== X-Gm-Message-State: AKGB3mLBeFZVNbDI6/KM1Mg4hWVm7d3sjKo2JKyjQHb7uXFpJ37O3Xz5 WdNLBKWrlKmJzX2xvRlWY4RXVZ9j9D0mQUWHzrJ3v12q X-Google-Smtp-Source: ACJfBov63RGxOohCQdlaplQW9cUwHChTEi+me0RgI3hea/TGo/pfIsiXucGNkJwPrryhGobpdmTz0zyH/b+KzQYY6GI= X-Received: by 10.129.222.9 with SMTP id k9mr2424072ywj.47.1513691770293; Tue, 19 Dec 2017 05:56:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Tue, 19 Dec 2017 05:55:29 -0800 (PST) In-Reply-To: <3010c065-91aa-a689-5bc3-2d3d20292a70@levkowetz.com> References: <2da19e94-bf94-0956-e053-1bb4bd5605c0@levkowetz.com> <52c39da2-6457-d43d-912e-cdfbea7d687b@levkowetz.com> <7dce0eb9-b26a-46eb-124f-f6c0e17f010a@levkowetz.com> <3010c065-91aa-a689-5bc3-2d3d20292a70@levkowetz.com> From: Eric Rescorla Date: Tue, 19 Dec 2017 05:55:29 -0800 Message-ID: To: Henrik Levkowetz Cc: tools-discuss Content-Type: multipart/alternative; boundary="f403043d048844a74a0560b1d4e0" Archived-At: Subject: Re: [Tools-discuss] Auto-posting IESG ballots X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 13:56:13 -0000 --f403043d048844a74a0560b1d4e0 Content-Type: text/plain; charset="UTF-8" Thanks! On Tue, Dec 19, 2017 at 2:03 AM, Henrik Levkowetz 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 > > > wrote: > > > >> > >> On 2017-10-18 17:37, Eric Rescorla wrote: > >> > On Wed, Oct 18, 2017 at 8:31 AM, Henrik Levkowetz < > henrik@levkowetz.com> > >> > wrote: > >> > > >> >> > >> >> On 2017-10-18 16:58, Eric Rescorla wrote: > >> >> > On Wed, Oct 18, 2017 at 7:54 AM, Henrik Levkowetz < > >> henrik@levkowetz.com> > >> >> > 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 < > >> >> henrik@levkowetz.com> > >> >> >> > 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 > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> > > >> >> >> > >> >> >> > >> >> > > >> >> > >> >> > >> > > >> > >> > > > > > > > > --f403043d048844a74a0560b1d4e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks!

On Tue, Dec 19, 2017 at 2:03 AM, Henrik Levkowe= tz <henrik@levkowetz.com> 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:

=C2=A0 https://datatracker.ietf.org/api/#ie= sg-position-api

The limitations on the API keys follow what we discussed below.=C2=A0 For t= esting
purposes, you may want to use the datatracker sandbox,

=C2=A0 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<= br> 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).=C2=A0 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,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Henrik


On 2017-10-18 20:50, Eric Rescorla wrote:
> On Wed, Oct 18, 2017 at 11:43 AM, Henrik Levkowetz <henrik@levkowetz.com>
> wrote:
>
>>
>> On 2017-10-18 17:37, Eric Rescorla wrote:
>> > On Wed, Oct 18, 2017 at 8:31 AM, Henrik Levkowetz <henrik@levkowetz.com>
>> > wrote:
>> >
>> >>
>> >> On 2017-10-18 16:58, Eric Rescorla wrote:
>> >> > On Wed, Oct 18, 2017 at 7:54 AM, Henrik Levkowetz &l= t;
>> henrik@levkowetz.com&g= t;
>> >> > wrote:
>> >> >
>> >> >>
>> >> >> On 2017-10-18 16:47, Eric Rescorla wrote:
>> >> >> > Thanks. I would actually be fine with repli= cating the existing API
>> >> >> surface
>> >> >> > (it's not that hard to generate form fi= lls), 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 a= nti-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 combin= ed authentication
>> >> and authorization token instead of username+password.=C2= =A0 If that token
>> >> doesn't leak, it should not be a problem.=C2=A0 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.=C2=A0 To counterbalance this, I believe= the
>> API key should be limited in what it authorizes the holder to do.<= br> >> More below.
>>
>
> This seems conceptually fine.
>
>
>>> One property of API keys is often that they have a limited lif= etime,
>> >> in order to reduce the impact of leakage.=C2=A0 Given wha= t you write below,
>> >> I guess that's a property you would like to avoid, to= o?=C2=A0 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 credenti= als 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 datatra= cker
>> > or both, but because you want to avoid polling, the upshot wi= ll
>> > still be distribution of credentials.
>>
>> Right.
>>
>> Ok, so in order to limit the damage an exposed API key can do, her= e are
>> some thoughts:
>>
>>=C2=A0 * Provide a GUI to revoke a key (necessary in any case) and = give
>>=C2=A0 =C2=A0 an overview of existing keys and their usage.
>>
>
> This seems like a good plan.
>
>
>=C2=A0 * Time limit the validity of the key to N days (30?) from the ti= me of
>>=C2=A0 =C2=A0 the latest login to the datatracker using username+pa= ssword.
>>
>
> Yeah, this seems like it would probably work though might be brittle.<= br> >
>
>=C2=A0 * Limit the key to a given URL path prefix (e.g., /api/iesg/ball= ot/)
>>=C2=A0 =C2=A0 This means having multiple keys if we evolve addition= al API endpoints,
>>=C2=A0 =C2=A0 which I expect to happen.
>>
>>=C2=A0 * Provide regular information in the datatracker GUI about A= PI key
>>=C2=A0 =C2=A0 activity in a manner easily digested and minimally di= stracting.
>>=C2=A0 =C2=A0 Maybe a message once a week, summarising the activity= ?
>>
>
> Both of these seem like good ideas.
>
> -Ekr
>
>
>>
>> Thoughts?
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Henrik
>>
>>
>> >
>> > -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 perpe= tual 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 serv= er.
>> >>
>> >> Understood.
>> >>
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Henrik
>> >>
>> >> >
>> >> > -Ekr
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >>
>> >> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Henrik
>> >> >>
>> >> >> > -Ekr
>> >> >> >
>> >> >> >
>> >> >> > On Wed, Oct 18, 2017 at 5:19 AM, Henrik Lev= kowetz <
>> >> henrik@levkowetz.= com>
>> >> >> > wrote:
>> >> >> >
>> >> >> >> Hi Ekr,
>> >> >> >>
>> >> >> >> On 2017-10-17 15:52, Eric Rescorla wrot= e:
>> >> >> >> > 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 r= eview and hoist it into the
>> IESG
>> >> >> >> Ballot.
>> >> >> >> > Is there
>> >> >> >> > an existing API surface for this k= ind of thing? Perhaps one
>> which
>> >> >> takes
>> >> >> >> an
>> >> >> >> > auth token
>> >> >> >> > so no CSRF/cookie nonsense?
>> >> >> >>
>> >> >> >> No, there isn't, but adding an endp= oint for this isn't that hard.
>> >> There
>> >> >> >> are things ahead of it in the queue, th= ough ,:-)
>> >> >> >>
>> >> >> >>
>> >> >> >> Best regards,
>> >> >> >>
>> >> >> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Henrik=
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >
>>
>>
>
>
>


--f403043d048844a74a0560b1d4e0--