[NETCONF-441] Unable to decrypt encrypted passwords Created: 11/Jul/17  Updated: 15/Mar/19  Resolved: 13/Jul/17

Status: Resolved
Project: netconf
Component/s: netconf
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Tomas Cere Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

External issue ID: 8839

 Description   

Noticed this in:
https://jenkins.opendaylight.org/releng/job/netconf-csit-1node-userfeatures-only-carbon/513/
https://jenkins.opendaylight.org/releng/job/netconf-csit-3node-clustering-only-carbon/588/

This seems like no netconf session would be able to connect succesfully apart from the initial one(since this one isnt encrypted yet, which is a big flaw in the implementation), or testtool which doesnt care about the credentials.

Carbon revert:
https://git.opendaylight.org/gerrit/#/c/60206/

 Comments   
Comment by Tomas Cere [ 11/Jul/17 ]

To be more clear in the failure in the first job seems like when the decryption failed, testtool was connected with a different session(the gibberish one) and had the modified data missing, since it only keeps the datastore per user afaik.
Since there is a discrepancy in the data that the device then reports it makes it seem that the credentials are different after the attempt at decryption.

Comment by A H [ 11/Jul/17 ]

A patch was submitted to revert the changes and fix this bug in Carbon SR1: https://git.opendaylight.org/gerrit/#/c/60206/

To better assess the impact of this bug and fix, could someone from your team please help us identify the following:
Regression: Is this bug a regression of functionality/performance/feature compared to Carbon?
Severity: Could you elaborate on the severity of this bug? Is this a BLOCKER such that we cannot release Carbon SR1 without it?
Workaround: Is there a workaround such that we can write a release note instead?
Testing: Could you also elaborate on the testing of this patch? How extensively has this patch been tested? Is it covered by any unit tests or system tests?
Impact: Does this fix impact any dependent projects?

Comment by Tomas Cere [ 11/Jul/17 ]

(In reply to A H from comment #2)
> A patch was submitted to revert the changes and fix this bug in Carbon SR1:
> https://git.opendaylight.org/gerrit/#/c/60206/
>
> To better assess the impact of this bug and fix, could someone from your
> team please help us identify the following:
> Regression: Is this bug a regression of functionality/performance/feature
> compared to Carbon?

It's a regression, seems like no netconf session that actually cares about the credentials would be able to be established.

> Severity: Could you elaborate on the severity of this bug? Is this a
> BLOCKER such that we cannot release Carbon SR1 without it?

It's a blocker.

> Workaround: Is there a workaround such that we can write a release note
> instead?

There are no workarounds.

> Testing: Could you also elaborate on the testing of this patch? How
> extensively has this patch been tested? Is it covered by any unit tests or
> system tests?

Well the codebase had a long term csit on it before this patch was introduced so with the revert we get get back to the point before this regression.

> Impact: Does this fix impact any dependent projects?

There would be impact if this wasnt reverted.

Comment by Thanh Ha (zxiiro) [ 11/Jul/17 ]

Patch is merged will kick off a new autorelease shortly.

Comment by A H [ 13/Jul/17 ]

Marking this blocker bug as fixed and resolved since the following patch has been merged:

https://git.opendaylight.org/gerrit/#/c/60206/

Generated at Wed Feb 07 20:15:02 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.