|
|
|
Security integration with state package.
Provides for principals created when corrresponding states are
created that have agents associated.
https://code.launchpad.net/~hazmat/juju/states-with-principals/+merge/100783
(do not edit description out of merge proposal)
Patch Set 1 #Patch Set 2 : Security integration with state package. #
Total messages: 12
|
hazmat
Please take a look.
|
13 years, 9 months ago (2012年04月04日 13:25:39 UTC) #1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Please take a look.
As we discussed before, this looks like a pretty significant change for that point in time. Either way, if you want to go with it, we need a written down description of what is going on here in terms of changes to the public interfaces, as usual.
On Wed, Apr 4, 2012 at 10:32 AM, <n13m3y3r@gmail.com> wrote: > As we discussed before, this looks like a pretty significant change for > that point in time. > > Either way, if you want to go with it, we need a written down > description of what is going on here in terms of changes to the public > interfaces, as usual. > > https://codereview.appspot.**com/5966076/<https://codereview.appspot.com/5966... It seems to be the number one concern regarding the failed MIR. The implementation here is per the security spec discussed last fall, incorporating feedback from the initial reviews. The spec is out of date (uses ensemble instead of juju), and per feedback the OTP agent was dropped for interceptable OTP tokens. There aren't any public interface changes, just the imposition of ACLs onto existing nodes. I can update the spec and send it around to the list if you'd like.. but as is, the components can effectively be merged as the default security policy is permissive, ie no functional delta till the policy is activated. -k
On 2012年04月04日 15:53:23, hazmat wrote: > It seems to be the number one concern regarding the failed MIR. My understanding is that the MIR has been dropped. > The implementation here is per the security spec discussed last fall, > incorporating feedback from the initial reviews. The spec is out of date > (uses ensemble instead of juju), and per feedback the OTP agent was dropped > for interceptable OTP tokens. > > There aren't any public interface changes, just the imposition of ACLs onto > existing nodes. Please see the mailing list conversation about what "public changes" means. The message subject is "Code reviews and public API changes". > I can update the spec and send it around to the list if you'd like.. but as > is, the components can effectively be merged as the default security > policy is permissive, ie no functional delta till the policy is activated. The management of the Python code base is under your control, as we agreed. What I'm concerned about is with changes that are landing without being debated for 12.04 (hint: we *are* in 04!).
On Wed, Apr 4, 2012 at 13:10, Kapil Thangavelu <kapil.thangavelu@canonical.com> wrote: >> On 2012年04月04日 15:53:23, hazmat wrote: >> > It seems to be the number one concern regarding the failed MIR. >> >> My understanding is that the MIR has been dropped. >> > > hence the term 'failed' If it's failed, it's not an argument to have changes going in now. > ic. we've publicly debated these changes previously last fall, > i believe your saying that that process needs to be done again? Sorry, I don't want to frustrate you at all, but try to look from another perspective: there's a release of Ubuntu *this month*, and we're rushing with a Go implementation to catch up meanwhile. Then, there's that massive change set that has seen zero debate in the mailing list. I hope it's not a surprise that I'm asking more details. Besides that, where's that previously reviewed document that you mention? It's not linked from this proposal, and I can't find it anywhere.
On Wed, Apr 4, 2012 at 12:43 PM, <n13m3y3r@gmail.com> wrote: > On Wed, Apr 4, 2012 at 13:10, Kapil Thangavelu > <kapil.thangavelu@canonical.**com <kapil.thangavelu@canonical.com>> wrote: > >> On 2012年04月04日 15:53:23, hazmat wrote: >>> > It seems to be the number one concern regarding the failed MIR. >>> >> > My understanding is that the MIR has been dropped. >>> >> > > hence the term 'failed' >> > > If it's failed, it's not an argument to have changes going in now. > > ic. we've publicly debated these changes previously last fall, >> i believe your saying that that process needs to be done again? >> > > Sorry, I don't want to frustrate you at all, but try to look from > another perspective: there's a release of Ubuntu *this month*, and we're > rushing with a Go implementation to catch up meanwhile. Then, there's > that massive change set that has seen zero debate in the mailing list. I > hope it's not a surprise that I'm asking more details. > > Besides that, where's that previously reviewed document that you > mention? It's not linked from this proposal, and I can't find it > anywhere. > > https://codereview.appspot.**com/5966076/<https://codereview.appspot.com/5966... The mir failed in part because of lack of appropriate security, and the security concerns remain an issue to adoption. for reference this was the original spec https://code.launchpad.net/~hazmat/juju/security-specification/+merge/63921 it was discussed in depth @ austin sprint http://pad.ubuntu.com/cUU8nlRZ4U i mispoke when i said it was previously discussed on list, while its discussed in the context of several other threads, i don't see a dedicated thread to it offhand. what i'm asking for is direction wrt to your comments.. i've updated the security branches and cleaned them up. If you'd like me to bring it up on list, i'm happy to push the spec there. If its something that should be dropped.. well then pls say that.. at this point clearly i'm not too concerned about wasting time effort on dead code. -k
On 2012年04月04日 17:43:36, hazmat wrote: > The mir failed in part because of lack of appropriate security, and the > security concerns remain an issue to adoption. A broken implementation is a much more serious concern for adoption. > for reference this was the original spec > https://code.launchpad.net/%7Ehazmat/juju/security-specification/+merge/63921 "Needs Fixing on 2011年06月09日" > what i'm asking for is direction wrt to your comments.. i've updated the > security branches and cleaned them up. If you'd like me to bring it up on > list, i'm happy to push the spec there. If its something that should be > dropped.. well then pls say that.. at this point clearly i'm not too > concerned about wasting time effort on dead code. Do you want me to say one more time? Sure: I think it is a bad idea to be merging massive changes for 12.04 at this stage. I would not do it. I would not be merging all those significant changes right before a release. It's supposed to be stable. Let's please not ship crack in 12.04.
On Wed, Apr 4, 2012 at 15:43, Clint Byrum <clint@fewbar.com> wrote: > I think they are equally serious, and adoption will suffer on the backend > (as people get more serious) if the security is not handled. One side of > me says we should at least ship an insecure toy, so that people can try > it out. But the other hand says we already did that in 11.10, and doing > so again would only waste peoples' time who are actively looking to deploy > with juju. Perhaps its better that we ship secure with bugs than insecure > with less bugs, and push hard to fix those problems as they are found. This was a great topic for us to have had at the last UDS. It's now time to ship 12.04, which was supposed to be a stable release, in my humble opinion. > Perhaps we can defer the large impact that this work carries until > after 12.04 releases, and instead focus on just fixing the "wide open > zookeeper" problem with a minimal patch that just adds a basic ACL like > "anonymous can't do anything", and be able to pass generated credentials > to each node? That sounds less complex and thus preferable as an entry point. It was once the whole point of that never-used admin-secret setting, by the way. That said, I'd still postpone that to 12.04.1. It's time to stop changing juju and preparing for an actual release. I can use juju in EC2 knowing zookeeper is open. I won't use juju anywhere if it breaks all the time.
On Wed, Apr 4, 2012 at 1:50 PM, <n13m3y3r@gmail.com> wrote: > On 2012年04月04日 17:43:36, hazmat wrote: > >> The mir failed in part because of lack of appropriate security, and >> > the > >> security concerns remain an issue to adoption. >> > > A broken implementation is a much more serious concern for adoption. its unclear how the implementation which has yet to land got classified as broken.
On 2012年04月04日 19:02:10, hazmat wrote: > its unclear how the implementation which has yet to land got classified as > broken. Kapil, it's your take. I'm not going to be the bad guy again. If you want to release this work in 12.04, just provide an up-to-date document explaining in detail what's being suggested as far as the external interactions go, and I'll review.
On 2012年04月04日 19:13:54, niemeyer wrote: > On 2012年04月04日 19:02:10, hazmat wrote: > > its unclear how the implementation which has yet to land got classified as > > broken. > > Kapil, it's your take. I'm not going to be the bad guy again. If you want to > release this work in 12.04, just provide an up-to-date document explaining in > detail what's being suggested as far as the external interactions go, and I'll > review. all right given the effort and timeline it seems more important to work on bug fixes for 12.04 instead of this. i'll bring it back up post release for 12.04.1