jiebi/CodeConvo huggingface dataset:
Change:
What would you like to be : The release notes state "No notable changes for this release": However it turns out these releases fix important security problems: Why is this needed: If people track releases in, for example, GitHub and then use the release notes to see what's changed, they will totally miss that important security problems have been fixed in these releases. People should not have to look in multiple places to find news of such fixes. The current practice risks people not upgrading because there were "no notable changes" and being oblivious to the risks they run.
I expect this is one for and probably others but I don't really have any clue who.
/sig release This has to do with the timing of cutting the releases vs sending the announcements. The notices were included in the announcement, but not in the generated md files. /assign can you open a PR to update those?
Looks like they put it in the email and the group, but not the release notes. !topic/kubernetes-security-announce/vUtEcSEY6SM/discussion
Just opened a PR to fix this: (I only noticed that this issue was already assigned after committing my changes, hope that's OK)
Thanks that PR looks exactly like what I'm after for this particular update!

Discussion:
## Changelog since v1.13.8 <del> **No notable changes for this release** </del> <ins> * Fix CVE-2019-11249: Incomplete fixes for CVE-2019-1002101 and CVE-2019-11246, kubectl cp potential directory traversal ([#80436](https://github.com/kubernetes/kubernetes/pull/80436)) * Fix CVE-2019-11247: API server allows access to custom resources via wrong scope ([#80750](https://github.com/kubernetes/kubernetes/pull/80750)) See also the [security announcement for this release](https://groups.google.com/forum/#!topic/kubernetes-security-announce/vUtEcSEY6SM). </ins> # v1.13.8

## Changelog since v1.14.4 <del> **No notable changes for this release** </del> <ins> * Fix CVE-2019-11249: Incomplete fixes for CVE-2019-1002101 and CVE-2019-11246, kubectl cp potential directory traversal ([#80436](https://github.com/kubernetes/kubernetes/pull/80436)) * Fix CVE-2019-11247: API server allows access to custom resources via wrong scope ([#80750](https://github.com/kubernetes/kubernetes/pull/80750)) See also the [security announcement for this release](https://groups.google.com/forum/#!topic/kubernetes-security-announce/vUtEcSEY6SM). </ins> # v1.14.4

## Changelog since v1.15.1 <del> **No notable changes for this release** </del> <ins> * Fix CVE-2019-11249: Incomplete fixes for CVE-2019-1002101 and CVE-2019-11246, kubectl cp potential directory traversal ([#80436](https://github.com/kubernetes/kubernetes/pull/80436)) * Fix CVE-2019-11247: API server allows access to custom resources via wrong scope ([#80750](https://github.com/kubernetes/kubernetes/pull/80750)) See also the [security announcement for this release](https://groups.google.com/forum/#!topic/kubernetes-security-announce/vUtEcSEY6SM). </ins> # v1.15.1
Change:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: sig-windows#flannel-overlay-windows-master Which test(s) are failing: [sig-network] DNS should provide DNS for the cluster [Conformance] [sig-network] DNS should provide DNS for services [Conformance] Since when has it been failing: Since this PR merged: Testgrid link: Reason for failure: The mentioned PR replaces the usage of file is not managed by Kubernetes. Anything else we need to know: /sig testing /sig windows /area conformance
/cc
/assign
a little help here :sweat_smile: , how can I test this to come up with a fix? I can't see how is the output of getent in windows
Yeah, so, file is commented. Keep in mind that that file is not managed by Kubelet because we cannot mount individual files in Windows containers at the moment (that's how it's done on Linux), until the ContainerD work is done for Windows as well. I couldn't find a platform-agnostic command that could work on both OSes and for both IPv4 and IPv6 as you'd like. I was instead thinking of adding a subcommand to the ` from the start, if memory serves, other IPv6 tests are considered experimental), especially since we don't really support IPv6 at this point on Windows. Thoughts, , ?
one way to solve this is using the new feature to e2e tests with to autodetect the IP family of the cluster. That will imply reverting and rewriting the DNS tests leveraging that new functionality. I can do it if you want
/unassign /assign

Discussion:
podARecByUDPFileName := fmt.Sprintf("%s_udp@PodARecord", fileNamePrefix) podARecByTCPFileName := fmt.Sprintf("%s_tcp@PodARecord", fileNamePrefix) <del> probeCmd += fmt.Sprintf(`podARec=$$(getent hosts $$(hostname | awk '{print $1}') | tr ":." "-" | awk '{print $$1".%s.pod.%s"}');`, namespace, dnsDomain) </del> <ins> if framework.TestContext.IPFamily == "ipv6" { probeCmd += fmt.Sprintf(`podARec=$$(getent hosts $$(hostname | awk '{print $1}') | tr ":." "-" | awk '{print $$1".%s.pod.%s"}');`, namespace, dnsDomain) } else { probeCmd += fmt.Sprintf(`podARec=$$(hostname -i| awk -F. '{print $$1"-"$$2"-"$$3"-"$$4".%s.pod.%s"}');`, namespace, dnsDomain) } </ins> probeCmd += fmt.Sprintf(`check="$$(dig +notcp +noall +answer +search $${podARec} A $${podARec} AAAA)" && test -n "$$check" && echo OK > /results/%s;`, podARecByUDPFileName) probeCmd += fmt.Sprintf(`check="$$(dig +tcp +noall +answer +search $${podARec} A $${podARec} AAAA)" && test -n "$$check" && echo OK > /results/%s;`, podARecByTCPFileName) fileNames = append(fileNames, podARecByUDPFileName)
Change:
What happened: The conformance test "validates resource limits of pods that are allowed to run" is failed if master node doesn't have taints. What you expected to happen: All conformance tests should pass even if a master node doesn't have taints. How to reproduce it (as minimally and precisely as possible): If a master node has taints like many cases, the test can pass like the following: However if the master node doesn't have any taints, the test cannot pass like: Anything else we need to know?: I am guessing this issue can be related to Environment: Kubernetes version (use ): v1.15.1 Cloud provider or hardware configuration: OpenStack OS (e.g: ): Ubuntu 18.04.2 LTS Kernel (e.g. ): 4.15.0-46-generic Install tools: kubeadm Network plugin and version (if this is a network-related bug): Others:
/sig scheduling
The test log contains only, that means the test doesn't create a pod on the master node which doesn't have any taints when this issue happens. The following log is the part of when the issue happened. Important line is which says additional-pod which was expected to be failed to be schedule is assigned to the master node.
nodeList is gotten from as in BeforeEach() step. And as I said on the function is problematic now.
The discussion on the slack:

Discussion:
var err error framework.AllNodesReady(cs, time.Minute) <del> masterNodes, nodeList, err = e2enode.GetMasterAndWorkerNodes(cs) </del> <ins> // NOTE: Here doesn't get nodeList for supporting a master nodes which can host workload pods. masterNodes, _, err = e2enode.GetMasterAndWorkerNodes(cs) </ins> if err != nil { e2elog.Logf("Unexpected error occurred: %v", err) } <ins> nodeList, err = e2enode.GetReadySchedulableNodesOrDie(cs) if err != nil { e2elog.Logf("Unexpected error occurred: %v", err) } </ins> // TODO: write a wrapper for ExpectNoErrorWithOffset() framework.ExpectNoErrorWithOffset(0, err)
Change:
This issue was reported in the Description The kube-apiserver includes multiple authentication backends for client request processing. These range in strength from client certificate authentication to simple HTTP Basic Authentication. When using a password (Basic Authentication), the kube-apiserver does not perform a secure comparison of secret values. In theory, this could allow an attacker to perform a timing attack on the comparison. For example, the AuthenticatePassword function simply performs string comparison to authenticate a user’s password (Figure 9.1). Figure 9.1: Username and password authentication handling in Exploit Scenario Alice runs a Kubernetes cluster in production. In order to support multiple organizational “customers,” she configures the cluster with HTTP Basic Authentication. Eve has a large number of username and password pairs for the organization, and uses the side-channel information from string comparison to tune her credential-stuffing attacks. Recommendation Short term, use a safe, constant-time comparison function such as . The comparison function should take the same amount of time regardless of matching prefix data within the password. Long term, deprecate Basic Authentication in favor of more robust and secure options. Add documentation noting that any Basic Authentication is for use only in development scenarios, and not appropriate for production deployments. This will help users create a robust and secure default stance for all deployments. Anything else we need to know?: See for current status of all issues created from these findings. The vendor gave this issue an ID of ATR-K8S-002 and it was finding 18 of the report. The vendor considers this issue Medium Severity. To view the original finding, begin on page 55 of the Environment: Kubernetes version: 1.13.4 Fixed in v1.16.0 by
/sig auth
/area security /kind bug /remove-kind feature

Discussion:
fs.StringVar(&s.PasswordFile.BasicAuthFile, "basic-auth-file", s.PasswordFile.BasicAuthFile, ""+ "If set, the file that will be used to admit requests to the secure port of the API server "+ "via http basic authentication.") <ins> fs.MarkDeprecated("basic-auth-file", "Basic authentication mode is deprecated and will be removed in a future release. It is not recommended for production environments.") </ins> } if s.RequestHeader != nil {

import ( "context" <ins> "crypto/subtle" </ins> "encoding/csv" "fmt" "io"

if !ok { return nil, false, nil } <del> if user.password != password { </del> <ins> if subtle.ConstantTimeCompare([]byte(user.password), []byte(password)) == 0 { </ins> return nil, false, nil } return &authenticator.Response{User: user.info}, true, nil
Change:
This issue was reported in the Description Kubernetes can be configured to use iSCSI volumes. When using CHAP authentication, CHAP secrets are stored using the Secrets API, such as in this . When a pod is configured to use iSCSI and the AttachDisk method is called, this will call the code in Figure 1. Figure 19.1: iSCSI secret handling These two functions both iterate over a slice of strings that are keys that reference secrets in a map. These are then used to generate iscsiadm commands. As shown, if there are errors in executing these commands, errors are returned with both the key and secret values in the error string. These errors will eventually be logged using klog: Someone with access to these logs would be able to view the sensitive secrets and could potentially gain access to iSCSI volumes. Exploit Scenario Alice runs a cluster, and wishes to use iSCSI for data storage. Eve has access sufficient to collect the logs, and uses this access to connect to iSCSI storage devices as a privileged user. Recommendation Short term, as in TOB-K8S-001: Bearer tokens revealed in logs, do not log sensitive credentials at any logging level, as they may accidentally leak into inappropriate environments, such as production. Long term, implement policies that enforce code review to ensure that sensitive data is not exposed in logs, or implement logging filters that check for sensitive data and remove it prior to reification within logs. In either case, ensure that sensitive data cannot be stored in logs. Anything else we need to know?: See for current status of all issues created from these findings. The vendor gave this issue an ID of ATR-K8S-003 and it was finding 22 of the report. The vendor considers this issue Medium Severity. To view the original finding, begin on page 61 of the Environment: Kubernetes version: 1.13.4
/sig storage /area security /kind bug /remove-kind feature

Discussion:
if len(v) > 0 { out, err := b.exec.Run("iscsiadm", "-m", "discoverydb", "-t", "sendtargets", "-p", tp, "-I", b.Iface, "-o", "update", "-n", k, "-v", v) if err != nil { <del> return fmt.Errorf("iscsi: failed to update discoverydb key %q with value %q error: %v", k, v, string(out)) </del> <ins> return fmt.Errorf("iscsi: failed to update discoverydb key %q error: %v", k, string(out)) </ins> } } }

if len(v) > 0 { out, err := b.exec.Run("iscsiadm", "-m", "node", "-p", tp, "-T", b.Iqn, "-I", b.Iface, "-o", "update", "-n", k, "-v", v) if err != nil { <del> return fmt.Errorf("iscsi: failed to update node session key %q with value %q error: %v", k, v, string(out)) </del> <ins> return fmt.Errorf("iscsi: failed to update node session key %q error: %v", k, string(out)) </ins> } } }
Change:
What happened: When an issue happens at the following check in the conformance test "validates resource limits of pods that are allowed to run": the debugging message ("Scheduled Pods: %#v") doesn't appear in the log at all like the following: ` and that makes debugging difficult actually. What you expected to happen: The debugging message should appear in the log if an issue happens. Environment: Kubernetes version (use ): v1.15.1 Cloud provider or hardware configuration: OpenStack OS (e.g: ): Ubuntu 18.04.1 LTS Kernel (e.g. ): 4.15.0-55-generic Install tools: kubeadm Network plugin and version (if this is a network-related bug): Others:
/sig testing /sig scheduling

Discussion:
framework.ExpectNoError(err) scheduledPods, notScheduledPods := e2epod.GetPodsScheduled(masterNodes, allPods) <del> printed := false printOnce := func(msg string) string { if !printed { printed = true return msg } return "" } framework.ExpectEqual(len(notScheduledPods), expectedNotScheduled, printOnce(fmt.Sprintf("Not scheduled Pods: %#v", notScheduledPods))) framework.ExpectEqual(len(scheduledPods), expectedScheduled, printOnce(fmt.Sprintf("Scheduled Pods: %#v", scheduledPods))) </del> <ins> framework.ExpectEqual(len(notScheduledPods), expectedNotScheduled, fmt.Sprintf("Not scheduled Pods: %#v", notScheduledPods)) framework.ExpectEqual(len(scheduledPods), expectedScheduled, fmt.Sprintf("Scheduled Pods: %#v", scheduledPods)) </ins> } // verifyReplicasResult is wrapper of verifyResult for a group pods with same "name: labelName" label, which means they belong to same RC

allPods := getPodsByLabels(c, ns, map[string]string{"name": labelName}) scheduledPods, notScheduledPods := e2epod.GetPodsScheduled(masterNodes, allPods) <del> printed := false printOnce := func(msg string) string { if !printed { printed = true return msg } return "" } framework.ExpectEqual(len(notScheduledPods), expectedNotScheduled, printOnce(fmt.Sprintf("Not scheduled Pods: %#v", notScheduledPods))) framework.ExpectEqual(len(scheduledPods), expectedScheduled, printOnce(fmt.Sprintf("Scheduled Pods: %#v", scheduledPods))) </del> <ins> framework.ExpectEqual(len(notScheduledPods), expectedNotScheduled, fmt.Sprintf("Not scheduled Pods: %#v", notScheduledPods)) framework.ExpectEqual(len(scheduledPods), expectedScheduled, fmt.Sprintf("Scheduled Pods: %#v", scheduledPods)) </ins> } func getPodsByLabels(c clientset.Interface, ns string, labelsMap map[string]string) *v1.PodList {
Change:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: pull-kubernetes-integration Which test(s) are failing: TestPreemptWithPermitPlugin Since when has it been failing: 13:30 PST, Sep 9, 2019 Testgrid link: Reason for failure: Need investigations. Anything else we need to know: /sig scheduling
Another flaky It happens at 2019-08-06 05:43:47 +0000 UTC
The above repeated for 30 seconds.
I checked the code and log again. I think the reason is as following: When scheduler preempted , it failed to delete the pod(same as the case for , there might be something wrong with etcd), so it could not schedule because had not been deleted successfully.
/assign Find the root cause now, will send a PR soon.
Thanks for your work! Not sure whether you are still investigating it, the flaky test is impacting many PRs now, so I send a PR for it now, sorry for it.

Discussion:
return unresPlugin, nil } <del> var perPlugin = &PermitPlugin{} </del> // Name returns name of the plugin. func (pp *PermitPlugin) Name() string { return permitPluginName

pp.allowPermit = false } <del> // NewPermitPlugin is the factory for permit plugin. func NewPermitPlugin(_ *runtime.Unknown, fh framework.FrameworkHandle) (framework.Plugin, error) { perPlugin.fh = fh return perPlugin, nil </del> <ins> // NewPermitPlugin returns a factory for permit plugin with specified PermitPlugin. func NewPermitPlugin(permitPlugin *PermitPlugin) framework.PluginFactory { return func(_ *runtime.Unknown, fh framework.FrameworkHandle) (framework.Plugin, error) { permitPlugin.fh = fh return permitPlugin, nil } </ins> } // TestPrefilterPlugin tests invocation of prefilter plugins.

// TestPermitPlugin tests invocation of permit plugins. func TestPermitPlugin(t *testing.T) { // Create a plugin registry for testing. Register only a permit plugin. <del> registry := framework.Registry{permitPluginName: NewPermitPlugin} </del> <ins> perPlugin := &PermitPlugin{} registry := framework.Registry{permitPluginName: NewPermitPlugin(perPlugin)} </ins> // Setup initial permit plugin for testing. plugins := &schedulerconfig.Plugins{

// TestCoSchedulingWithPermitPlugin tests invocation of permit plugins. func TestCoSchedulingWithPermitPlugin(t *testing.T) { // Create a plugin registry for testing. Register only a permit plugin. <del> registry := framework.Registry{permitPluginName: NewPermitPlugin} </del> <ins> perPlugin := &PermitPlugin{} registry := framework.Registry{permitPluginName: NewPermitPlugin(perPlugin)} </ins> // Setup initial permit plugin for testing. plugins := &schedulerconfig.Plugins{

// TestPreemptWithPermitPlugin tests preempt with permit plugins. func TestPreemptWithPermitPlugin(t *testing.T) { // Create a plugin registry for testing. Register only a permit plugin. <del> registry := framework.Registry{permitPluginName: NewPermitPlugin} </del> <ins> perPlugin := &PermitPlugin{} registry := framework.Registry{permitPluginName: NewPermitPlugin(perPlugin)} </ins> // Setup initial permit plugin for testing. plugins := &schedulerconfig.Plugins{
Change:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: The image () used to run the per-pod infra/pause container logs to stdout about once per second. What you expected to happen: Pause container not logging anything. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Kubelet does not expose, nor manage these logs. Writing the logs wastes resources and takes up disk space, which may not be properly accounted by kubelet. The pause image used for the e2e tests seems much better: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/assign Will also rebuild with

Discussion:
sudo docker ps ``` <del> And see the actual task.  (note that initial ```docker pull``` may take a few minutes, depending on network conditions. </del> <ins> And see the actual task.  (Note that initial ```docker pull``` may take a few minutes, depending on network conditions.) </ins> ### Step Two: Turn up the master service. A Kubernetes 'service' is named load balancer that proxies traffic to one or more containers.  The services in a Kubernetes cluster are discoverable inside other containers via environment variables.  Services find the containers to load balance based on task labels.  The task that you created in Step One has the label "name=redis-master", so the corresponding service is defined by that label.  Create a file named redis-master-service.json that contains:

Once you have that service description, you can create the service with the cloudcfg cli: ```shell <del> ./src/scripts/cloudcfg.sh -c redis-master-service create /services </del> <ins> ./src/scripts/cloudcfg.sh -c redis-master-service.json create /services </ins> ``` Once created, the service proxy on each minion is configured to set up a proxy on the specified port (in this case port 10000).

} ``` <del> This time the label query for the service is 'name=redis-slave' </del> <ins> This time the label query for the service is 'name=redis-slave'. </ins> Now that you have created the service specification, create it in your cluster with the cloudcfg cli:

} ?> ``` <del> To play with the service itself, find the name of a frontend, grab the external IP of that host from the Google Cloud Console, and visit http://&lt;host-ip&gt;:8080, note you may need to open the firewall for port 8080 using the console or the gcloud tool. </del> <ins> To play with the service itself, find the name of a frontend, grab the external IP of that host from the Google Cloud Console, and visit http://&lt;host-ip&gt;:8080. Note, you may need to open the firewall for port 8080 using the console or the gcloud tool. </ins>

detect-master <del> ./target/cloudcfg -h https://${KUBE_MASTER_IP} $@ </del> <ins> $(dirname $0)/../../target/cloudcfg -h https://${KUBE_MASTER_IP} $@ </ins>
Change:
What happened: The stackdriver logging agent is installed and start running no matter logging is enabled/disabled in the cluster or not. What you expected to happen: Do not install and start the logging agent if logging is disabled.
/sig windows
cc

Discussion:
Import-Module -Force C:$Filename } <ins> # Returns true if the ENABLE_STACKDRIVER_WINDOWS or ENABLE_NODE_LOGGING field in kube_env is true. # $KubeEnv is a hash table containing the kube-env metadata keys+values. # ENABLE_NODE_LOGGING is used for legacy Stackdriver Logging, and will be deprecated (always set to False) # soon. ENABLE_STACKDRIVER_WINDOWS is added to indicate whether logging is enabled for windows nodes. function IsLoggingEnabled { param ( [parameter(Mandatory=$true)] [hashtable]$KubeEnv ) if ($KubeEnv.Contains('ENABLE_STACKDRIVER_WINDOWS') -and ` ($KubeEnv['ENABLE_STACKDRIVER_WINDOWS'] -eq 'true')) { return $true } elseif ($KubeEnv.Contains('ENABLE_NODE_LOGGING') -and ` ($KubeEnv['ENABLE_NODE_LOGGING'] -eq 'true')) { return $true } return $false } </ins> try { # Don't use FetchAndImport-ModuleFromMetadata for common.psm1 - the common # module includes variables and functions that any other function may depend

Create-Directories Download-HelperScripts <del> Install-LoggingAgent Configure-LoggingAgent Restart-LoggingAgent </del> <ins> # Even if Stackdriver is already installed, the function will still [re]start the service. if (IsLoggingEnabled $kube_env) { Install-LoggingAgent Configure-LoggingAgent Restart-LoggingAgent } </ins> Create-DockerRegistryKey Configure-Dockerd
Change:
What happened: The vresion of the hostpathplugin specified in the kubernetes e2e tests had a bug in cloning causing storageclass compare checks to always fail. As a result e2e tests could not pass for cloning in kubernetes. What you expected to happen: The version referencedin e2e tests should have a working hostpathplugin image to enable e2e testing of clone functinoality. How to reproduce it (as minimally and precisely as possible): Attempt to run the e2e cloning test: without modifying the hostpathplugin image version, test will fail due to storageClass mismatch even when set properly in the test. Anything else we need to know?: Fix in hostpathplugin is available in hostpathplugin:v1.2.0-rc4 There's also a required update to the provisioner side-car which has been submitted here:
/sig storage /assign

Discussion:
- mountPath: /registration name: registration-dir - name: hostpath <del> image: quay.io/k8scsi/hostpathplugin:v1.2.0-rc3 </del> <ins> image: quay.io/k8scsi/hostpathplugin:v1.2.0-rc4 </ins> args: - "--v=5" - "--endpoint=$(CSI_ENDPOINT)"