Uploaded image for project: 'Jenkins Website'
  1. Jenkins Website
  2. WEBSITE-277

Add support for plugin warnings to plugin site

    XMLWordPrintable

    Details

    • Type: New Feature
    • Status: Done (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: plugin-site
    • Labels:
      None
    • Similar Issues:

      Description

      We're adding "warnings" to the update sites that inform users (mostly) about security issues in core and plugins they're using.

      This should also show up on the plugins site.

      • Warnings can be issued for plugins that aren't currently being published
      • Warnings can be issued for past or current releases (the latter needing to be more visible, i.e. no fixed version)

      See https://github.com/jenkinsci/backend-update-center2/pull/96 for the current draft format. The resource file contents are a new top-level element in the update-site.json object with the key 'warnings'.

        Attachments

          Issue Links

            Activity

            danielbeck Daniel Beck created issue -
            danielbeck Daniel Beck made changes -
            Field Original Value New Value
            Link This issue is related to JENKINS-40494 [ JENKINS-40494 ]
            danielbeck Daniel Beck made changes -
            Link This issue is related to INFRA-1022 [ INFRA-1022 ]
            danielbeck Daniel Beck made changes -
            Link This issue is related to INFRA-1028 [ INFRA-1028 ]
            Hide
            danielbeck Daniel Beck added a comment -

            As I'm adding warnings to wiki pages in INFRA-1028 and these are visible on the plugins site (similar to 'adopt-a-plugin' messages) this may not actually be required (modulo some appropriate CSS) unless we want to show better warnings on the plugins site where we are more flexible in changing the output.

            Show
            danielbeck Daniel Beck added a comment - As I'm adding warnings to wiki pages in INFRA-1028 and these are visible on the plugins site (similar to 'adopt-a-plugin' messages) this may not actually be required (modulo some appropriate CSS) unless we want to show better warnings on the plugins site where we are more flexible in changing the output.
            mmccaskill Michael McCaskill made changes -
            Sprint Post-launch [ 151 ]
            mmccaskill Michael McCaskill made changes -
            Rank Ranked higher
            mmccaskill Michael McCaskill made changes -
            Status To Do [ 10003 ] In Progress [ 3 ]
            Hide
            mmccaskill Michael McCaskill added a comment -

            Daniel Beck - Working on this locally i've noticed that, google-login for example, has mention of the security warnings in the wiki content, specifically in the change log information. So I'm asking if we're ok with presenting duplicate information for a plugin?

            Show
            mmccaskill Michael McCaskill added a comment - Daniel Beck - Working on this locally i've noticed that, google-login for example, has mention of the security warnings in the wiki content, specifically in the change log information. So I'm asking if we're ok with presenting duplicate information for a plugin?
            Hide
            danielbeck Daniel Beck added a comment -

            Yes. It's useful for changelogs (which versions are affected?) independently of known whether the current version is affected. It's more difficult for older releases, not sure whether that can be presented reasonably straightforward.

            Show
            danielbeck Daniel Beck added a comment - Yes. It's useful for changelogs (which versions are affected?) independently of known whether the current version is affected. It's more difficult for older releases, not sure whether that can be presented reasonably straightforward.
            mmccaskill Michael McCaskill made changes -
            Assignee Michael McCaskill [ mmccaskill ] gus reiber [ gusreiber ]
            Hide
            mmccaskill Michael McCaskill added a comment -

            Assigning to Gus to make the visual stuff happen.

            Show
            mmccaskill Michael McCaskill added a comment - Assigning to Gus to make the visual stuff happen.
            rtyler R. Tyler Croy made changes -
            Assignee gus reiber [ gusreiber ] Michael McCaskill [ mmccaskill ]
            Hide
            mmccaskill Michael McCaskill added a comment -

            R. Tyler Croy - Just curious as to why you re-assigned this ticket? I specifically need it assigned to Gus to perform his portion of this.

            Show
            mmccaskill Michael McCaskill added a comment - R. Tyler Croy - Just curious as to why you re-assigned this ticket? I specifically need it assigned to Gus to perform his portion of this.
            Hide
            rtyler R. Tyler Croy added a comment -

            Michael McCaskill, I did so in error. I was under the impression that these tickets had been stale and was re-assigning them to you as the maintainer of the plugin-site project.

            Show
            rtyler R. Tyler Croy added a comment - Michael McCaskill , I did so in error. I was under the impression that these tickets had been stale and was re-assigning them to you as the maintainer of the plugin-site project.
            Hide
            mmccaskill Michael McCaskill added a comment -

            R. Tyler Croy - Thanks for the clarification. Just wanted to make sure I didn't do anything wrong. In the future I'll try to be more transparent in the status of these tickets.

            Show
            mmccaskill Michael McCaskill added a comment - R. Tyler Croy - Thanks for the clarification. Just wanted to make sure I didn't do anything wrong. In the future I'll try to be more transparent in the status of these tickets.
            mmccaskill Michael McCaskill made changes -
            Resolution Fixed [ 1 ]
            Status In Progress [ 3 ] Done [ 10004 ]
            danielbeck Daniel Beck made changes -
            Resolution Fixed [ 1 ]
            Status Done [ 10004 ] To Do [ 10003 ]
            Hide
            danielbeck Daniel Beck added a comment -

            Michael McCaskill Could you rephrase the message for the version range?

            • If both 'first' and 'last' are given: "from Version X to Version Y" (in whatever way indicates both are inclusive)
            • if only 'last' is given: "version Y and earlier"
            • if only 'first' is given: "version X and later"
            • If neither is given, just skip the info.

            The last two cases should only be relevant if it's an active warning.

            Example: https://plugins.jenkins.io/pipeline-maven affects all versions up to 0.5, so only that is given. But 0.4 is also affected.

            Also note that 'id' (SECURITY-441 here) is not for display, it just serves as unique identifier (which happens to work nicely for existing plugin warnings, but still).

            Also, there's a list of version ranges, and this only shows the first one. I'd expect something like:

            Show
            danielbeck Daniel Beck added a comment - Michael McCaskill Could you rephrase the message for the version range? If both 'first' and 'last' are given: "from Version X to Version Y" (in whatever way indicates both are inclusive) if only 'last' is given: "version Y and earlier" if only 'first' is given: "version X and later" If neither is given, just skip the info. The last two cases should only be relevant if it's an active warning. Example: https://plugins.jenkins.io/pipeline-maven affects all versions up to 0.5, so only that is given. But 0.4 is also affected. Also note that 'id' (SECURITY-441 here) is not for display, it just serves as unique identifier (which happens to work nicely for existing plugin warnings, but still). Also, there's a list of version ranges, and this only shows the first one. I'd expect something like: Arbitrary files from Jenkins master available in Pipeline by using the withMaven step Affects version 0.5 and earlier Affects version 2.0-beta-5 and earlier
            Hide
            danielbeck Daniel Beck added a comment -

            Ideally it would distinguish between 1 range and more ranges, and only use the nested list format if >1

            Show
            danielbeck Daniel Beck added a comment - Ideally it would distinguish between 1 range and more ranges, and only use the nested list format if >1
            mmccaskill Michael McCaskill made changes -
            Status To Do [ 10003 ] In Progress [ 3 ]
            Hide
            mmccaskill Michael McCaskill added a comment -

            Daniel Beck - The 4th condition seems strange unless it's to protect against human error. Would you issue a warning for a plugin without any version information?

            Show
            mmccaskill Michael McCaskill added a comment - Daniel Beck - The 4th condition seems strange unless it's to protect against human error. Would you issue a warning for a plugin without any version information?
            mmccaskill Michael McCaskill made changes -
            Remote Link This issue links to "API PR (Web Link)" [ 15626 ]
            mmccaskill Michael McCaskill made changes -
            Remote Link This issue links to "UI PR (Web Link)" [ 15627 ]
            Hide
            danielbeck Daniel Beck added a comment -

            Michael McCaskill first and last are optional and only for human consumption, only the regex pattern is used by Jenkins. Unless you can get a list of all versions and match that, first/last is the only useful info you can show. Note that a pattern with neither first nor last is probably .* indicating an issue in all releases.

            Show
            danielbeck Daniel Beck added a comment - Michael McCaskill first and last are optional and only for human consumption, only the regex pattern is used by Jenkins. Unless you can get a list of all versions and match that, first/last is the only useful info you can show. Note that a pattern with neither first nor last is probably .* indicating an issue in all releases.
            Hide
            mmccaskill Michael McCaskill added a comment -

            Daniel Beck Oh ok. Currently I am using the pattern to match against the current version of the plugin to determine if it's "active". But if first and last is missing then I can assume it is implicitly active?

            Show
            mmccaskill Michael McCaskill added a comment - Daniel Beck Oh ok. Currently I am using the pattern to match against the current version of the plugin to determine if it's "active". But if first and last is missing then I can assume it is implicitly active?
            Hide
            danielbeck Daniel Beck added a comment -

            Michael McCaskill No, use the pattern as much as possible, that's the relevant one also used e.g. in Jenkins when it only matters whether "this" version is affected. For active/not, you also have "this" version – the one you show as latest.

            First/last are not guaranteed to be there. If you want to be fancy and the pattern doesn't match current but it's still without first/last, call it "some versions" and move on

            Show
            danielbeck Daniel Beck added a comment - Michael McCaskill No, use the pattern as much as possible, that's the relevant one also used e.g. in Jenkins when it only matters whether "this" version is affected. For active/not, you also have "this" version – the one you show as latest. First/last are not guaranteed to be there. If you want to be fancy and the pattern doesn't match current but it's still without first/last, call it "some versions" and move on
            Hide
            mmccaskill Michael McCaskill added a comment - - edited

            Daniel Beck Ok sounds good. Thanks for the clarification. I am making a change to default to ".*" for the pattern if it's not given for a version range.

            Verified the pattern is always going to be there so need to account for setting a default.

            Show
            mmccaskill Michael McCaskill added a comment - - edited Daniel Beck Ok sounds good. Thanks for the clarification. I am making a change to default to ".*" for the pattern if it's not given for a version range. Verified the pattern is always going to be there so need to account for setting a default.
            Hide
            mmccaskill Michael McCaskill added a comment -

            PRs have been merged to develop.

            Show
            mmccaskill Michael McCaskill added a comment - PRs have been merged to develop.
            mmccaskill Michael McCaskill made changes -
            Resolution Fixed [ 1 ]
            Status In Progress [ 3 ] Done [ 10004 ]

              People

              Assignee:
              mmccaskill Michael McCaskill
              Reporter:
              danielbeck Daniel Beck
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: