Skip to content

Conversation

@travispaul
Copy link
Member

@travispaul travispaul commented Oct 24, 2025

  • Add support for a description field on access keys.
  • Add support for updating an access key's description and status.
  • Added an updated field that is updated when either description or status are modified.
  • Add prefix and checksum to accesskeysecret inspired by suggestions from Github's Secret scanning partner program (even though we are unlikely to join this program.)
  • Replace usage of nodeunit's ifError function with assert-plus' ifError (See: ifError doesn't throw caolan/nodeunit#151).
  • Use non-blocking version of crypto.randomBytes().
  • Move existing (and new) accesskey unit tests into a separate file.

Confirmed make check and make tests pass. The unit tests will pass with sdc-ufds version (7.5.0) with changes from TritonDataCenter/sdc-ufds/pull/29

The unit tests will also mostly pass with the current version of sdc-ufds (v7.4.1) though some validation tests in this repo will fail as this older version is less strict about the status and description properties. Meaning this client is compatible with both versions (not that it necessarily needs to be.)

Related PRs:

- Add support for description field on access keys
- Add support for udpating an access key's description and status
- Add prefix and checksum to accesskeysecret
- Replace usege of nodeunit's ifError with assert-plus' ifError
  (See: caolan/nodeunit#151)
- Eexport DEFAULT_PREFIX and DEFAULT_BYTE_LENGTH.
- Patch up some fields that may be missing on older
  records as a convience for clients.
Copy link
Contributor

@danmcd danmcd left a comment

Choose a reason for hiding this comment

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

Catching up on the incremental change here.

Copy link
Contributor

@danmcd danmcd left a comment

Choose a reason for hiding this comment

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

Got distracted by Intel ucode, have some clarifying questions, one of which is critical, and one nit.

"rimraf": "~2.4.0"
}
},
"nan": {
Copy link
Contributor

Choose a reason for hiding this comment

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

This will prevent OS-8701/MANTA-5487 classes of problems right?

Copy link
Member Author

Choose a reason for hiding this comment

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

Unfortunately, not in this case because this module wouldn't commonly be used at the highest level of the dependency tree. It does help the next person working on this module and running tests but its not nearly as helpful as other places.

To avoid OS-8701/MANTA-5487 issues we really want package-lock.json files in the top level modules, like sdc-ufds, and sdc-cloudapi. We also want to use npm ci instead of npm install as there's cases where npm install will still re-resolve version ranges. Even without using npm ci having a package-lock.json in those repos reduces the frequency of a OS-8701/MANTA-5487 happening again.

Copy link
Contributor

Choose a reason for hiding this comment

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

OH... I'm getting confused. HERE it shouldn't be an issue because nobody's using this app with v0.10 anymore I'm guessing?

If this IS getting used with v0.10, we'll need to put it up in package.json I'm guessing, or higher up here (I'll indicate where).

Copy link
Contributor

Choose a reason for hiding this comment

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

When sdc-ufds and sdc-cloudapi come up I'll keep an eye on that.

Copy link
Member Author

Choose a reason for hiding this comment

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

Sorry, I think I muddied things up a bit too and didn't accurately address your question.

it shouldn't be an issue because nobody's using this app with v0.10 anymore

Correct, if something was using v0.10 with this module the package-lock.json here wouldn't help (or hurt) them anyway, we'd still need to solve that in the same way we did in OS-8701/MANTA-5487.

cneira
cneira previously approved these changes Nov 17, 2025
Copy link
Contributor

@danmcd danmcd left a comment

Choose a reason for hiding this comment

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

Pardon my nan panic. I've resolved all other conversations except for that one and a new one. All I need on those two is that I'm now understanding things and not further muddying the waters.

I'll need to go over index.js and accesskey.test.js once more.

"rimraf": "~2.4.0"
}
},
"nan": {
Copy link
Contributor

Choose a reason for hiding this comment

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

OH... I'm getting confused. HERE it shouldn't be an issue because nobody's using this app with v0.10 anymore I'm guessing?

If this IS getting used with v0.10, we'll need to put it up in package.json I'm guessing, or higher up here (I'll indicate where).

"rimraf": "~2.4.0"
}
},
"nan": {
Copy link
Contributor

Choose a reason for hiding this comment

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

When sdc-ufds and sdc-cloudapi come up I'll keep an eye on that.

Copy link
Contributor

@danmcd danmcd left a comment

Choose a reason for hiding this comment

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

Code seems okay, but looking through the tests, I have some silly questions. I may be missing the plot too.

  • Do access keys have lifetimes?
  • This may be more a node-triton or sdc-ufds issue, but does the testing here need to cover users trying to grab things that aren't theirs?

@travispaul
Copy link
Member Author

travispaul commented Nov 17, 2025

@danmcd,

* Do access keys have lifetimes?

These access keys do not have a lifetime and do not expire on their own. I considered giving them an expiration but opted against it to align with AWS. We'll need to support temporary tokens for the S3 Manta functionality separately too, which would cover the use case for keys that can expire.

There's an argument to be made that "We're not AWS" and/or those reasons aren't good enough and we want the keys to automatically expire too.

* This may be more a node-triton or sdc-ufds issue, but does the testing here need to cover users trying to grab things that aren't theirs?

This module assumes that the user IDs supplied are from a trusted source such as cloudapi or sdc-ufds. I did add some some tests here which creates a key for a user and two subusers and confirms that only their specific keys are returned when queried. I can add another user with two subusers and do a cross check against both accounts too to cover all the bases.

danmcd
danmcd previously approved these changes Nov 18, 2025
Copy link
Contributor

@danmcd danmcd left a comment

Choose a reason for hiding this comment

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

Thank you for the extra test with two (possibly mutually-hostile) users. I can't see anything else immediately wrong here.

Copy link

@cneira cneira left a comment

Choose a reason for hiding this comment

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

Let me know if it's too much work to avoid the usage of Buffer.alloc that we need to start exploring bumping up the mahi version of node.

Also fix some inconsistent 2 vs 4 space indentiation usage.
@travispaul
Copy link
Member Author

travispaul commented Nov 24, 2025

@danmcd commit c1da5c0 dismissed your approval. When/if you have some more cycles could you re-review?

Copy link
Contributor

@danmcd danmcd left a comment

Choose a reason for hiding this comment

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

Re-up based on the new play-nice-with-v.0.10.x changes.

@travispaul travispaul merged commit 4dadfe2 into master Nov 26, 2025
1 check passed
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.

4 participants