- Notifications
You must be signed in to change notification settings - Fork 18
fix: fix CipherSubscriber to only call onNext once per request #456
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 29 commits
caeac1d e05b523 e11731a b2fd263 62028e1 478e870 9ad2d16 f029007 11ad1d7 c23a407 dde8989 e7cd2e2 daf1493 9febcce faf99ee 84fe71d 84be7aa 12be3e3 53d62d6 b30a380 2a6c43d 05ec321 0af0ad6 da80e66 8ca7c00 e8914d4 1564b49 31270f2 adb5a41 1604c4e File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| | @@ -11,22 +11,26 @@ | |||||||||||||
| import javax.crypto.Cipher; | ||||||||||||||
| import java.nio.ByteBuffer; | ||||||||||||||
| import java.security.GeneralSecurityException; | ||||||||||||||
| import java.util.concurrent.atomic.AtomicBoolean; | ||||||||||||||
| import java.util.concurrent.atomic.AtomicLong; | ||||||||||||||
| | ||||||||||||||
| public class CipherSubscriber implements Subscriber<ByteBuffer> { | ||||||||||||||
| private final AtomicLong contentRead = new AtomicLong(0); | ||||||||||||||
| private final Subscriber<? super ByteBuffer> wrappedSubscriber; | ||||||||||||||
| private Cipher cipher; | ||||||||||||||
| private final Cipher cipher; | ||||||||||||||
| private final Long contentLength; | ||||||||||||||
| private boolean isLastPart; | ||||||||||||||
| private final boolean isLastPart; | ||||||||||||||
| private final int tagLength; | ||||||||||||||
| private final AtomicBoolean finalBytesCalled = new AtomicBoolean(false); | ||||||||||||||
| | ||||||||||||||
| private byte[] outputBuffer; | ||||||||||||||
| | ||||||||||||||
| CipherSubscriber(Subscriber<? super ByteBuffer> wrappedSubscriber, Long contentLength, CryptographicMaterials materials, byte[] iv, boolean isLastPart) { | ||||||||||||||
| this.wrappedSubscriber = wrappedSubscriber; | ||||||||||||||
| this.contentLength = contentLength; | ||||||||||||||
| cipher = materials.getCipher(iv); | ||||||||||||||
| this.cipher = materials.getCipher(iv); | ||||||||||||||
| this.isLastPart = isLastPart; | ||||||||||||||
| this.tagLength = materials.algorithmSuite().cipherTagLengthBytes(); | ||||||||||||||
| } | ||||||||||||||
| | ||||||||||||||
| CipherSubscriber(Subscriber<? super ByteBuffer> wrappedSubscriber, Long contentLength, CryptographicMaterials materials, byte[] iv) { | ||||||||||||||
| | @@ -46,20 +50,50 @@ public void onNext(ByteBuffer byteBuffer) { | |||||||||||||
| if (amountToReadFromByteBuffer > 0) { | ||||||||||||||
| byte[] buf = BinaryUtils.copyBytesFrom(byteBuffer, amountToReadFromByteBuffer); | ||||||||||||||
| outputBuffer = cipher.update(buf, 0, amountToReadFromByteBuffer); | ||||||||||||||
| | ||||||||||||||
| if (outputBuffer == null || outputBuffer.length == 0) { | ||||||||||||||
| // The underlying data is too short to fill in the block cipher. | ||||||||||||||
| // Note that while the JCE Javadoc specifies that the outputBuffer is null in this case, | ||||||||||||||
| // in practice SunJCE and ACCP return an empty buffer instead, hence checks for | ||||||||||||||
| // null OR length == 0. | ||||||||||||||
| if (contentRead.get() == contentLength) { | ||||||||||||||
| if (contentRead.get() + tagLength >= contentLength) { | ||||||||||||||
| // All content has been read, so complete to get the final bytes | ||||||||||||||
| this.onComplete(); | ||||||||||||||
| finalBytes(); | ||||||||||||||
| return; | ||||||||||||||
| } | ||||||||||||||
| // Otherwise, wait for more bytes. To avoid blocking, | ||||||||||||||
| // send an empty buffer to the wrapped subscriber. | ||||||||||||||
| wrappedSubscriber.onNext(ByteBuffer.allocate(0)); | ||||||||||||||
| } else { | ||||||||||||||
| wrappedSubscriber.onNext(ByteBuffer.wrap(outputBuffer)); | ||||||||||||||
| /* | ||||||||||||||
| Check if stream has read all expected content. | ||||||||||||||
| Once all content has been read, call onComplete. | ||||||||||||||
| ||||||||||||||
| Once all content has been read, call onComplete. | |
| Once all content has been read, call finalBytes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| // All content has been read; complete the stream. | |
| // (Signalling onComplete from here is Reactive Streams-spec compliant; | |
| // this class is allowed to call onComplete, even if upstream has not yet signaled onComplete.) | |
| finalBytes(); | |
| // All content has been read; compute finalBytes | |
| finalBytes(); |
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this calculation include the tag length?
It feels weird that this formula is different than the other ones
| if (contentRead.get() < contentLength) { | |
| if (contentRead.get() + tagLength < contentLength) { |
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @kessplas
Is the lack of calling
onComplete()afterfinalBytes()deliberate? There seems to be a change in behaviour here. edit: this doesn't seem to be a problem, I've downloaded the src directly and confirmed that re-adding it makes no difference.FWIW, I'm looking into a failure in our software that has been introduced with
v3.3.3of this SDK, and it seems to relate to our Kotlin Flows not completing normally and instead "cancelling", which leads to our completion handlers not firing properly. My current working theory is that the missingonComplete()here is leading to the Kotlin cancellation, when the upload Flow has completed sending all ByteBuffers and shutdown, but without the subscriber having properly calledonComplete(). edit: this is not the case, and I'm still confusedAny idea what might be going on here? Are you sure that this change was safe?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @davidconnard ,
This change made the
CipherSubscribermore spec compliant asonNext()MUST be only called once for oneonNext()signal. The spec is not abundantly clear about the validity of signalingonComplete()from withinonNext()but intuitively, theonComplete()signal should come from the publisher once all data is published and flow through the subscribers accordingly; callingonComplete()from withinonNext()subverts this expectation.We don't specifically support Kotlin, as we don't test against the Kotlin SDK. That said, I would recommend opening an issue for this, as it's easier for us to track than comments on a specific PR. Thanks!
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @kessplas for the response ... Yesterday, I didn't yet have enough information to raise an issue. I've done some further digging, and I've uncovered where the change in behaviour is coming from.
In the AWS SDK, in the
netty-nio-client, in theNettyRequestExecutor.StreamedRequestclass, in theonNext()method, there is a check forshouldContinuePublishing(), which checks if the content-length has been reached. When it has been reached, the subscription is cancelled, and anonComplete()call is made. See https://github.com/aws/aws-sdk-java-v2/blob/7009f86260a3d77f811c1dde31679d1297c1cc01/http-clients/netty-nio-client/src/main/java/software/amazon/awssdk/http/nio/netty/internal/NettyRequestExecutor.java#L453-L456It is this subscription cancellation that is causing my test failure. Encountering this subscription cancellation behaviour is new (as far as my test is concerned). Before this change, the final content-length would only be reached (ie. final bytes sent) as a side-effect of the
onComplete()call, and the subscription cancellation would have no actual effect (ie. would not fire ononError()for the publisher). With your changes, the final content-length is reached in the terminalonNext()call, and the cancellation (triggered by the AWS SDK) fires at that point (prior to publisher completion), leading to anonError()call, which triggers different completion behaviour in the Kotlin Flow.So, this isn't a problem with your change, and apologies for that! Previously, the
CipherPublisherwas hiding this early cancellation behaviour of the AWS SDK from our flow, and your change has simply exposed our code to this behaviour in the underlying AWS SDK. If I remove the AWS S3 Encryption SDK from the picture, and apply our Flow transformer (with its completion handler) over the raw AWS S3 SDK, then I see the exact same behaviour - our completion handler is invoked (with an error) after cancellation of the subscription/flow).The solution for us appears to be to restructure our flow / publisher logic. For reference, when our requests to S3 are using the AWS S3 encryption SDK (which is not all the time), we are wrapping the byte stream publisher in another publisher, which performs additional verification of the plaintext (original bytes) checksum prior to sending to S3. To date, we had used
onNext()calls to accumulate the plaintext checksum, and we performed the verification in theonComplete()call. While that worked, on reflection, it does not seem to be the correct way to verify this, and it only worked because of theCipherSubscriberpreviously delayed sending the final bytes to S3 (and therefore, delayed the cancellation) until theonComplete()call (rather than having it fire from the terminalonNext()call).The right solution seems to be to change our code to perform the verification in the terminal
onNext()call (by tracking the byte count, like the AWS SDK is doing). This will verify the plaintext checksum before sending the final bytes to the wrapped subscriber (ie.CipherSubscriber) in the chainedonNext()call.