Hi Adam,
comments inline.


Il 16/05/2016 17:24, Adam Goryachev ha scritto:
> Thank you for taking the time to explain, but it doesn't (well,
> partially) explain how to solve my "concern". We ideally want a larger
> number of "maintainers" available to share the burden of developing
> backuppc, and allowing the survival of backuppc when a couple of people
> are too busy for extended periods of time. Consider if we have 3
> maintainers, and one moves job, another is simply swamped with
> work/family, and one is not really a developer, and gets bored of
> working on backuppc. We need to actively maintain this group of
> maintainers, and ensure there is always enough to allow someone else to
> be added, and to remove the old maintainers that can be confirmed as no
> longer interested.
This can be done easily by controlling the "Teams" in github.
You may have different teams with different capabilities, including the possibility
to alter team member list.

> So, lets say we now have 20 maintainers. One of those happens to be ...
> accidentally dangerous. They follow the work flow, sending their pull
> request, but since they are also a maintainer, then they immediately
> accept the request, and it is committed to the main backuppc repo. Every
> user after this point now ends up with a system that is corrupting 0.1%
> of files backed up. It might take years before this is noticed and
> tracked back to the original commit. Consider how that could be
> different if the maintainer had the intent to cause damage (without
> notice) or to steal information if ($domainname="cia.gov") { send_secrets }
You need to balance between security and ease of use.
In the States, in spite of huge resources of "cia.gov", they have "automatic declassification"
due to the burden to handle "top secrets" for extended periods of time.

> So, I feel that we would like to enforce some peer review. Perhaps the
> solution is to require 2 maintainers to approve a patch, but I fear that
> increases the workload/makes the process more fragile.
If You want peer-review we could move to the "patchwork" infrastructure, and retain
the ML as primary mean, but even there I'm not aware of any way to enforce multiple
approval, it just makes it possible and traceable.

In general, in any unix-like system, there will be someone with "root" access and stopping
him is very difficult ;)
Having many persons with commit privilege (root-like PW) is good for redundancy, but
increases risk of lockout. Craig, very evidently, leaned toward security, let's avoid doing the
mirror mistake.
This is obviously different from having strong identification to keep out unwanted people.

> Ultimately, perhaps I'm being silly, and just seeing demons where none
> exist. I'm sure many open source projects would have similar issues, and
> have solved them.
This might be, but "better safe than sorry".

>
> Regards,
> Adam

------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/