Skip to content

#199 test fix for uploaded files#201

Open
jasonriddell wants to merge 1 commit into
mainfrom
fix/keycode-upload
Open

#199 test fix for uploaded files#201
jasonriddell wants to merge 1 commit into
mainfrom
fix/keycode-upload

Conversation

@jasonriddell
Copy link
Copy Markdown
Member

The only additions are:

  • EncryptKeycode() in encrypt.go (PGP-armored keycode encryption)
  • PublicKey, PublicKeysResponse, Recipient types in misc.go
  • GetPublicKeys(), UploadKeycode(), UploadKeycodes() in package.go (all using packageCode in URLs)
  • The UploadKeycodes() call in the upload flow before FinalizePackage()

The only additions are:

- EncryptKeycode() in encrypt.go (PGP-armored keycode encryption)
- PublicKey, PublicKeysResponse, Recipient types in misc.go
- GetPublicKeys(), UploadKeycode(), UploadKeycodes() in package.go (all using packageCode in URLs)
- The UploadKeycodes() call in the upload flow before FinalizePackage()
fmt.Printf("File uploads complete\n")

fmt.Println("Uploading keycodes...")
if err := p.UploadKeycodes(); err != nil {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a blocker: wondering whether a keycode upload failure should be fatal here. If SendSafely has no PGP public keys configured for this package (empty PublicKeys slice), UploadKeycodes returns nil and we proceed to finalize. That seems right. But if there are recipients and all keycodes fail, we abort before FinalizePackage. Is that the intended behavior, or would it be better to finalize anyway and let the caller decide? I don't know the SendSafely semantics well enough to say.

if _, err := io.WriteString(w, keyCode); err != nil {
return "", fmt.Errorf("failed to write keycode: %w", err)
}
w.Close()
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

w.Close() and armorWriter.Close() (line 92) return errors that are dropped here. In practice these write to a bytes.Buffer which cannot fail, so this is probably safe. The existing encrypt() above does the same thing. Would it make sense to check both and return an error, at least for defensive consistency? Or is the pattern intentional given the buffer-backed writer?

Copy link
Copy Markdown
Contributor

@eugeneckim eugeneckim left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

go_debug.txt (763 lines) and yb-support-tool (binary, 13 MB) are both included in the commit. Neither should be version-controlled. The debug file ends with a DENIED response from the keycode upload endpoint — is there a successful end-to-end run somewhere that confirms the full flow works? Happy to be corrected if the package expiry explains the DENIED.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants