Extend default debian/gbp.conf with extra security config tips #246
Conversation
When creating a new package, populate the git-buildpackage with additional configs and in-line comments on why and how to use them. This will make go packaging easier, more consistent and more secure as the best practices flow to all packages via good defaults. Also add comment to explain why pristine-tar is beneficial.
| @@ -341,8 +341,40 @@ func writeDebianGbpConf(dir string, dep14, pristineTar bool) error { | |||
| fmt.Fprintf(f, "dist = DEP14\n") | |||
| } | |||
| if pristineTar { | |||
| fmt.Fprintf(f, "pristine-tar = True\n") | |||
| fmt.Fprintf(f, ` | |||
| # Always use pristine tar to improve supply chain security and auditability | |||
There was a problem hiding this comment.
I don't agree with this statement, and that it improves security. pristine-tar is a hack, and the team policy to reject its use is the correct one, we should be removing all of its usage across the team not encouraging it again. This wording tries to give it a positive side which it does not have.
If a comment needs to be added, then it should spell the team policy and that pristine-tar is problematic and should be avoided.
There was a problem hiding this comment.
Pristine-tar is not a hack. If you claim that it is bad, you should present some evidence, and then we can assess if it is compelling. In https://salsa.debian.org/go-team/go-team.pages.debian.net/-/merge_requests/7#note_574266 I already asked for this, and you just provided a link to a comment in a bug report that is 10+ years old.
There was a problem hiding this comment.
I already presented references, rationale, and arguments why this is bad, but you keep latching on that comment as if this was the only thing presented, and as if was some stale thing that has somehow decayed by time, where time itself has somehow changed its design. And as mentioned on that other thread, that's a comment from the original developer and designer of the tool itself.
But in any case this is not how things work, you are the one approaching a team with an established policy and workflow, where you want to change it (after having just joined!), so the onus is on you to prove whether all the flaws in its design have changed at all since its inception (they have not). So I'm finding your comment about requiring evidence so that "we can assess if it is compelling" (so trying to invert the onus), while having conveniently dismissed all the previous discussion, to be rather rude.
There was a problem hiding this comment.
Please stop using ad hominem arguments here and in your other comments elsewhere. The merits of using pristine-tar can fully be debated on its own without having to resort to ad hominem arguments about who is suggesting it.
I have been using pristine-tar on numerous packages for many years and it works well. The man page is not stating it is a hack or discouraging it's use. It does it's job, allows one to run gbp clone of a repo when reviewing changes and building, and it is very space efficient. In the Debian packaging world where we require the package sources to include the upstream source, pristine-tar serves its purpose well.
There was a problem hiding this comment.
Anyway, this is not making pristine-tar default, it is just adding an inline comment if pristine-tar was used.
| # will always build using the currently checked out branch as the Debian branch. | ||
| # This makes it easier for contributors to work with feature and bugfix | ||
| # branches. | ||
| ignore-branch = True |
There was a problem hiding this comment.
This also goes against the current team workflow, and tries to sneak it in and encourage using debian/latest which I've already argued (see debian-devel for example), is a bad default in the Debian context. Introducing yet a different workflow in the team when we should be consolidating on the existing one, would make working on the go packages more painful.
| # upstream released and what was imported into Debian. | ||
| # | ||
| # Most Go packages have tags of form 'v1.0.0' | ||
| upstream-vcs-tag = v%(version%~%-)s |
There was a problem hiding this comment.
The upstream/latest branch name is not what the team workflow has agreed to, please remove that part.
Otherwise I think this change is fine, but given that I don't think it might be universally followed by upstreams, maybe it should be marked with a FIXME, and/or commented out by default.
I'd end the last sentence with a dot though.
| # | ||
| # Most Go packages don't publish signatures for the tarball releases, so this is | ||
| # not enabled by default. | ||
| #upstream-signatures = on |
There was a problem hiding this comment.
I think this is a good change, and commenting it out by default seems like the safest option, indeed.
There was a problem hiding this comment.
For full benefits of signature checking we also need to use pristine-tar that allows bit-for-bit identical tarballs and thus signature checking for tracing the source code supply-chain.
There was a problem hiding this comment.
Err, no. The tarball does not need to be stored in pristine-tar at all for the signatures to be useful. The tarball along their signatures are going to be stored in the archive, tied with the uploader signature and handed over to the archive signatures later on, there's full traceability of all this in place already.
| #upstream-signatures = on | ||
|
|
||
| # Ensure the Debian maintainer signs git tags automatically | ||
| sign-tags = True |
There was a problem hiding this comment.
This also seems like a good change. I'd end the sentence with a dot though.
When creating a new package, populate the git-buildpackage with additional configs and in-line comments on why and how to use them. This will make go packaging easier, more consistent and more secure as the best practices flow to all packages via good defaults.
Also add comment to explain why pristine-tar is beneficial.