[NCM-Cli 4] As a user I want to be able view/ and modify my account's white-list so that I can manage my organizations/ personal compliance needs.

mnedelko commented 5 years ago

AS A User

I WANT TO able view/ and modify my account's white-list

SO THAT I can manage my organizations/ personal compliance needs.

ACCEPTANCE CRITERIA:

[x] I should be able to request, view and select the organization I wish to manage my whitelist for
[x] I should be able to add/ delete packaged from my whitelist
[x] I should be able to request and view the whitelist I should be able to see who last changed the whitelist [not MVP - shall be delayed]

QUESTIONS:

[x] Does the org policy set allow user collaboration at a SaaS level? -- Yes, but only at an organizational level.

Fishrock123 commented 5 years ago

@mnedelko Needs extra definition about what a 'white list' will mean going forwards

mster commented 5 years ago

@mnedelko Needs extra definition about what a 'white list' will mean going forwards

I agree. There seems to be a "whitelist" (allow) feature, as well as a "block" feature.

mnedelko commented 5 years ago

Good point. At this stage, we only ever explored "whitelist (allow)". That said, if the backend API now supports "whitelist (block)" we may wish to explore that for the cli-client in form of a 'black-' or 'block list' sooner than later. There are designs for the future policy builder which includes a 'block list' (see screenshot below). That said, we may wish to confirm with @pmuellr whether the block-feature is available now.

PLEASE NOTE: The following design has nothing to do with this story as there is no intended UI component to this cli tool. That said, a future integration of the NCM feature-set into N|Solid SaaS may incorporate a design similar (not identical) to the below.

pmuellr commented 5 years ago

I should be able to see a list of actions that were committed to the whitelist and who committed them

We don't currently maintain a history of edits to the whitelist, this will be new function for ncm2-api ...

Also, we do allow service tokens to be used to edit the whitelist, so keep in mind "who" might be a service token.

juliangruber commented 5 years ago

Also, we do allow service tokens to be used to edit the whitelist, so keep in mind "who" might be a service token.

Do we? I thought service tokens would only be able to read the whitelist at this time

juliangruber commented 5 years ago

Also @pmuellr can you confirm that we now also support a block list in the api?

pmuellr commented 5 years ago

That said, if the backend API now supports "whitelist (block)"

The backend does not support a "whitelist(block)" API. It would probably be called a "blacklist" as "whitelist (block)" seems like a confusing term.

juliangruber commented 5 years ago

Ok, assuming we will want a blocklist, do you think we can implement this in this sprint?

pmuellr commented 5 years ago

We? I thought service tokens would only be able to read the whitelist at this time

Service tokens can have up to 3 permissions currently:

ncm:cert:read - can read package certification data
ncm:policy:read - can read policy data
ncm:policy:write - can write policy data

We just don't have a way for users to actually change the whitelists with a service token. I have some tools that do it though, works fine.

juliangruber commented 5 years ago

Gotcha. Then in real world though the modifier of a block/safe list is always going to be a person though, because we don't expose any tooling modifying those lists through service tokens to the user, right?

pmuellr commented 5 years ago

Ok, assuming we will want a blocklist, do you think we can implement this in this sprint?

Maybe. Need more specs, this is the first time we've gotten close maybe implementing one. Is it exactly like the whitelist, in terms of API to view/edit the list, and the entries in the list are exactly the same? And each policy in an org has both a whitelist and a blacklist.

This also raises the question of whether this is the right organization. Eg, maybe these "lists" devolve to "named package lists" associated with the org, and we still have policies, but the whitelist and blacklist each become a list of multiple "named package lists".

I'm also curious what the function of these lists will be. The backend API does nothing with them. It's easy to understand what they do in a ci mode where modules have to pass some severity level in scoring to "pass", and that "pass" can be directly affected by the whitelist/blacklist. But what about UI.

pmuellr commented 5 years ago

Gotcha. Then in real world though the modifier of a block/safe list is always going to be a person though, because we don't expose any tooling modifying those lists through service tokens to the user, right?

It's exposed via the public GraphQL API, but no tooling. Users can create tokens with ncm:policy:write from the Service Tokens page with their account.

juliangruber commented 5 years ago

Maybe. Need more specs, this is the first time we've gotten close maybe implementing one. Is it exactly like the whitelist, in terms of API to view/edit the list, and the entries in the list are exactly the same? And each policy in an org has both a whitelist and a blacklist.

That sounds right, for the first iteration this should mirror current whitelist functionality. So, add and remove specific name@version, remove and list them. With the independent addition of lastModifiedUser.

This also raises the question of whether this is the right organization. Eg, maybe these "lists" devolve to "named package lists" associated with the org, and we still have policies, but the whitelist and blacklist each become a list of multiple "named package lists".

We were talking about sharable policies, and those can contain safe and block lists already, so I guess better to just have one sharable entity that includes all the possibilities? Maybe in the future we want to add UI like "add the modules of this policy's safe list to your safe list"?. And if we choose to eventually make module lists a separate entity, I guess they will be templates that you clone any way.

I'm also curious what the function of these lists will be. The backend API does nothing with them. It's easy to understand what they do in a ci mode where modules have to pass some severity level in scoring to "pass", and that "pass" can be directly affected by the whitelist/blacklist. But what about UI.

The designs suggest:

list modules in block list with name, version
list modules in safe list with name, version
delete module from list

I guess no point in worrying about order or other extra visible information. And the number of modules depending on that module is dependant on project information, which we don't have yet anyways.

juliangruber commented 5 years ago

It's exposed via the public GraphQL API, but no tooling. Users can create tokens with ncm:policy:write from the Service Tokens page with their account.

That's good to know, thank you! I guess then the UI should assume user or org for lastModifiedUser.

pmuellr commented 5 years ago

... UI w/ whitelisting and blacklist

I wasn't thinking about white/black list viewing / editing, I was thinking about when I'm looking at list of packages - say at a terminal from ncm-cli or in a ns web page, what do we do with entries on the white/black lists. Just curious.

pmuellr commented 5 years ago

Can a package/version be on the whitelist and blacklist at the same time? Guessing not. When trying to add a package/version to a list and it's on the other list, what happens?

juliangruber commented 5 years ago

Can a package/version be on the whitelist and blacklist at the same time? Guessing not. When trying to add a package/version to a list and it's on the other list, what happens?

Great observation, it would only make sense for them to be mutually exclusive.

I wasn't thinking about white/black list viewing / editing, I was thinking about when I'm looking at list of packages - say at a terminal from ncm-cli or in a ns web page, what do we do with entries on the white/black lists. Just curious.

Right! ncm ci will change its exit code based on whether bad / good modules are on the safe / block list, and ncm proxy will prevent installation. ncm cli will use the safe / block list to tell you which modules you need to worry about.

pmuellr commented 5 years ago

With the independent addition of lastModifiedUser

Is that a property of the list, or of entries in the list, or both?

It was sounding like what we wanted was a "history" of edits as well. "On Tuesday, JimmyBob added react@latest and express@4.16.4 to the block list". Kinda stuff.

pmuellr commented 5 years ago

I'm also curious what the function of these lists will be. The backend API does nothing with them. It's easy to understand what they do in a ci mode where modules have to pass some severity level in scoring to "pass", and that "pass" can be directly affected by the whitelist/blacklist. But what about UI.

I wasn't thinking about white/black list viewing / editing, I was thinking about when I'm looking at list of packages - say at a terminal from ncm-cli or in a ns web page, what do we do with entries on the white/black lists. Just curious.

Right! ncm ci will change its exit code based on whether bad / good modules are on the safe / block list, and ncm proxy will prevent installation. ncm cli will use the safe / block list to tell you which modules you need to worry about.

There is no ncm proxy. Please god tell me there is no ncm proxy.

But I'm not hearing a lot of UI usage for these lists. Is all this ceremony around lists too much - editing UIs, GraphQL APIs? Maybe the customer's project should just have a file with this info in it, that our tooling can read and blamo - a lot less work for us to do. Probably easier for the customer anyway!

juliangruber commented 5 years ago

Is that a property of the list, or of entries in the list, or both?

It was sounding like what we wanted was a "history" of edits as well. "On Tuesday, JimmyBob added react@latest and express@4.16.4 to the block list". Kinda stuff.

It's a property of the entries iiuc, because it answers "who added this module to the whitelist?" then you can ask that person for specific reasoning. Even better would be for you to be able to add a comment too, but I guess that can come later.

There is no ncm proxy. Please god tell me there is no ncm proxy.

But I'm not hearing a lot of UI usage for these lists. Is all this ceremony around lists too much - editing UIs, GraphQL APIs? Maybe the customer's project should just have a file with this info in it, that our tooling can read and blamo - a lot less work for us to do. Probably easier for the customer anyway!

There is! Again! :D However, only for the Artifactory integration, so we're cool.

But I'm not hearing a lot of UI usage for these lists. Is all this ceremony around lists too much - editing UIs, GraphQL APIs? Maybe the customer's project should just have a file with this info in it, that our tooling can read and blamo - a lot less work for us to do. Probably easier for the customer anyway!

Hmm interesting idea! Every project could have it's safe and block lists as text files committed to source control. This could indeed be an easier first step, but

we already support whitelists in ncm desktop and can't break that
knowing of the lists in our servers / on the api layer let's us work more with the data

pmuellr commented 5 years ago

It's a property of the entries iiuc, because it answers "who added this module to the whitelist?" then you can ask that person for specific reasoning. Even better would be for you to be able to add a comment too, but I guess that can come later.

If it's a property of the entries, there's no way to ask the question "who deleted this module from the whitelist?".

juliangruber commented 5 years ago

That's right! @mnedelko @pdevay do we want to display a list of deleted modules, or have an activity feed for the whole list? Otherwise as @pmuellr noticed, you couldn't tell who deleted a module from the list.

mnedelko commented 5 years ago

Hi @juliangruber. Thank you for the question. I hope I am not misinterpreting this, but I think we may have touched on this in the conversation we had yesterday. i.e. for the MVP we hope to be able to see who modified the whitelist last.

We also noted that the 'activity feed' was a great idea, and this actually aligns with the activity feed visualization we discussed earlier this year. But this would be something we decided to explore after the NCM feature set found its way into SaaS.

juliangruber commented 5 years ago

i.e. for the MVP we hope to be able to see who modified the whitelist last.

We need to be more specific here, what does it mean "who modified the whitelist last"? Does that mean that for the whitelist you can see the name of the person who updated it last? Or that for each module in the whitelist, you can see know who added it? And do we care about dates? 🙏

mnedelko commented 5 years ago

Who modified the white-list may not be part of the MVP, but may be useful for future iterations.

Fishrock123 commented 5 years ago

I think this part of whitelisting is complete

mnedelko commented 5 years ago

Issue moved to nodesource/product-stories #41 via ZenHub

nodesource / ncm-cli

[NCM-Cli 4] As a user I want to be able view/ and modify my account's white-list so that I can manage my organizations/ personal compliance needs. #10