Posted by: Anonymous Coward
on October 27, 2004 03:07 AM
The author and various readers note that infiltration is not particularly a problem with the open source development model. In all development models, anyone with sufficient access to the development environment could compromise it. Larger organizations are more likely to be exposed to such compromises, if only because more people are involved. Moreover, there is a strong financial incentive for proprietary developers to put competing products at a disadvantage.
My view is that the open source model presents us with a perfect opportunity to work on the general problem of authenticating contributions to the code base. The results can equally be applied to closed source development, but I believe that the open source model is a more realistic setting in which to develop effective solutions. We begin with the assumption that much of the development infrastructure in an open source project lies outside the control of the project. So a given contributor may be a nice guy, and may have properly signed all his contributions, but if he has practiced poor security hygeine on his own system, his contributions may be tainted.
This problem is obvious in open source development. What's perhaps not so obvious is that closed source organizations are not exempt from the effects of poor security hygeine. In theory, security could be tighter in a closed environment, but in practice very few organizations are willing to undergo the inconvenience of rigorous "clean room" discipline. Indeed, it would be unwise to assume any level of security as characteristic of closed source environments. In my experience as a security consultant, I've noticed that closed source developers are often expected to maintain their own systems, they often have persuaded management to give them root on the servers, and they often work from home. The outsourcing of development work provides similar opportunities for compromise.
In the open source community, our advantage is that we can face this problem head on. It's a question of authenticating both developers and their systems. In a sense, it's about DRM as well, but not the kind of mandatory "digital restrictions management" that conspires to put our systems outside of our control. This would be a more advisory kind of DRM by which we could mutually negotiate on compliance to agreed security standards. My point is that we need to take the lead on these decisions for our own benefit, or else we may find that they have been made for us. And that's not in the spirit of open source at all.
Learn about Linux
Download Linux
Get Linux help
Authentication
Posted by: Anonymous Coward on October 27, 2004 03:07 AMMy view is that the open source model presents us with a perfect opportunity to work on the general problem of authenticating contributions to the code base. The results can equally be applied to closed source development, but I believe that the open source model is a more realistic setting in which to develop effective solutions. We begin with the assumption that much of the development infrastructure in an open source project lies outside the control of the project. So a given contributor may be a nice guy, and may have properly signed all his contributions, but if he has practiced poor security hygeine on his own system, his contributions may be tainted.
This problem is obvious in open source development. What's perhaps not so obvious is that closed source organizations are not exempt from the effects of poor security hygeine. In theory, security could be tighter in a closed environment, but in practice very few organizations are willing to undergo the inconvenience of rigorous "clean room" discipline. Indeed, it would be unwise to assume any level of security as characteristic of closed source environments. In my experience as a security consultant, I've noticed that closed source developers are often expected to maintain their own systems, they often have persuaded management to give them root on the servers, and they often work from home. The outsourcing of development work provides similar opportunities for compromise.
In the open source community, our advantage is that we can face this problem head on. It's a question of authenticating both developers and their systems. In a sense, it's about DRM as well, but not the kind of mandatory "digital restrictions management" that conspires to put our systems outside of our control. This would be a more advisory kind of DRM by which we could mutually negotiate on compliance to agreed security standards. My point is that we need to take the lead on these decisions for our own benefit, or else we may find that they have been made for us. And that's not in the spirit of open source at all.
#