One other keepalive on this thread is that I'd really like for us to move to using ssh as the primary means for publishing source, at least for clone/pull. HTTP is fine for browsing/eyeballing, but anyone who means to build off the source should be able to do server authentication as an integrity measure, which means either ssh or https. This protects against things like name service-based MITM, which is quite easy to do (additional note: nice if we got DNSSEC going for openindiana.org).
Following the line of thinking even as it becomes a distinct question from source structure and integrity: as we're trying to improve our security posture in rolling out stable, I'd at least suggesting releasing stable with signed packages, so that binary distribution is also protected, albeit by cryptographic protection of the packaging envelope rather than transport integrity. I don't have experience of the latter, but a) I have some background with cryptography and willing to learn new applications and 2) suspect that Triskelios and others from Illumos will have some experience of it from within Sun/Oracle. We can discuss on #oi-dev and/or at the next meeting. I reckon the EC folks have their hands full at the moment, so I thought it better to post notes here as I'm thinking these things through rather than pumping them onto IRC. On 24 May 2011, at 17:00, Bayard Bell wrote: > I'm bumping this, as part of the problem that needs sorting is where to > manage security patches that need doing around 151. I had an agenda item for > last week's meeting to discuss this. > > Hopefully we'll be able to discuss this at today's meeting (which *is* > happening? ;->). > > On 18 May 2011, at 18:54, Bayard Bell wrote: > >> Just a couple of notes as I've been been a bit frustrated with the way that >> merge queues are used in OI. I've got nothing against merge queues, it just >> seems that the source should be offered with merges already done. OI source >> should be accessible in the repos for cloning or browsing without requiring >> someone to merge. That's not to say that the patches shouldn't also be just >> as accessible, as well as the upstream source. It doesn't seem auspicious to >> me that the top of the OI builds docs contain a pointer to a page on using >> MQ. What I'd prefer to see is a source namespace that looks like: >> >> hg.openindiana.org\ >> upstream\ >> illumos-gate\ >> onnv_147\ >> [etc.] >> userland-gate\ >> build-165\ >> [etc.] >> [etc.] >> oi\ >> illumos-gate\ >> oi_147\ >> [etc.] >> userland-gate\ >> oi_147\ >> [etc.] >> mq\ >> illumos-gate\ >> onnv_147-oi_147\ >> [etc.] >> userland-gate\ >> build-165-oi_147\ >> [etc.] >> >> If people want to see what's in OI or pull OI source, there it is. OI >> releases under active development may be a separate case that require people >> to pull merge queues. I've also been thinking about how to maintain patches >> for CVE audits/incident response going forward. What I'd suggest, building >> on the previous suggestion is just to have a second series of merge queue >> that goes on top of an OI release and is regularly merged into the release, >> so that it can remain private. Thus: >> >> >> sec_mq\ >> illumos-gate\ >> oi_147\ >> [etc] >> userland-gate\ >> oi_146 >> [etc.] >> >> I'll admit some of this is just plain branding: OI, as source should be able >> to be somewhat self-referential. If people want to understand how it works >> back upstream, fine, but the current system comes across to me as a bit >> baroque. I'm sure I don't entirely appreciate the reasoning of the current >> system, but hopefully your responses will get me there. >> >> Cheers, >> Bayard >
smime.p7s
Description: S/MIME cryptographic signature
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ oi-dev mailing list [email protected] http://openindiana.org/mailman/listinfo/oi-dev
