[flashrom] Proposed changes to flashrom hosting and workflow

Patrick Georgi pgeorgi at google.com
Tue Aug 11 11:25:46 CEST 2015


2015-08-11 2:28 GMT+02:00 Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2006 at gmx.net>:
>
> @Stepan:
> It would be good to know which of patchwork or svn (or both) cause extra
> maintenance burden.

AFAICS at least svn seems to be automatically getting security updates
> on ra (coreboot server).
>
We run apache (with mod_dav_svn) just for svn. It's automatically updated
alright, but it still increases the system's surface.


> If we migrate off patchwork, is there a way to keep/import the old data
> into some other tool?

Since it's unstructured data that will be hard to automate.


> Hm. In the end, we have to decide whether the tree will be managed
>
directly by humans or indirectly via Gerrit. I doubt we can have both at
> the same time without pretty explosions.
>
Even with gerrit, it's always managed by humans. Gerrit never presses the
'submit' button by itself.

IIRC OpenID had/has soem security bugs which partially stems from the
> design. That's one o the reasons why I wanted to avoid Gerrit.
>
OpenID provides open federation. There are some impersonation attacks, some
of which can be defused by using https.
Gerrit also supports OAuth2 now, which uses preshared credentials per
authentication provider (currently for Google and Github). That reduces the
impersonation risk, but is a maintenance mess - and definitely not "Open
Web".

There are three conflicting goals with regard to identification:
1. to not store credentials on every. single. server. on. the. net. (hence
no local auth scheme)
2. to not lock users (and services) into a few select identity providers
(hence OpenID)
3. to prevent some (not all) impersonation attacks (hence preshared
credentials in OAuth2)

We now provide both: reliable authentication (OAuth2) and open federation
(OpenID). That allows users to decide on the trade-off (while we don't need
to protect a credentials database).

I assume the switch was done to get some gerrit features (jenkins
> integration) not present in patchwork.
>
The switch was done because patchwork became a dumping ground for
non-actionable diffs.

The main advantages of gerrit over patchwork (IMHO) are:
1. you can directly work from the list of open commits (in patch work you
can only reply by hunting down the thread that it archived in your local
mail client. if you weren't subscribed back then, you're out of luck)
2. through the git push model of contributing you're guaranteed to have
context for the commit. compare "all history that leads to this commit" to
the diffs in patchwork: uh, that might be based on r5200 or maybe r1500 or
is it even manually edited and doesn't apply cleanly to anything?

That we automatically test-build the commits and thus have some basic
sanity checks is a very useful bonus. But at least for me that wasn't the
reason for switching tools.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.flashrom.org/pipermail/flashrom/attachments/20150811/e093d66d/attachment.html>


More information about the flashrom mailing list