Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bringing supply chain security features to the Go community

github.blog

Post reply on HN
Print view View original

41–50 of 72 posts

Re: Bringing supply chain security features to the Go community

#41

Post by newman314 »

veverkap wrote: post #26
zdw wrote: post #18

Earlier quoted context omitted.

It would be wonderful if there were bulk editing of Dependabot settings across multiple repos. The weakest part of GitHub is the lack of bulk administrative edits (repo settings, not code changes) across multiple repos. This affects group (team) permissions as well - having to add a new team to multiple repos with specific permissions is a manual slog and hard to audit. Even the expanded permission categories are fre…

At a previous employer, we used Terraform to manage GitHub teams/repos/permissions. It worked ... okay. Might be worth a try for you?

Can you expand a bit more on how you achieved this? It sounds interesting.

Re: Bringing supply chain security features to the Go community

#42

Post by burnished »

samatman wrote: post #40
wolverine876 wrote: post #37

Earlier quoted context omitted.

> The team is still relatively small (it's 7 people), and supporting a service like this at GitHub scale is hard, but we're keen to keep improving. While I empathize with your team regarding their apparent workload, that's only because they (probably) don't control hiring. GitHub isn't a struggling startup; it's not a non-profit; it's a mature, sizeable organization whose owner has over a trillion dollars in assets.…

The Mythical Man-Month is probably older than you.

That book is an incredible read for anyone, even just the first couple chapters, but the central thesis is "you probably cannot pay any amount of money to make an over-due software development (or many other kinds of development) project be an on-time project", and not "there is no point in growing a team to solve bigger problems faster". You can't hire another orchestra to help play the same song faster, but you can hire another orchestra for more music over a longer time.

Re: Bringing supply chain security features to the Go community

#43

Post by dmitriid »

greysteil wrote: post #13
leo_bloom wrote: post #2

GitHub's dependabot is causing a ton of "spam" in our frontend (Angular) repositories, as it seemingly opens 1-5 PRs per day to bump random dependencies. I really hope this does not become common practice for our Go repositories. Is there an option to tell dependabot "make one PR per week at most, please, and bundle your changes"?

PM for security products at GitHub here (and one of the original authors of Dependabot). Sorry to hear that. I wouldn't expect us to be telling you about 1-5 security issues a day - do you maybe have (non-security) version updates enabled? If so and they feel like spam to you I'd recommend turning them off. (I wish I had a better suggestion, but until Dependabot supports grouped updates it sounds like it just isn't r…

A must: allow Dependabot to merge PRs automatically. The reason to refuse this is frankly ridiculous [1]. For JS projects Dependabot is little less than a spammer, and the ability to automatically merge minor/patch versions is a must. Having to rely on third-party actions to do this is probably a larger security risk than letting people decide what PRs they want to automerge.

[1] https://github.com/dependabot/feedback/issues/954#issuecomme... and the original issue: https://github.com/dependabot/dependabot-core/issues/1973

And why it doesn't fly: https://github.com/dependabot/dependabot-core/issues/1973#is...

Re: Bringing supply chain security features to the Go community

#44

Post by newman314 »

greysteil wrote: post #13
leo_bloom wrote: post #2

GitHub's dependabot is causing a ton of "spam" in our frontend (Angular) repositories, as it seemingly opens 1-5 PRs per day to bump random dependencies. I really hope this does not become common practice for our Go repositories. Is there an option to tell dependabot "make one PR per week at most, please, and bundle your changes"?

PM for security products at GitHub here (and one of the original authors of Dependabot). Sorry to hear that. I wouldn't expect us to be telling you about 1-5 security issues a day - do you maybe have (non-security) version updates enabled? If so and they feel like spam to you I'd recommend turning them off. (I wish I had a better suggestion, but until Dependabot supports grouped updates it sounds like it just isn't r…

While we are on the feedback train, please consider making the Docker dependabot action more intelligent.

Right now, I have a monorepo with multiple Dockerfiles in subdirectories.

I end up having to add an entire docker block scoped to each directory that has a Dockerfile which is painful. Ideally, I would have a way to specify using */Dockerfile as a way to scan for Docker dependencies.

Also, multi-stage Dockerfile configs seem to confuse Dependabot where it'll submit a pull request to update the "AS build" but not the image to be used for packaging...

I really like the promise/premise of Dependabot, just want it to be easier to use (and edit across multiple repos).

Re: Bringing supply chain security features to the Go community

#45

Post by wolverine876 »

samatman wrote: post #40
wolverine876 wrote: post #37

Earlier quoted context omitted.

> The team is still relatively small (it's 7 people), and supporting a service like this at GitHub scale is hard, but we're keen to keep improving. While I empathize with your team regarding their apparent workload, that's only because they (probably) don't control hiring. GitHub isn't a struggling startup; it's not a non-profit; it's a mature, sizeable organization whose owner has over a trillion dollars in assets.…

The Mythical Man-Month is probably older than you.

Yes, I thought of that, and it's a relevant point IMHO. But while hiring 10,000 people off the street won't improve things, GitHub hardly has its hands tied; they know how to get things done if they want to. We're talking about adding some basic features. Somewhere in GitHub and Microsoft, there probably are some additional highly productive developers who could be assigned to the project.

Re: Bringing supply chain security features to the Go community

#46

Post by xorcist »

zdw wrote: post #18
greysteil wrote: post #13

Earlier quoted context omitted.

PM for security products at GitHub here (and one of the original authors of Dependabot). Sorry to hear that. I wouldn't expect us to be telling you about 1-5 security issues a day - do you maybe have (non-security) version updates enabled? If so and they feel like spam to you I'd recommend turning them off. (I wish I had a better suggestion, but until Dependabot supports grouped updates it sounds like it just isn't r…

It would be wonderful if there were bulk editing of Dependabot settings across multiple repos. The weakest part of GitHub is the lack of bulk administrative edits (repo settings, not code changes) across multiple repos. This affects group (team) permissions as well - having to add a new team to multiple repos with specific permissions is a manual slog and hard to audit. Even the expanded permission categories are fre…

Puppet and Ansible are great for this type of things. If you want a new repo for your group, you make a pull request for our management repo.

There are a bunch of access rights, hooks and tokens that need to be set up in a certain way depending on the type of repo, and Ansible regularly makes sure no one deviates from the intended configuration.

Github (or Bitbucket or Gitlab) isn't different from any other software in this regard.

Re: Bringing supply chain security features to the Go community

#47

Post by karlding »

boarnoah wrote: post #38
leo_bloom wrote: post #2

GitHub's dependabot is causing a ton of "spam" in our frontend (Angular) repositories, as it seemingly opens 1-5 PRs per day to bump random dependencies. I really hope this does not become common practice for our Go repositories. Is there an option to tell dependabot "make one PR per week at most, please, and bundle your changes"?

I usually ignore those and bundle a bunch in a single PR. The worst I found was another team which merges in depandabot PR's one by one. Their git history isn't pleasant to look through :(

The git log command has a --perl-regexp flag [0], which allows you to filter commits that match a Perl-style regular expression. I guess in that situation you could specify a regular expression that excludes dependabot in --author.

If typing --perl-regexp gets old, you can always alias it or add a repo/global config option via grep.patternType [1]. Or you can create an alias for adding the less-powerful --invert-grep [2].

[0] https://git-scm.com/docs/git-log/2.32.0#Documentation/git-lo...

[1] https://git-scm.com/docs/git-config/2.32.0#Documentation/git...

[2] https://git-scm.com/docs/git-log/2.32.0#Documentation/git-lo...

Re: Bringing supply chain security features to the Go community

#48

Post by onei »

newman314 wrote: post #41
veverkap wrote: post #26

Earlier quoted context omitted.

At a previous employer, we used Terraform to manage GitHub teams/repos/permissions. It worked ... okay. Might be worth a try for you?

Can you expand a bit more on how you achieved this? It sounds interesting.

There's a GitHub provider for Terraform [1]. I tried it out on a GitHub Enterprise instance last year and found it a little awkward because they didn't have support for the latest GH APIs and the version before was missing a bunch of features. When I looked recently, they seemed to have got past that.

The principle is broadly the same as other Terraform workflows: import existing config and update it when you need to. You can manage repo permissions, people and teams, all centrally and in code. Super useful for tracking changes (the GH audit logs are a bit lacking in my experience) and identifying discrepancies between the expected and actual configurations.

[1] https://registry.terraform.io/providers/integrations/github/...

Re: Bringing supply chain security features to the Go community

#49

Post by mikewhy »

zdw wrote: post #18
greysteil wrote: post #13

Earlier quoted context omitted.

PM for security products at GitHub here (and one of the original authors of Dependabot). Sorry to hear that. I wouldn't expect us to be telling you about 1-5 security issues a day - do you maybe have (non-security) version updates enabled? If so and they feel like spam to you I'd recommend turning them off. (I wish I had a better suggestion, but until Dependabot supports grouped updates it sounds like it just isn't r…

It would be wonderful if there were bulk editing of Dependabot settings across multiple repos. The weakest part of GitHub is the lack of bulk administrative edits (repo settings, not code changes) across multiple repos. This affects group (team) permissions as well - having to add a new team to multiple repos with specific permissions is a manual slog and hard to audit. Even the expanded permission categories are fre…

Does GitHub have "system level" webhooks like gitlab? That's what I've done previously, so when anyone creates a repo, it's configured as the org expects.

This page[1] seems to mention organization level hooks that receive repository created events, if making your team edit a terraform/puppet/ansible/chef repo to simply create a repo seems overkill to you

[1]: https://docs.github.com/en/developers/webhooks-and-events/we...

Re: Bringing supply chain security features to the Go community

#50

Post by skipants »

leo_bloom wrote: post #2

GitHub's dependabot is causing a ton of "spam" in our frontend (Angular) repositories, as it seemingly opens 1-5 PRs per day to bump random dependencies. I really hope this does not become common practice for our Go repositories. Is there an option to tell dependabot "make one PR per week at most, please, and bundle your changes"?

A setting I turned on to make it more manageable is to ignore patch updates and have dependabot only make PRs for major & minor version bumps.
Post reply on HN