Uploaded image for project: 'TFS Artifactory Plugin'
  1. TFS Artifactory Plugin
  2. TFSAP-25

CLONE - Reject artifact property changes if no repository is specified

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open
    • Priority: 2 - Critical
    • Resolution: Unresolved

      Description

      The ADS task ArtifactoryProperties@1 can be used without specifying a repository in the `pattern` argument. This means that you can apply your changes to all artifacts that match the given wildcard expression everywhere in Artifactory.

       

      As an example, a developer accidentally called the task like this:

      - task: ArtifactoryProperties@1
        inputs:
          command: 'set'
          artifactoryService: 'Artifactory'
          setProps: 'someproperty=1;'
          specSource: 'taskConfiguration'
          fileSpec: |
            {
              "files": [
                {
                  "pattern": "*.zip"
                }
              ]
            }
      

      This resulted in all our .zip files everywhere in artifactory to get this property. Even .zip files that were part of other packages.

      It is the same functionality if you use the `delete` function instead of `set`.
      We haven't tested it for obvious reasons, but it appears that using the pattern:

       

      "pattern": "*.*"
      

      Would apply the changes to all artifacts everywhere in artifactory. This means a developer can accidentally, or maliciously, overwrite or delete critical artifact properties, like buildNumber and buildName, for all artifacts that have been uploaded. Even cached artifacts will be changed.

       

      For companies who have to work under regulatory conditions this is extremely critical. Naturally it can be reverted from a backup, but that means that you have to be aware that the changes have happened to begin with.

       

      I think it is critical that the task is changed so that it should require a repository as a minimum.

      Ideally it should go even further, so that it is only allowed to add properties and not delete/overwrite existing properties without a user with Admin privileges.
      Just because a "user" has deploy permissions should not enable them to overwrite/delete properties, only add them.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned
              Reporter:
              brobrobro fkldjflkjlkdf
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Dates

                Created:
                Updated: