ietf
[Top] [All Lists]

Re: New Non-WG Mailing List: Ietf-and-github -- Discussion of using GitHub in IETF activities, particularly for Working Groups

2016-01-28 08:33:54
There are really two separate issues:

1) Use of git protocol
2) Use of github

These are two separate issues. The second requires the first but not vice versa.

A DDoS against Github or IETF doesn't actually worry me too much
because the basic git protocol is pretty resistant to DoS. If one repo
is down, use another. The repos will sync anyway. I am now using
Github and Sourceforge for git hosting.

The trickier part is the non git part of the infrastructure. The
ticketing, the wikis, etc. Quite a few WGs are using those and I think
we have a real problem - that collaboration is not clearly within the
scope of Note Well for a start.


I would like to see IETF take these functions in house for a number of
reasons. First I think it important that IETF have visibility of the
entire conversation. But secondly, I would like to see us innovate on
top of git.

To do the archive job properly, we should construct an append only
archive log of all IETF activity and checkpointing the log on an
hourly basis using a hash chain that is then cross notarized with
other chains (Certificate Transparency, BlockChain, etc).

Git and SSH also need serious work. The current realization is really,
really kludgy. Configuring a repo to take an SSH key today requires
cut and paste of the keys themselves. That is really annoying when you
are using RSA2048 and not going to be that much better with Curve448.
If we eat the damn dogfood it might persuade us that it would be
tastier if the protocol allowed fingerprints of keys to be used
everywhere and pushed out the actual key in the protocol.

I would also like to see git re-architected to use a proper hash
function and to sign the repo data rather than just hash it. Further,
it should be easy for developers to maintain separate keys on every
device they use. The reason for that is that we are starting to see
attacks on open source projects as a vector for injecting backdoors.
And current practice doesn't necessarily mean we know for sure whose
account was the source of the bogus data or which machine. The most
likely attack vector is that the attacker targets a contributor to a
project and compromises one of their machines. Laptops and other
mobile devices tend to be more vulnerable than desktops.


No, this isn't necessarily our core interest but this is the place
where we have the necessary expertise. And getting a handle on the
source code maintenance chain is going to be an essential part of any
plan to secure the network as a whole.

<Prev in Thread] Current Thread [Next in Thread>