We can confirm that on 2019-07-06 there was a Canonical owned account on GitHub whose credentials were compromised and used to create repositories and issues among other activities. Canonical has removed the compromised account from the Canonical organisation in GitHub and is still investigating the extent of the breach, but there is no indication at this point that any source code or PII was affected.
Furthermore, the Launchpad infrastructure where the Ubuntu distribution is built and maintained is disconnected from GitHub and there is also no indication that it has been affected.
We plan to post a public update after our investigation, audit and remediations are finished.
Thank you, your trust in Canonical is important to us, which is why we make privacy and security a priority.
-David on behalf of Canonical
We require 2FA for all accounts under the lxc organization and only grant the access that's actually needed by those contributors. So while it's not impossible that one of our members' credentials may get compromised, especially when considering the use of access token, current access is as restricted as you would expect for those repositories.
It's also worth noting that because of Git's own design, even should one of those accounts get compromised, it would be fairly simple to spot and revert any changes that may have occurred.
This is out of sheer laziness because a USB stick is easier to plug in than Sata. Today I learned it is now has security features as well :)
Canonical is a great thing in my life. Hope they haven't been hit too hard and that they learn how to prevent it.
Lyon ? r/Lyon !
We can see there the palatial fineness of french critical mind.
I can confirm that we're aware of the issue, have done some initial remediation (e.g. shutting down CI systems that might pull potentially compromised code) while we do a more in depth investigation.
And we've of course revoked the access that was abused.
Always sign your commits!
We do NOT know this.
> We do NOT know this.
Well, at least we know that the attackers wanted their activities to be noticed at this point in time.
I have reasons to suspect that this is a compromised account, in which case there should be enough forensics info to figure out what the scope of the damage is.
Likewise, I wonder if git differentiates signatures where the keys are set as trusted in gnupg, and those that are not.
They do this
Sure, if GitHub wanted to completely abandon the decentralized nature of Git and be a completely centralized system. Which it would love to, I'm sure, but I don't think the user base is quite ready for them to completely shut off any repository with any commits not made by Github users, and posted to GitHub through the account of the user who made the commit, which is what you are suggesting.
How on earth do you know they haven't done both?!
Thus maintainers usually sign merge commits and it's their job to confirm that commits don't do anything shady and come from people they claim to come from.
Unfortunately PGP is fundamentally broken. Any identity (email address) can be trivially DoS'd by anyone, because the keyservers are (by design) write-only databases which anyone can add to.
I don't need a key server for me to sign or validate that something was signed by who it said it was if exchanged my keys via a secure means.
It has no effect on GitHub, though, which doesn’t use keyservers as part of its validation process.
</var/lib/apt/lists/*_debian_dists_testing_main_source_Sources.lz4 unlz4 |
sed -n '/^Vcs-Browser:/n;s/^Vcs-\([A-Za-z]*\): .*/\1/p' |
The sources can be pulled directly from Debian as tarballs using [syncpackage]. Ubuntu maintainers are free to use their preferred VCS for maintaining Ubuntu-specific packaging. Using the same VCS as the Debian maintainer (or upstream developer) is often convenient, but not required.
> Woulda thought they used SVN primarily since they pull from Debian