You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If a client receives a notification where isEncrypted is explicitly false, it nonetheless continues to treat it as though isEncrypted were true
Steps to reproduce
Came across this bug when I was running an sshnpd with legacy atKeys at the same time as I was doing enroll requests; the enroll request notifications explicitly have isEncrypted == false (which is correct) but NotificationResponseTransformer nonetheless tries to decrypt the data and of course fails
Describe the bug
If a client receives a notification where isEncrypted is explicitly false, it nonetheless continues to treat it as though isEncrypted were true
Steps to reproduce
Came across this bug when I was running an sshnpd with legacy atKeys at the same time as I was doing enroll requests; the enroll request notifications explicitly have isEncrypted == false (which is correct) but NotificationResponseTransformer nonetheless tries to decrypt the data and of course fails
Expected behavior
explicit isEncrypted == false should be respected
Additional context
See also atsign-foundation/at_server#1944
The text was updated successfully, but these errors were encountered: