Re: [GNUnet-developers] Discussion, and Help Wanted: Moving to Gitlab for Git, CI, and Issues

[Christian Grothoff]

On 4/7/19 11:11 AM, Schanzenbach, Martin wrote:
>>> On 4/7/19 8:33 AM, Schanzenbach, Martin wrote:
>>>> Contributors should be able to do anything they want in their own
>>>> namespaces including committing code that does not compile (e.g. for
>>>> their gnunet.git forks). However, in order to get it into the "main"
>>>> gnunet project codebase, the CI must pass for the respective pull
>>>> request and I would argue that 1-2 "main" devs should sign off on the
>>>> commit (this allows us to control the CAA issue a bit).
>>> Eh, sorry, but under forthcoming EU regulation, we cannot even host
>>> contributor's code without having a signed the CAA. So Git pushes should
>>> only be possible for people that signed the CAA, and in that case if a
>>> CAA-signing contributor has pushed a change to a namespace/branch that
>>> by convention is to be merged, we should ideally automate the merge.
>>
>> I think you misunderstand the new regulation. Having a CAA does not protect 
>> the platform from this.
>> It is not enough to have the user state that the code is his, the platform 
>> must verify/ensure that.
>> No legal document is able to absolve us from this.
> 
> Btw I also think it only applied to commercial platforms. So is there really 
> a need to worry???

A hostile actor can very easily classify you as "commercial", starting
with GNUnet e.V. applying for grants and hiring devs thus potentially
providing income for some people. And as we learned with Telekom, legal
disputes with the wrong party can bankrupt you easily even if you
_would_ win it, and the Vorstand has _personal_ liability in case of
gross negligence. IANAL, but I believe the CAA should help us against
any claims of _gross_ negligence. OTOH, I'm sure there will be lawyers
that would twist the situation of allowing anyone to upload any code
without any such contract as gross negligence.

>>> However, given that we cannot then preserve the gpg signature on the
>>> commit (depending on how the merge goes), maybe indeed we _need_ a dev
>>> to do the sign-off just to get at least one proper gpg signature on the
>>> commit.  In that case, maybe the CI can automatically send an e-mail to
>>> a group of devs that are on sanity-checking + gpg-signing duty.
>>>
>>> Anyway, the CAA issue should be solved prior to any Git write access,
>>> and the sign off step _may_ be (borderline) acceptable to address the
>>> GPG signing issue, but it shouldn't be seen or phrased as that this is
>>> done by the "main" devs. The sign-off should be more more like a
>>> secretary position for pushing the paperwork along.
>>
>> Well then the whole "open participation" thing is moot anyway and I wonder 
>> why it comes up all the time here.
>> If we have a beaurocractic onboarding process including the CAA (which we do 
>> not have atm btw), then participation is limited and must be done through 
>> gatekeepers anyway.

I'm not sure why you say "which we do not have atm btw" -- all the
Gitolite admins have been told that giving Git (write) access should
only be done if someone has signed the CAA, and I have a collection of
CAA sheets here at home. I'm not 100% sure that there isn't one missing
(some are electronic, I still need to print those), but at least the
process exists and _should_ be enforced.

signature.asc
Description: OpenPGP digital signature