3 ms·
They state in the post that of 17 million requests to their git-proxy server, only 230 of those requests could be identified as successful responses to incorrec
by uxp 10y ago
They state in the post that of 17 million requests to their git-proxy server, only 230 of those requests could be identified as successful responses to incorrect data/repos, at a percent of 0.0013%.
I don't know of anyone that would recommend creating tests, even integration tests, that hammers a service to check to see if something like one hundredths of one percent of requests returns invalid data. If anything, the fact that a script is hammering a service that probably (in a Dev or QA environment) has much less data in it's database and file stores, and much less protection (like load balancing and caching) than it would in production would generate more false positives than it would generate in substantial data disclosure regression defects.
- smashed 10y agoBut the overwhelming majority of requests failed with errors. The happy-path was not tested either.
- manquer 10y agoNormally perhaps not, but if you host other people's IP . The risk of a leak like this can have major economic consequences to other organisations which trusted you with security for their code. To me it looks like poor design , I would expect private repos to be hosted completely independently and in isolation with more secure and throughly audited code with longer release cycle (LTS ?) after the code has been well tested in the public free repos. It is not excessive if you consider the potential value of the private repos that github has control over. They already do something similar for enterprise edition. It leaves bad taste that smaller customers are not treated with similar caution