Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.

If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!

Permission for 'Assign License' in tasks



  • What permissions are required for a group/user to be able to 'Assign License' to a package that has an 'Unknown' license in the nuget/node package in a specific feed?

    I am logged in as an Administrator and see the 'Assign License'. However when I give someone the 'NuGet Uploaders' task they don't see the 'Assign License' button. I also added the 'Manage Feed' permission to the 'NuGet Uploaders' task to see if that would work but it did not provide that button to the user.

    Product: ProGet
    Version: 4.8.2



  • The "NuGet Uploaders" is a custom task that someone made; see Security Tasks for more info.

    That said, there is currently no specific attribute for this, because license management is not just "package" level, but it's applied at a global/system level (you select "global" or "feed" on the page); thus, you would need to assign [Admin_ConfigureProGet].

    This was done because, typically, we had figured that license agreements must read and then be approved by governance/legal/compliance teams; this would all be coordinated by an administrator to ProGet, as opposed to an individual developer.

    So, if you can share with us your specific use case / workflow, and then the compliance/security behind it, then we can study it and make a better way to delegate this sort of work.



  • You are correct, the 'NuGet Uploaders' task is a custom one I made, it's been a while since I did that and did not immediately recall it as such.

    That said, our use case is that the one administrating ProGet (myself and a few others) define what licenses are allowed in a separate feed. We have a set of developer architects that are responsible for reviewing which packages get put into the feed. Some of the packages they appropriately want to upload to the feed have an 'unknown' license. The dev arch then looks into the package and sees the url pointing to what reads as a particular license (likely a file in the project github repo). They would assign it correctly.

    We would watch the new url license assignments and verify (trust but verify) ourselves outside of that process to allow them to move forward. Below is a workflow of what we have setup:

    Arch upload -> import-nuget-feed -> assign license -> arch promote -> approved-nuget-feed

    • Arch has upload access to the import-nuget-feed
    • Arch only has promote access to approved-nuget-feed
    • approved-nuget-feed has license restrictions on it
    • Arch would assign license of the package while in the import-nuget-feed
    • Devs use approved-nuget-feed for development

    The archs would not need proget administrative rights, because they are not administrating the running and operations of Proget, just the content within it.

    I hope that makes sense. I appreciate your time in this.



  • Great, thanks for the detailed explanation. It's quite helpful actually.

    It's important to note that "URL associations" are not feed-specific; it's a system-wide setting that says "this URL means this license ID in this instance of ProGet". As you can imagine, making these feed-level associations would be probably even worse (in this feed, this URL means this, but in that feed it means nothing).

    So, now that you give access to manage license url/ids, they can just add/change the url "www.gnu.org/licenses/gpl-3.0-standalone.html " from being associated with GPL3 to MIT. Basically, it can be an "end run" around your feed-specific license rules, because you can just change it at the system level to get around it, so we would need make all license management a separate, system-level permission.

    On the face of it, it seems counter-intuitive because you can manage licenses per feed. This is why we never made it a separate permission, I would guess...

    Anyway it's quite easy to do, just a matter of making a feature that isn't unintuitive and can be easily documented*.

    * we've learned the hard way how difficult this is, and are still working on improving our docs ASAP!



  • This is an issue we now face, our lead developers manage feeds, but need rights to assign licences. Configure Proget is a bit too much, so it would be ideal to have this covered under the manage feed as they can already add approved or rejected states to licences they want.

    I am on 4.8.8

    Thanks,

    Luke



  • How do you feel about adding a new task attribute for "manage licenses"? It's not feed-scopable, but would seem to allow it.

    would this solve some issues?



  • Hello Alana,

    That does take you out of the flow a bit, as I assume that this would give them access to edit the "Manage Licences" page?

    I think is a step in the right direction, but I would still think using the Manage Feed flag and adding that as a role to that which allows Assign Licence is a good option as well.

    Thanks,

    Luke



Inedo Website HomeSupport HomeCode of ConductForums GuideDocumentation