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.
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.
> 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.
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.
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.
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.
> Any security checklist should start with a description both how the machine is to be used and the expected threats models.
It states right at the top that the target audience is Linux sysadmins and their workstations.
> It has some good advice, but is certainly not comprehensive.
"This, by no means, is an exhaustive "workstation hardening" document, but rather an attempt at a set of baseline recommendations to avoid most glaring security errors without introducing too much inconvenience."
Not everyone has an evil agenda. And, if you read the guide, it specifically mentions the downsides of SecureBoot and offers alternatives (AntiEvilMaid).
You actually tend to never use the root password on a modern workstation -- just sudo. The situations where you have to use a root password are usually if something has gone wrong and you have to log in via tty.
It redirects to a site with a valid certificate belonging to "The Linux Foundation." To a domain with a whois record belonging to The Linux Foundation. With DNS servers belonging to the Linux Foundation.