n Sun, Aug 26, 2012 at 3:54 PM, Pedro Giffuni <p...@apache.org> wrote: > > > ----- Original Message ----- > >> >> On Sun, Aug 26, 2012 at 3:20 PM, Dave Fisher <dave2w...@comcast.net> >> wrote: >>> Hi, >>> >>> We need to do more work to have proper compliance with Apache >> Infrastructure policy in managing external dependencies. >>> >>> I may not be precisely correct and am looking for confirmation, but In >> general i think we need to >>> >>> (1) Completely avoid using svn.apache.org. I don't think we are allowed >> to do this even as a backup URL. >>> >>> (2) Use mirrors or maven for ASF dependencies where we use the current >> release. If we use mirrors then archive.apache.org should be the backup for >> the >> mirror so that we aren't in trouble if the project has a release. If a maven >> repository were used then there would be no issue. >>> >>> (3) If we use mirrors then we should allow the user to choose which mirror. >>> >>> If we decide to take the time to go the maven route. I can use the example >> of ant and maven repos from the Apache POI build.xml. >>> >>> Notes about maven repos. Infra [1], maven central [2] and example of an >> externally hosted repo [3] >>> >>> This area needs careful attention. >>> >> >> Note that this move is exactly the wrong thing to do if we want have >> buildbots build binaries that are assumed to be safe and therefore >> signable. Instead of the security and verifiability of ASF-run host, >> we're putting the dependencies off to a dozen different remote sites, >> with no visibility into their site's mechanisms for vetting changes, >> access controls, auditability of changes, even basics like ensuring >> domain names are renewed and not poached by others. >> > > This is not true. We use checksums precisely to certify the source tarballs > haven't been tampered with. >
If we think that then we're fooling ourselves. Checksums are effective for detecting accidental corruption during transmission, or for detecting when someone casually modifies a file. It does very little to prevent us against malicious changes. To be specific: One can make whatever changes one wishes in a file to insert malicious code, and then via brute force (or better) make other changes to an unrelated file in the archive in order to achieve the desired hash collision. Is it computationally expensive? Yes. Is it impossible? No. Does a binary used by 10 million people present an incentive that would attract that kind of attention? I don't want to find out. This is why Apache releases have the detached digital signature as well. It gives a much higher degree of safety. > > >> Do we really think other websites are as secure as the ones that Infra >> operates? If so we should move the source code to the other sites as >> well, right? >> > > Yes, upstream providers generate checksums and do proper > maintainance of their packages but perhaps more importantly by > working with them we can leverage their mirrors more efficiently. > > I agree with Dave; we have to get rid of those tarballs > in SVN. Python 2.6.1 will be axed today, BTW. > > I haven't looked at Maven but it sounds like something > we should look at.. > > Pedro.
