Bugzilla – Full Text Bug Listing
| Summary: | Dynamic discovery (remote peer monitor) does not work with security enabled | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Qiyan Li <qiyanli> |
| Component: | TPTP | Assignee: | Bing Xu <xubing> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P2 | CC: | ashishp, ewchan, jgwest, jkubasta, jptoomey, rdanek, sluiman |
| Version: | unspecified | Keywords: | plan |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | housecleaned460 closed460 | ||
|
Description
Qiyan Li
*** Bug 101571 has been marked as a duplicate of this bug. *** If you follow the link to the duplicate (which is actually the original bug) you find that this bug has been around for a long time and was deferred from prior releases. So why is it now believed to be a blocker bug for 4.2? In the original bug it was marked as a Major P3. This should be targeted for 4.2.1. Reducing severity to be consistent wih bug 101571, and increasing priority to P1 because of customer need. We still need to do proper sizing and depending on the sizing we will make the decision. This defect was opened so that the defect can show up in TPTP --- the original defect was in Hyades, and slipped through the TPTP defect tracking process. Resetting priority for 4.2.1: - P1: commit to fix - P2: fix if time allows - P3: fix if all P1 and P2 are fixed I would like to stress that products building on top of TPTP need this functionality, so despite priority please take into consideration that the severity of this defect is "major". Adding Hendra for tracking. Retarget to 4.3. Insufficient resource to be done in 4.2.1. I'd like to re-evaluate both the priority and the target milestone of this defect. While it's true that the original defect has been around for a long time, our consuming product was unaffected because, due to the many other limitations of the secure RAC, we simply did not use security at all. Based on feedback that secure AC is a requirement, we have spent time fixing most of those other limitations, but this issue continues to preclude us from using the secure AC. Thus the desire for a higher priority, and to see it fixed in 4.2.1 if possible. I realize this is problematic given Samson & Hendra's absences, but I'd stil like to keep this defect for consideration of 4.2.1, and we can all try to scare up resources with the necessary background to fix it. Adding Bob to the CC list. Not containable in 4.3 and retarget to 4.4. Please let me know if you have any concern. Set priority to P1 for 4.4 plan closure. Not containable in 4.4. Hi Bing. I have transferred my bugs to you for triage. Thanks. Discussed this with Jonathan. The current interface of agent does not support user authentication. Authentication is only implemented on client side. So Peer Monitoring won't work with security turned on. Further investigation is needed in order to provide an estimation. Joanna, can we move it to Future? (In reply to comment #14) > Discussed this with Jonathan. The current interface of agent does not support > user authentication. Authentication is only implemented on client side. So > Peer Monitoring won't work with security turned on. > > Further investigation is needed in order to provide an estimation. Joanna, can > we move it to Future? > Is this actually a regression that is 1.5 years old, or a feature request? Hi Harm, it's a feature request. AFAIK the requirement that the remote peer have the l/p to a valid administrative account on the local machine in order to authenticate itself has always restricted its implementation. The earlier bug (which is a dupe of this for an unknown reason) was opened over two-and-a-half years ago, and hasn't made the cut for any particular iteration. (In reply to comment #16) > Hi Harm, it's a feature request. AFAIK the requirement that the remote peer > have the l/p to a valid administrative account on the local machine in order to > authenticate itself has always restricted its implementation. The earlier bug > (which is a dupe of this for an unknown reason) was opened over two-and-a-half > years ago, and hasn't made the cut for any particular iteration. > Thanks, so check with Eugene and Joanna to make sure this is not required, and then change it to an enhancement request. I can easily see the need for this, but it will not be trivial to design and impl. Joanna and Eugene, Can you confirm that implementation of user authentication was not part of original requirement of agent API? Thanks. > > Hi Harm, it's a feature request. AFAIK the requirement that the remote peer > > have the l/p to a valid administrative account on the local machine in order to > > authenticate itself has always restricted its implementation. The earlier bug > > (which is a dupe of this for an unknown reason) was opened over two-and-a-half > > years ago, and hasn't made the cut for any particular iteration. > > > Thanks, so check with Eugene and Joanna to make sure this is not required, and > then change it to an enhancement request. I can easily see the need for this, > but it will not be trivial to design and impl. The original design of the client did not include the user/password prompt for secure peer discovery connection. It requires communication on the agent side to request and retrieve the user/password from the client side. Ashish, I understand this is a requirement from downstream product that you worked on. Do you know who is the new contact of the product? We need to make sure if this is still a high priority request from product? >> [Bing] Has it been implemented before or never worked?
AFAIK this has never been implemented before and thus never worked. I assume that this was apart of the original design since the single RAC connection case requires a username/pwd; however, I during our dev/testing a few years ago we noticed it wasn't actually implemented. I hope that helps, let me know if you have any additional questions.
Bing, is this feature containable in 4.5? It was requested by a consuming product. Joanna, I will discuss it with Jonathan on Monday (he is off today) to provide an estimation. It is high priority among my open I6 defects. Mass update of P1 enhancements and defects targetted to future to P2. As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As such, TPTP is not delivering enhancements. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement is resolved as WONTFIX. For this enhancement to be considered, please re-open with an attached patch including the Description Document (see http://www.eclipse.org/tptp/home/documents/process/development/description_documents.html), code (see http://www.eclipse.org/tptp/home/documents/resources/TPTPDevGuide.htm), and test cases (see http://www.eclipse.org/tptp/home/documents/process/TPTP_Testing_Strategy.html). As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As such, TPTP is not delivering enhancements. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement is resolved as WONTFIX. For this enhancement to be considered, please re-open with an attached patch including the Description Document (see http://www.eclipse.org/tptp/home/documents/process/development/description_documents.html), code (see http://www.eclipse.org/tptp/home/documents/resources/TPTPDevGuide.htm), and test cases (see http://www.eclipse.org/tptp/home/documents/process/TPTP_Testing_Strategy.html). As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since the originator of this enhancement/defect has an inactive Bugzilla account and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open. |