| There is a lot of very good evidence that "bolted on" security makes for | "bad security" and that getting it right, by design, from the start, | gives you a much higher chance of success. | | Darren R <[email protected]>
| Bottom-line: by designing without security in mind, you're likely to | screw up in ways that require that you go back to the drawing board. | Spending a little more time gathering requirements and thinking about | these related problems will reduce the likelihood that you'll have to | re-design later. | | Nico <[email protected]> This argument has ceased to be productive. It disingenuous to make claims like this -- they're false. Many of us have solicited input from the security team on various portions of our designs. Sometimes feedback was provided, but other times our requests were ignored. We've had meetings with different members of the team to discuss high-level concepts. The assertion that you're not being included is false and unproductive. Different portions of pkg(5) are going to be designed by different people at different times. So far, the security proposals written in response to this thread have been vague and underspecified. I agree with Shawn. We must first define the objects and their relationships to one another. Once we've figured that out, we can ask the larger questions about the security implications, and then refactor the design into something that addresses everyone's concerns. The current argument insists we put the cart before the horse, and then claims our team isn't in favor of carts. It's non-sensical. I would like to continue to include the Security team in this project, however, the proecess of lobbing unfounded accusations at the I-team has to stop. If you'd like to participate, there are a number of things that you can do today that would be enormously helpful: 1. Review Bart's design on manifest signing. (I think he already sent out an e-mail to this effect). 2. OpenSolaris needs a default set of CA certs and a common location for finding them. Pkg(5) needs to make use of this. I've had to work around the absence of such a facility. If we can finish the ARC case for this, and get the support integrated, it would help a lot. 3. Shawn and Bart have discussed catalog sigining and manifest signing, but I don't know if a final design document was ever issued. If someone has time to review the Catalog v1 specification, and provide guidance about a Catalog signing design, that might be useful too. (I'll defer to Shawn on whether he wants this advice now or later, though). 4. Participate constructively in the design discussions that are going on now. We're not trying to exclude/preclude security, but in some cases we need to agree on a common set of first principles before we can delve into details. 5. Help us write code. We have a lot of work to do, so if there's an area of the code that you think needs specific improvements, drop us a line with a proposal for how you want to fix it. Chances are, we'll buy you a beer next time we see you. 6. Test, find, and file bugs. It's obvious, but worth mentioning. | Or perhaps you should consider dealing with the security bits first and | placate the loud voices, so that you can move on to the other things with that | tucked away under your belt. | | Darren R <[email protected]> I don't consider it appropriate to reward childish, attention-seeking behavior. The expectation is that we all behave like adults. Thanks, -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
