Bugzilla – Full Text Bug Listing
| Summary: | The JVMTI agent does not work with secure AC | ||||||
|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | amehrega | ||||
| Component: | TPTP | Assignee: | Igor Alelekov <igor.alelekov> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | critical | ||||||
| Priority: | P1 | CC: | jkubasta, kiryl.kazakevich, popescu, samwai, sluiman | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | closed460 | ||||||
| Attachments: |
|
||||||
|
Description
amehrega
This was not committed to. Guru, I believe this needs to be supported in i4. Joanna, The NewAC does not support Security in its native mode. It supports security in the "Backward Compatiblity Mode" If the AC can provide the security then the Execution framework resolution will resolve it. It has nothing to do with jvmti (In reply to comment #3) > Joanna, > The NewAC does not support Security in its native mode. It supports security > in the "Backward Compatiblity Mode" > If the AC can provide the security then the Execution framework resolution will > resolve it. It has nothing to do with jvmti I guess we need to take this off line but I don't understand how such a large missunderstanding of requirements could exist. This is likely not going to be acceptable to the bulk of the consuming products since secure access has been a basic feature for many releases. For tomorrow's meeting, please let me know how much effort would be required in order to add support to the NewAC for Security in its native mode Here are the two enhancements used to implement new AC security: https://bugs.eclipse.org/bugs/show_bug.cgi?id=74579 https://bugs.eclipse.org/bugs/show_bug.cgi?id=147117 Unfortunately these are buried in the big pile of "future" enhancements. AC needs to support secure AC. Guru, please add size estimates Valentina, again the secure AC is part of the Platform.Communications component. The new AC does not support security natively. The JVMTI Agent like any other agent resides on the top of the communications infrastructure. This has to be provided by Joanna and team. Hi Igor. Please update the sizing on this bug. Thanks. Created attachment 73190 [details]
patch
Hi Samson, could you please review the patch?
It fixes the defect Ali descibed in his use case - JVMTI profiling doesn't work with security enabled in Agent Controller (in its "backward compatibility layer").
To track implementation of AC security in its regular mode I opened enhancement request #195644
Thanks Igor. The patch seems trivial. What is the behaviour seen by the client now? What is the use of "acPortRequestReply()" for? (In reply to comment #12) > Thanks Igor. The patch seems trivial. What is the behaviour seen by the client > now? What is the use of "acPortRequestReply()" for? You know, AC has two network listeners - one for new and one for old clients. If Backward Compatibility Layer (dedicated for old clients service) detects a call from new client it sends redirect request with appropriate port value. With security enabled this redirect is not being sent. The patch fixes it. (In reply to comment #13) > You know, AC has two network listeners - one for new and one for old clients. > If Backward Compatibility Layer (dedicated for old clients service) detects a > call from new client it sends redirect request with appropriate port value. > With security enabled this redirect is not being sent. The patch fixes it. This sounds like the right simple fix. It will need testing via several scenarios to ensure everything works. Hi Igor. Please request for approval once you have completed your testing. Thanks. Igor Looking at the patch - you are messaging to have the secureAC port responded back to the client. Does the Client then connect without security to the "New Secure Port"? There is no code in the execution framework to do this - the last time I checked. (In reply to comment #16) > Igor > Looking at the patch - you are messaging to have the secureAC port responded > back to the client. Does the Client then connect without security to the "New > Secure Port"? There is no code in the execution framework to do this - the last > time I checked. No, the patch sends redirect to the configured insecure AC port (10006). Clients connect to this port as usual and work without security as before. Hi Samson, could you please check the patch in? I've tested it on Windows and Linux. Hi Igor. The patch has been checked in. Please mark this bug as fixed. Thanks. Thanks, resolving as fixed. 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 this enhancement/defect has been resolved and unverified for more than 1 year 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. |