On 12/07/2011 06:20 PM, Denis Arnaud wrote:
As a side note, rather than using Snap (and Augeas, and...), we (in my
department) tend to prefer Chef (http://www.opscode.com/chef/), which
has got a broader scope, and allows much more complex configurations
and automation tasks.
Denis
Chef, l
> Date: Thu, 8 Dec 2011 12:33:38 -0500
> From: seth vidal
>
> I answered Denis immediately at the first post and he concurred it was
> a problem. I like to think the conversation evolved as we discussed.
>
Yes, the conversation has shifted... Indeed, I mixed two distinct ideas:
1. One correspondi
On Thu, 2011-12-08 at 12:33 -0500, seth vidal wrote:
> I answered Denis immediately at the first post and he concurred it was
> a problem. I like to think the conversation evolved as we discussed.
It's probably not worth pursuing this much further, but I'd just note
that the specific sub-thread I
On Wed, 07 Dec 2011 15:25:18 -0800
Adam Williamson wrote:
>
> Well, yes, but only because you shifted the entire terms of the thread
> without telling anyone else. All of the above - about how the idea was
> to build packages with untrusted build dependencies in trustworthy
> places - may have b
On Wed, Dec 07, 2011 at 03:25:18PM -0800, Adam Williamson wrote:
> On Wed, 2011-12-07 at 18:12 -0500, seth vidal wrote:
> > On Wed, 07 Dec 2011 13:25:28 -0800
> > Adam Williamson wrote:
> >
> > > I'm not sure we can treat scratch / personal builds with *quite* so
> > > much abandon. They're still
On Wed, Dec 7, 2011 at 11:12 AM, seth vidal wrote:
> Bandwidth is the big concern for the end user here and then the other
> issue is - is all of this worth it for building pkgs? I don't think it
> is, personally, pkg building is not that huge of a hit, afaict to
> getting things done.
+1 as a c
>
> Date: Wed, 07 Dec 2011 16:01:06 +0100
> From: Richard Marko
>
> I'm currently writing a proposal of similar architecture for testing
> purposes. Looks like the core -- community provided virtual machines is
> the common component for all this stuff so if designed correctly it can
> be shared f
On Wed, 2011-12-07 at 16:15 -0500, seth vidal wrote:
> On Wed, 07 Dec 2011 15:02:42 -0500
> Przemek Klosowski wrote:
>
> > On 12/07/2011 01:25 PM, seth vidal wrote:
> >
> > > If I were going to use random vm's I'd want to:
> > > 1. connect using ssh
> > > 2. push over my own rpm/python/etc binar
On Wed, 07 Dec 2011 13:25:28 -0800
Adam Williamson wrote:
> I'm not sure we can treat scratch / personal builds with *quite* so
> much abandon. They're still valuable targets for anyone trying to
> compromise Fedora, after all.
I don't think you understand - we need to be able to reliably reprod
On Wed, 2011-12-07 at 18:12 -0500, seth vidal wrote:
> On Wed, 07 Dec 2011 13:25:28 -0800
> Adam Williamson wrote:
>
> > I'm not sure we can treat scratch / personal builds with *quite* so
> > much abandon. They're still valuable targets for anyone trying to
> > compromise Fedora, after all.
>
>
2011/12/7 Nicolas Mailhot
> Concerning trust, the classic way it has been solved before (by seti…)
> is to farm the same build to several independant nodes, cheksum results
> and make sure they all agree
>
Again, we could use that P2P build system just to alleviate the centralised
Koji servers f
On 12/07/2011 01:25 PM, seth vidal wrote:
> If I were going to use random vm's I'd want to:
> 1. connect using ssh
> 2. push over my own rpm/python/etc binaries
> 3. checksum all the rest of the installed (and running) software
> 4. verify those checksums versus my known good set
> 5. THEN push ov
An idea just struck me that may work.
If the system is made light enough that it is utterly painless for
anyone to contribute processing time then cross-checking of hashes could
be made statistically secure, save for a widespread compromise of the
entire Fedora userbase.
For example, if I just
On 12/08/2011 05:12 AM, seth vidal wrote:
> Bandwidth is the big concern for the end user here and then the other
> issue is - is all of this worth it for building pkgs? I don't think it
> is, personally, pkg building is not that huge of a hit, afaict to
> getting things done.
>
> I mean the sum t
On Thu, 08 Dec 2011 05:35:02 +0900
夜神 岩男 wrote:
> On 12/08/2011 05:12 AM, seth vidal wrote:
> > Bandwidth is the big concern for the end user here and then the
> > other issue is - is all of this worth it for building pkgs? I
> > don't think it is, personally, pkg building is not that huge of a
On Wed, 07 Dec 2011 15:02:42 -0500
Przemek Klosowski wrote:
> On 12/07/2011 01:25 PM, seth vidal wrote:
>
> > If I were going to use random vm's I'd want to:
> > 1. connect using ssh
> > 2. push over my own rpm/python/etc binaries
> > 3. checksum all the rest of the installed (and running) softw
On Thu, 08 Dec 2011 04:34:57 +0900
夜神 岩男 wrote:
> An idea just struck me that may work.
>
> If the system is made light enough that it is utterly painless for
> anyone to contribute processing time then cross-checking of hashes
> could be made statistically secure, save for a widespread comprom
On 12/07/2011 01:25 PM, seth vidal wrote:
>
>>
>> That would be very cool. Do you intend to use DeltaCloud (
>> http://deltacloud.apache.org/), or something like that?
> I'm using libcloud, actually. I'm interested in pursuing this in
> python, not ruby.
>
Deltacloud's primary interface is
On 12/07/2011 01:40 PM, seth vidal wrote:
> On Wed, 07 Dec 2011 13:35:03 -0500
> Mo Morsi wrote:
>
>> On 12/07/2011 01:25 PM, seth vidal wrote:
>> >
>> >>
>> >> That would be very cool. Do you intend to use DeltaCloud (
>> >> http://deltacloud.apache.org/), or something like that?
>> >
Le mercredi 07 décembre 2011 à 10:36 -0500, seth vidal a écrit :
> I've looked into spawning virt instances to do building and it is
> pretty doable. The problem with them being offered by volunteers is
> trust:
>
> 1. how do we trust the initial installation hasn't been poisoned unless
> we ship
On Wed, 07 Dec 2011 13:35:03 -0500
Mo Morsi wrote:
> On 12/07/2011 01:25 PM, seth vidal wrote:
> >
> >>
> >> That would be very cool. Do you intend to use DeltaCloud (
> >> http://deltacloud.apache.org/), or something like that?
> > I'm using libcloud, actually. I'm interested in pursuing th
On Wed, 7 Dec 2011 18:31:27 +0100
Denis Arnaud wrote:
> 2011/12/7 seth vidal
>
> > I've looked into spawning virt instances to do building and it is
> > pretty doable. The problem with them being offered by volunteers is
> > trust [...]
> >
>
> You are right. I had not thought at that... how n
2011/12/7 seth vidal
> I've looked into spawning virt instances to do building and it is pretty
> doable. The problem with them being offered by volunteers is trust
> [...]
>
You are right. I had not thought at that... how naive of me :(
The volunteers/trustees would sign the builds with their
On Wed, 7 Dec 2011 14:46:18 +0100
Denis Arnaud wrote:
> Hello,
>
> RedHat-hosted Koji servers offer an invaluable service by allowing
> all of us, package maintainers, to build all of "our" Fedora
> packages. I guess that that infrastructure is not cost-less for
> RedHat and and the quality of s
On 12/07/2011 02:46 PM, Denis Arnaud wrote:
> Hello,
>
> RedHat-hosted Koji servers offer an invaluable service by allowing all
> of us, package maintainers, to build all of "our" Fedora packages. I
> guess that that infrastructure is not cost-less for RedHat and and the
> quality of service is
On Wed, Dec 7, 2011 at 8:46 AM, Denis Arnaud
wrote:
> Hello,
>
> RedHat-hosted Koji servers offer an invaluable service by allowing all of
> us, package maintainers, to build all of "our" Fedora packages. I guess that
> that infrastructure is not cost-less for RedHat and and the quality of
> servi
Hello,
RedHat-hosted Koji servers offer an invaluable service by allowing all of
us, package maintainers, to build all of "our" Fedora packages. I guess
that that infrastructure is not cost-less for RedHat and and the quality of
service is great (for instance, the wait in the queues, before Koji
a
27 matches
Mail list logo
