On 3/27/14, 6:37 AM, Justin Wood (Callek) wrote:
On 3/26/2014 9:15 PM, Taras Glek wrote:
Bobby Holley <mailto:bobbyhol...@gmail.com>
Wednesday, March 26, 2014 17:27
I don't understand what the overhead is. We don't run CI on user
repos. It's effectively just ssh:// + disk space, right? That seems
totally negligible.
Human overhead in keeping infra running could be spent making our infra
better elsewhere.
Also, project branches are pretty useful for teams working together on
large projects that aren't ready to land in m-c. We only use them when
we need them, so why would we shut them down?
I'm not suggesting killing it. My suggestion is that project branch
experience would likely be better when not hosted by mozilla. It would
still trigger our c-i systems.
Except when you consider the disposable project branches get "Level 2"
commit privs needed, and that to commit to our repos you need to have
signed the committer agreement, which grants some legal recompense if
malice is done.
These project branches run on "non try" based machines which have
elevated rights vs what try does, and can do much much more harm if
there is malice here.
I for one would not be happy from a sec standpoint if we allowed
bitbucket-hosted repos to execute arbitrary code this way.
The security concern should be on the scheduling front, not where the
code is hosted.
If a repo push incurs automation activity, we have established trust
that anyone who can push to that repo can be trusted. If we don't have
this automatic scheduling on push, no trust is established and there is
no security concern.
If a user is able to schedule automation manually (say by calling a web
API), we trust the user isn't doing something nefarious. Since the
scheduling API requires authentication, there shouldn't be a new
security concern here.
Even if there is an increased security concern over MITM or silent repo
modification by 3rd party, these concerns can be mitigated through
proper security settings (our Mercurial clients in automation aren't
currently validating x509 fingerprints) and moving our automation jobs
to execute in containers, which I believe is already in the works. That
leaves us pretty much with kernel vulnerabilities (that can escape from
containers), which we should be protecting ourselves against anyway.
This problem is little different than what <insert cloud hosting service
provider here> deals with.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
