diff options
Diffstat (limited to 'zarb-ml/mageia-dev/attachments/20100927/04b37deb')
| -rw-r--r-- | zarb-ml/mageia-dev/attachments/20100927/04b37deb/attachment-0001.html | 18 | ||||
| -rw-r--r-- | zarb-ml/mageia-dev/attachments/20100927/04b37deb/attachment.html | 18 |
2 files changed, 36 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/attachments/20100927/04b37deb/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20100927/04b37deb/attachment-0001.html new file mode 100644 index 000000000..6e80dca6a --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20100927/04b37deb/attachment-0001.html @@ -0,0 +1,18 @@ +<br><br><div class="gmail_quote">2010/9/26 Giuseppe Ghibò <span dir="ltr"><<a href="mailto:ghibomgx@gmail.com">ghibomgx@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> +<br><br><div class="gmail_quote">2010/9/26 nicolas vigier <span dir="ltr"><<a href="mailto:boklm@mars-attacks.org" target="_blank">boklm@mars-attacks.org</a>></span><div class="im"><br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex"> + +<div>On Sun, 26 Sep 2010, joris dedieu wrote:<br> +<br> +> 2010/9/26 Olivier Blin <<a href="mailto:mageia@blino.org" target="_blank">mageia@blino.org</a>>:<br> +> ><br> +</div><div>> > 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></div>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.</div></blockquote><div><br></div><div>What about virtualization?</div><div><br></div><div>Maybe we could set-up some kind of cluster of remote and dedicated vm's as a unique build system. Could be a good workaround over security and integrity issues, 'cause we are using a "single" build system.</div> +<div><br></div></div> diff --git a/zarb-ml/mageia-dev/attachments/20100927/04b37deb/attachment.html b/zarb-ml/mageia-dev/attachments/20100927/04b37deb/attachment.html new file mode 100644 index 000000000..6e80dca6a --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20100927/04b37deb/attachment.html @@ -0,0 +1,18 @@ +<br><br><div class="gmail_quote">2010/9/26 Giuseppe Ghibò <span dir="ltr"><<a href="mailto:ghibomgx@gmail.com">ghibomgx@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> +<br><br><div class="gmail_quote">2010/9/26 nicolas vigier <span dir="ltr"><<a href="mailto:boklm@mars-attacks.org" target="_blank">boklm@mars-attacks.org</a>></span><div class="im"><br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex"> + +<div>On Sun, 26 Sep 2010, joris dedieu wrote:<br> +<br> +> 2010/9/26 Olivier Blin <<a href="mailto:mageia@blino.org" target="_blank">mageia@blino.org</a>>:<br> +> ><br> +</div><div>> > 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></div>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.</div></blockquote><div><br></div><div>What about virtualization?</div><div><br></div><div>Maybe we could set-up some kind of cluster of remote and dedicated vm's as a unique build system. Could be a good workaround over security and integrity issues, 'cause we are using a "single" build system.</div> +<div><br></div></div> |