illumos is already using ssh as the primary hg mechanism, fyi. Seems to work far better than http.
-- Garrett D'Amore On May 25, 2011, at 3:45 PM, "Bayard Bell" <[email protected]> wrote: > 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 >> > > _______________________________________________ > oi-dev mailing list > [email protected] > http://openindiana.org/mailman/listinfo/oi-dev _______________________________________________ oi-dev mailing list [email protected] http://openindiana.org/mailman/listinfo/oi-dev
