Prow web UI exposes private repositories

[ivanvc]

The plugin catalog and the command help pages expose private repositories in the repository dropdown. For example, both show the repository etcd-io/etcd-GHSA-j8g6-82f3-cvhp, which is private.

I tried tracing the issue, and it seems to come from (client) GetRepos(...), as it gets all the repositories accessible to the user/organization without filtering (however, I may be wrong that this is the root cause):

prow/pkg/github/client.go

Lines 2529 to 2560 in 79d27b6

	func (c *client) GetRepos(org string, isUser bool) ([]Repo, error) {
	durationLogger := c.log("GetRepos", org, isUser)
	defer durationLogger()
	var (
	repos []Repo
	nextURL string
	)
	if c.fake {
	return repos, nil
	}
	if isUser {
	nextURL = fmt.Sprintf("/users/%s/repos", org)
	} else {
	nextURL = fmt.Sprintf("/orgs/%s/repos", org)
	}
	err := c.readPaginatedResults(
	nextURL, // path
	acceptNone, // accept
	org,
	func() interface{} { // newObj
	return &[]Repo{}
	},
	func(obj interface{}) { // accumulate
	repos = append(repos, *(obj.(*[]Repo))...)
	},
	)
	if err != nil {
	return nil, err
	}
	return repos, nil
	}

[smg247]

This is obviously not expected behavior, but this doesn't seem harmful to me. You can see the repositories in the dropdown, but there is no data there when selected. Essentially, we are leaking names of private repositories. Is there a reason you can think of where this is a serious issue?

[BenTheElder]

FWIW, if this is considered a problem, I'd highly recommend using a distinct instance.

prow.k8s.io used to have private repositories for some sensitive embargoed security-patch related work, but that's not the approach now, and the Kubernetes project is primarily focused on open repos.

It's super likely that there will be other gaps and I would encourage using an isolated deployment for anything so sensitive that the names of the repos are considered an info leak.

[ivanvc]

I don't have a local Prow deployment. However, I noticed this information leak while checking Prow's Web UI. I don't know if other Kubernetes organizations make use of private repositories. I noticed etcd's because I'm a contributor.

Feel free to close if you feel this is irrelevant or the risk is minor :)

[BenTheElder]

We should probably consider this a bug anyhow, I just didn't want anyone getting the wrong idea about how secure this is.

That includes etcd, we should discuss privately in slack with the other K8s Infra / Testing leads about the requirements for etcd and private repos.

[BenTheElder]

/kind bug
/sig testing

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten