Yes, builtin CDN offload is actively under discussion as part of v2 protocol changes, but there is nothing currently available in released versions. The "repo" command that comes with Android dev tools uses the clone.bundle approach (which is basically what we're implementing on git.kernel.org for a handful of core repositories). I would guess "repo" is partly why nobody added anything like this directly to git -- for Google, that particular itch has been scratched.
Anyway, here's hoping that the coming protocol changes will have a native solution to this problem.
It's not really a recommendation. It's presented as one of the free software projects attempting to tackle workstation security. Another one is SubgraphOS.
"The only serious attempt at workstation security"
"The Volvo of blah blah"
Quite a slam to those of past and present that handed NSA or DOD pentesters their asses back to them. Maybe be more accurate if you said "a FOSS attempt at workstation security" minus Volvo part. Volvo probably goes to INTEGRITY-178 as SKPP cert requires more attack areas to be covered plus 2 years of pentesting for kernel. Genode Architecture is prime contender for FOSS far as foundations go. Next time a FOSS project claims to be designed securely just ask for a covert storage and timing channel analysis of any components that handle secrets. They'll either say "Huh? What's a covert channel analysis?" or "We don't really have anyone doing that as we're too understaffed or it doesn't really matter." ;)
I'm sorry you all have to read just the slide deck. It's an hour-long presentation and a lot of content is simply not in the deck. :( Unfortunately, every time I've presented it, the talk was not recorded -- hopefully I'll eventually present it somewhere else that will capture it for me.
It's a good presentation with many good points outside the horrid formatting. Just turn it into a PDF with slides for goodness sakes. Write key pages on a piece of paper for audience questions where you have to go back. Should work fine. :)
Btw, one thing worth correcting is false claim that QubesOS was or is only attempt at workstation security. I've evaluated almost a dozen over past 10 years with some still existing. List those here:
You really need to look up separation kernels as isolating most critical stuff in a dedicated partition protected with 4-12kloc kernel is one of strongest approaches. seL4 and Muen are examples with GenodeOS an example of FOSS attempt to do a Nizza-like architecture with strong foundation and best-of-breed components (esp Nitpicker GUI). High-assurance security is moving forward with hardware-software architectures with one maybe getting SOC release (plus source code) in 1-2 years. Yet, our prior work with separation kernels/VMM's plus safe code (esp SPARK Ada or C w/ Astree Analyzer) for trusted components is still stronger than any crap mainstream FOSS, VMware, etc are making. They rarely learn from the past.
Note: Email me if you want more examples of past and current high-assurance work. I have collected them for most focus areas with papers, prototypes and/or products.
> Btw, one thing worth correcting is false claim that QubesOS was or is only attempt at workstation security.
You must look at my statements in the context of presenting this at the Linux Security Summit. You know a lot more about this than me, obviously, but from what I can tell, each of the other solutions you mention run custom non-Linux microkernels that provide virtualization to other consumer OSes. I'm ready to be educated here, but I believe I didn't misstate that QubesOS was one of the first pure-Linux mainstream attempts at workstation security through compartmentalization.
Re slides. Oh, I must have misread meaning of one of your comments. I got a PDF to share now. Good. :)
Re "one of the first pure-Linux mainstream attempts"
Damn, I'd have had you if you didn't say mainstream. This statement is so well-worded I might have to agree with it. Sad part, though, is it's because mainstream rarely accepts anything more secure, esp high integrity/security. Rust and QubesOS are among a tiny set of exceptions.
If you want to give the talk at the CloudFlare office in SF or London (can get a couple other speakers -- maybe about network services), we could provide food for attendees and either free for 100-300 people or have people make a donation to Linux Foundation. Getting it professionally recorded so you could put it online somewhere would be easy; I can give you the files, or we could find a place to host them.
Thank you very much for the offer. I'm not sure I can easily take you up on that, as SF and London are about equally far from Montreal. I'll try to see if perhaps I can do an on-air hangout.
Of course, if the company leadership doesn't care, then you will have a hard time convincing them why the upfront effort of "doing it right" is worth it. When dealing with this situation, I found it useful to compare IT security people to lawyers. Wait, hear me out before you shout me down. :)
To the non-initiated, lawyers and infosec people are seen with nearly-equal amount of both dislike and trepidation. They are seen as a force of lawful evil that descends on your team and starts telling you that all those cool things you're trying to do cannot actually be done, or must be done in a non-obvious roundabout way. When asked for reasons, both lawyers and infosec start talking about concepts that are entirely unfamiliar to most devs (code provenance, license agreements, trademarks, patent litigation, IP isolation, containers and namespaces, RBAC policies, multifactor authentication). All you care about is that this is a person who is telling you that your project, 99% complete after your team worked multiple 60-hour weeks, must be delayed until a bunch of things -- that you don't consider broken! -- are fixed.
However, this is where things usually go differently. If a lawyer comes to management and says "this project cannot launch because a bunch of code was copy-pasted from stackoverflow and links with an incompatibly-licensed library," the management is likely to listen even if they don't understand a word of what was said -- because they know the importance of lawyers and know that, in the long run, litigation is extremely expensive. However, if an infosec person comes to them and says "this project cannot launch because they have a PHP script running as root that listens on external port 80," management will not value this input nearly to the same degree, even though, in the long run, a bad security vulnerability can have just as much of a detrimental impact on a company as litigation -- and probably worse, because you won't be able to hush-hush and "settle out of court."
The reasons for this are multiple -- infosec is in infancy compared to the legal field, and, sadly, many IT security practitioners tend to look and act in a way that makes their recommendations carry so much less weight with upper management.
So, where I'm going with this is -- if you work for a company in an infosec field and you genuinely want to improve things to the point where management actually starts to listen (which translates into $$ for your team and your projects), then you need to both convince them that your expertise is equally as important as the lawyers', and probably present yourself with the same amount of gravitas as those working on the legal team.
The slides interface is supposed to be for the presenter, really, not for the general public. The benefit to the presenter is if someone from the audience says "I'd like you to go back to the slide where you talked about X" -- finding the slide in a 2D-organized deck is much easier by going to overview and finding the right contextual column.
I find slides.com very handy because I can present from any web browser and don't have to worry about bringing my laptop.
