diff options
Diffstat (limited to 'zarb-ml/mageia-dev/attachments/20100926/88900d00/attachment-0001.html')
| -rw-r--r-- | zarb-ml/mageia-dev/attachments/20100926/88900d00/attachment-0001.html | 16 |
1 files changed, 16 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/attachments/20100926/88900d00/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20100926/88900d00/attachment-0001.html new file mode 100644 index 000000000..3ebb256b9 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20100926/88900d00/attachment-0001.html @@ -0,0 +1,16 @@ +<br><br><div class="gmail_quote">2010/9/26 nicolas vigier <span dir="ltr"><<a href="mailto:boklm@mars-attacks.org">boklm@mars-attacks.org</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +<div class="im">On Sun, 26 Sep 2010, joris dedieu wrote:<br> +<br> +> 2010/9/26 Olivier Blin <<a href="mailto:mageia@blino.org">mageia@blino.org</a>>:<br> +> ><br> +</div><div class="im">> > Because there are some authentication and integrity issues which are not<br> +> > simple to solve: we have to be sure that the binary packages really come<br> +> > from the unmodified SRPM (so that it does not contains malware).<br> +><br> +> This can be avoid by<br> +> - building every package twice (also useful for integrity check)<br> +<br> +</div>Then you can still do it with two hosts adding malware instead of one.<br></blockquote><br>What this means? Two RPMs built at different time will result different, even the executable binaries when built on the same hardware at different time might be different (because of timestamps, etc.).<br> +<br>IMHO the idea of the cloud is not that bad but need to be rethinked. I don't see so much flaws for security. If you inspire to what repsys is right now, the cloud would be like having several svn repositories mirrored around the world each one with a local iurt/repsys building system (it might be even partial, e.g. there could be BIG ones holding the whole svn|git tree, and smaller one holding just the latest release or the latest two releases, etc.). Each building system around the world will sign packages they build with their own signing keys and you know where they come from. And packages won't be resigned by a supposed master. Of course you have to trust their administrators, exactly like you right now have to trust single users submitting sources to the svn and bulding packages.<br> +<br>The most difficult things IMHO would be building from the same syncronized data. In that case you might choose a master server and several mirrors. The master might have multiple internet access points (e.g. from two providers) and will be the only one who might receive svn commits. Or a model without a master, I guess inspiring to a model what UseNET is (was), I think a lot more complicate. But in that case you have two direction of feeding and if two libraries are submitted in different user in nearest time, you need a system to check for coerency and set alarms in some cases.<br> +<br>IMHO one of the building problems was not massive automatic rebuilding but avoid bottenlecks to the users when building goes wrong.<br><br>Bye<br>Giuseppe.<br><br></div> |