Change:
Download the latest release and unpack this tar file on Linux or OS X, cd to the created `kubernetes/` directory, and then follow the getting started guide for your cloud. <ins> On OS X you can also use the [homebrew](http://brew.sh/) package manager: `brew install kubernetes-cli` </ins> ### Building from source Get the Kubernetes source.  If you are simply building a release from source there is no need to set up a full golang environment as all building happens in a Docker container.

Discussion:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: The RSS vulnerability feed includes an invalid GUID; see this excerpt: (the space character is not allowed there) Proposed Solution: Find another way to generate elements for the CVE feed Page to Update: (and the feeds it links to) <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /kind bug /sig security
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Could this possibly be resolved at the , ensuring that the script generating data for the CVE feed contains accurate formatted information? Currently, it seems the script () generating feed data assumes there is only one CVE ID in the GitHub issue title used for data generation.
/assign I think I might have an idea for an approach to solve this issue based on comment
I can see two approaches to solving this bug: the Python script to only take the first CVE in the list so that our guid links are not malformed; or we want to preserve as much information as possible, we could find some way to alter both the script and to show multiple guids if they exist. I think option 1 makes the most sense, but I am open to suggestions. I'll start with approach 1 first :+1:
Thank you for the discussion on this and follow up PR. This fix seems fine to me. However, I am wondering if this would result in everyone getting notified about old CVEs through RSS Subscriptions as this will create new entries and how much potential panic if any this may create.
Fixed the specific instance called out in the issue, by retitling the issue, so we have more time to discuss this. See here:
Another option to fix this without creating new entries would be to strip the space in the title GUID in the script. So it is consistent everywhere.

I am hesitant to breakdown into two new CVEs, when the announcement and issue are done together and more importantly the CVEs are closely related.
How many instances are there? If it's not many this seems OK to do once and get a better format. Are we currently going to generate this at which will be valid as a guid but not valid as a link ...?
great point about CVE dot org link not working. It's a pity it does not take multiple CVEs. I just checked how many such instances of multiple CVEs in a single Github Issue we have. The one described in the issue is the only one. So in that case I agree this would be worth fixing it and will not cause too much panic.