-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SEC] potential security issue related to GitHub CI servers? #6406
Comments
GitHub support reply on the second issue (blocklist)
No clear "next step" or instructions how to resolve were given so far. |
Related: pypa/pip#12680 It doesn't seem like something we should be worried about. |
On second thoughts, we should keep an eye out, just in case (I'm looking at you xz) |
I think our problem is not an instance of this - the hashes in the error logs are very different, not just lower/uppercase variants. |
Reply from GitHub support: Please rest assured that this has not been a widespread issue impacting GitHub services or resources. Nevertheless, while this has not been a widespread issue, we have communicated this with AVG directly. But with respect to next steps regarding the blacklisted log URL, the only other thing we can advise right now is that you send your feedback to AVG to notify them of the false positive too. And on the topic of the more recent issue regarding the package SHAs: This doesn't appear to be related to AVG's blacklisting; instead, it's likely related to some kind of build, deployment, or CICD workflow process expecting one version of a dependency that's pinned to a particular commit, but receiving a different one. Do you happen to be using a The reason I ask is because this error is typically seen when using Python's pip package manager with a requirements file that includes hashes for each package. The hash is a way to verify the integrity of the downloaded package, ensuring it has not been tampered with. The error message is suggests that the hash of the downloaded package does not match the expected hash listed in the requirements file. This could be due to:
To update the hashes in your requirements file, you can use the pip freeze command to get the current versions and hashes of your installed packages, and then update your requirements file with this information. But please also note that this will overwrite your current requirements file, including any packages you've installed that are not in your requirements file. |
My analysis of this is:
I will follow up. |
My reply to GH support:
|
Response by GitHub support, indicates the log access is legit false positive. Hi Franz, Thanks for that. So we have concluded our investigation and I have the following updates for you. For the blacklisted URLs you brought to our attention:
These were false positive flags by AVG, and everything in these flagged URLs matches the data we have in the backend. The URLs are generated from Azure Blob storage and we have no evidence of a security breach. Even if this was a man-in-the-middle attack, we would have TLS failures making it evident. In short, all the details of the URL match the backend data we have and there's no indication of foul play here. We have brought this up with our counterparts at AVG; however, as I'm sure you can understand, we cannot share anything about the nature of the communication, or give any guarantees about what actions might be taken from their side. We also reviewed the workflow runs themselves and found no tampering or issues with them. If and where possible, I advise contacting AVG to mark this as a false positive, as we have no control over what AVG says is a threat. It's likely these URLs are hitting some common rule that their software uses by default. In addition to the URLs above, we can confirm that we don't have any indication that there are any security threats from accessing any of our blob storage URLs:
We want to reinforce that these are all owned and managed by GitHub Actions and there are no indications of security threats. For a full list of URLs and IPs, see: https://api.github.com/meta. Thanks again for reporting this and for your concern about the security of GitHub's products. Kind regards, Dan | GitHub Support Engineer |
New reply from GitHub support: Hi Franz, Yes - sorry about that. So this is tricky, as it's not directly related to an issue with GitHub Actions itself, so may be pushing outside of the scope of what we can help you with. Nevertheless, I'll do my best to help. We haven't seen anything that suggests this is a security concern. The "THESE PACKAGES DO NOT MATCH THE HASHES FROM THE REQUIREMENTS FILE" error you're encountering is relates to pip's hash-checking mode, and one reason for this is indeed to ensure that the packages haven't been tampered with, but it could also simply be related to a network issue during the download of your packages. In short, this error gets thrown when the hash of the downloaded package doesn't match the projects requirements, and this could be for a number of reasons. I appreciate we've touched on it before, and you may have your reasons for this, but I can see that there is no requirements.txt file in sktime/sktime. This may be related and could prevent the error, even if it only comes up intermittently, as the file would let you specify exactly which dependencies and which versions are needed for your project. Other reasons for this error could be:
Here are a few general steps that might help with troubleshooting.
Something else that may help: We also have a setup-python Action that can be used for caching dependencies in Python projects. The action creates and restores a cache identified by a unique key, and can also speed up your workflows. Hope that helps! Kind regards, Dan | GitHub Support Engineer |
Analysis of the response:
|
There have been multiple strange occurrences around GitHub CI servers that may be security related:
These also do not always seem to be the same packages, or same sha.
I also wonder whether the two are correlated.
What is going on here? I really hope Microsoft don't have hackers in there...
The text was updated successfully, but these errors were encountered: