First:
- pycurl is still the default https implementation used if it is installed,
- users concerned with security are better served by using ssh and signing their revisions.
That being said, I suspect the more likely potential victims may not be aware of the problem at all and may not install pycurl nor use ssh nor sign their revisions.
Now, setting up a mitm attacjk alone is not enough, you also need to inject malicious code in a repo while still faking the signatures and sha1 associated with the revisions and that nobody check the code nor inspect the merge results.
That sill leave a narrow window for people not signing and I'm not sure we check the sha1 in all scenarios either.
But given the work involved on our side to even diagnose if such an attack is feasible, I think we should just implement https support properly for our urllib-based implementation.
I think most of our users are using python2.6 now, so supporting 2.4 and 2.5 is less concerning than it was last time I worked on the subject.
First:
- pycurl is still the default https implementation used if it is installed,
- users concerned with security are better served by using ssh and signing their revisions.
That being said, I suspect the more likely potential victims may not be aware of the problem at all and may not install pycurl nor use ssh nor sign their revisions.
Now, setting up a mitm attacjk alone is not enough, you also need to inject malicious code in a repo while still faking the signatures and sha1 associated with the revisions and that nobody check the code nor inspect the merge results.
That sill leave a narrow window for people not signing and I'm not sure we check the sha1 in all scenarios either.
But given the work involved on our side to even diagnose if such an attack is feasible, I think we should just implement https support properly for our urllib-based implementation.
I think most of our users are using python2.6 now, so supporting 2.4 and 2.5 is less concerning than it was last time I worked on the subject.