[New: openFATE 308836] performance: scaling ...
Feature added by: Michael Meeks (michael_meeks) Feature #308836, revision 1 Title: performance: scaling ... Buildservice: New Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Description: Build performance should scale, in proportion to the number of users, and not the number of build nodes. Put another way - providing a means to apply local CPU horsepower to the channel, combined with some approach (eg. an xdelta to the previous built binary RPMS) to overcome the (typically) assymetric bandwidth availability in a typical DSL client - easy to download a reference to diff against, hard to up-load it. I would love to donate my CPU resource to help accelerate the projects I care about; as - no-doubt would others. Of course - this has security implications, which are (most likely) more or less meaningless. We ship binaries (re-)built from internal, signing servers anyway, and we have an authentication structure in place: if paranoia reigns, we could restrict that to a further subset of privileged users. -- openSUSE Feature: https://features.opensuse.org/308836
Feature changed by: Adrian Schröter (adrianSuSE) Feature #308836, revision 2 Title: performance: scaling ... - Buildservice: New + Buildservice: Rejected by (adrianSuSE) + reject date: 2010-01-21 12:15:54 + reject reason: security concerns are much more critical as you describe + it here, since one package in any repo you have added can take over + your entire system. people would need to setup xen/kvm and would be + easily to allowed to inject packages with complete wrong content. + one can work out a concept to handle all these cases, but this is + beyond the scope of this faterequest. Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Description: Build performance should scale, in proportion to the number of users, and not the number of build nodes. Put another way - providing a means to apply local CPU horsepower to the channel, combined with some approach (eg. an xdelta to the previous built binary RPMS) to overcome the (typically) assymetric bandwidth availability in a typical DSL client - easy to download a reference to diff against, hard to up-load it. I would love to donate my CPU resource to help accelerate the projects I care about; as - no-doubt would others. Of course - this has security implications, which are (most likely) more or less meaningless. We ship binaries (re-)built from internal, signing servers anyway, and we have an authentication structure in place: if paranoia reigns, we could restrict that to a further subset of privileged users. -- openSUSE Feature: https://features.opensuse.org/308836
Feature changed by: Michael Meeks (michael_meeks) Feature #308836, revision 3 Title: performance: scaling ... - Buildservice: Rejected by (adrianSuSE) - reject date: 2010-01-21 12:15:54 - reject reason: security concerns are much more critical as you describe - it here, since one package in any repo you have added can take over - your entire system. people would need to setup xen/kvm and would be - easily to allowed to inject packages with complete wrong content. - one can work out a concept to handle all these cases, but this is - beyond the scope of this faterequest. + Buildservice: New Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Description: Build performance should scale, in proportion to the number of users, and not the number of build nodes. Put another way - providing a means to apply local CPU horsepower to the channel, combined with some approach (eg. an xdelta to the previous built binary RPMS) to overcome the (typically) assymetric bandwidth availability in a typical DSL client - easy to download a reference to diff against, hard to up-load it. I would love to donate my CPU resource to help accelerate the projects I care about; as - no-doubt would others. Of course - this has security implications, which are (most likely) more or less meaningless. We ship binaries (re-)built from internal, signing servers anyway, and we have an authentication structure in place: if paranoia reigns, we could restrict that to a further subset of privileged users. + Discussion: + #1: Michael Meeks (michael_meeks) (2010-01-22 14:12:19) + Again, please re-consider. There are many circumstances where the risk + is really low. If you trust all the people in the commit chain - there + is simply no issue: surely. + eg. people trust openSUSE released versions, and their updates - + because we have great quality, and (of course) because the packages are + signed. + If I have a home repository eg. that I trust the committers to, + building against only signed repositories, I see no reason why there is + any security issue whatsoever with me building my own binaries, with my + own CPU power, for my own home channel. + Fundamentally though - if we cannot scale our build horsepower in + proportion to the number of our users, surely, we will just choke in + the end however well we design the system. + Would you really not let people choose the level of security risk they + are willing to tolerate, and build locally on their machines (in a + chroot jail or whatever). -- openSUSE Feature: https://features.opensuse.org/308836
Feature changed by: Sascha Peilicke (saschpe) Feature #308836, revision 4 Title: performance: scaling ... - Buildservice: New + Buildservice: Rejected by Sascha Peilicke (saschpe) + reject reason: Unrealistic, reasons given. Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Partner organization: openSUSE.org Description: Build performance should scale, in proportion to the number of users, and not the number of build nodes. Put another way - providing a means to apply local CPU horsepower to the channel, combined with some approach (eg. an xdelta to the previous built binary RPMS) to overcome the (typically) assymetric bandwidth availability in a typical DSL client - easy to download a reference to diff against, hard to up-load it. I would love to donate my CPU resource to help accelerate the projects I care about; as - no-doubt would others. Of course - this has security implications, which are (most likely) more or less meaningless. We ship binaries (re-)built from internal, signing servers anyway, and we have an authentication structure in place: if paranoia reigns, we could restrict that to a further subset of privileged users. Discussion: #1: Michael Meeks (michael_meeks) (2010-01-22 14:12:19) Again, please re-consider. There are many circumstances where the risk is really low. If you trust all the people in the commit chain - there is simply no issue: surely. eg. people trust openSUSE released versions, and their updates - because we have great quality, and (of course) because the packages are signed. If I have a home repository eg. that I trust the committers to, building against only signed repositories, I see no reason why there is any security issue whatsoever with me building my own binaries, with my own CPU power, for my own home channel. Fundamentally though - if we cannot scale our build horsepower in proportion to the number of our users, surely, we will just choke in the end however well we design the system. Would you really not let people choose the level of security risk they are willing to tolerate, and build locally on their machines (in a chroot jail or whatever). + #2: Sascha Peilicke (saschpe) (2010-12-17 16:06:55) + As you said, this depends on trust. Sure, we may trust the majority of + our users, but that doesn't mean that no one abuses this. There's no + guarantee to not get arbitrary trash send back instead of a working + package. The result would have to be tested/checked sent through + ClamAV, you name it. + SETI let's several users process the same set of data and then compares + the results. While this mitigates some of the mentioned risks, it's a + lot of processing again ... -- openSUSE Feature: https://features.opensuse.org/308836
participants (1)
-
fate_noreply＠suse.de