Skip to content

Extend default debian/gbp.conf with extra security config tips #246

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Extend default debian/gbp.conf with extra security config tips #246

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 36 additions & 2 deletions template.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -341,8 +341,42 @@ 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, `
# Enable pristine-tar to exactly reproduce orig tarballs
pristine-tar = True

`)
}

// Additional text to the template which is useful for 99% of the go packages
fmt.Fprint(f, `
# Lax requirement to use branch name 'debian/latest' so that git-buildpackage
# 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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This ignore-branch = True is simply a flag to make it easier to build branches with various names, for example using name bugfix/123456-arm64-build-error. It has nothing to do with debian/latest. It is very common for people to use multiple different branch names for bugfixes and features, and submit those branches as Merge Requests on Salsa. Once merged, the branch can be deleted.


# The Debian packaging git repository may also host actual upstream tags and
# branches, typically named 'main' or 'master'. Configure the upstream tag
# format below, so that 'gbp import-orig' will run correctly, and link tarball
# import branch ('upstream/latest') with the equivalent upstream release tag,
# showing a complete audit trail of what upstream released and what was imported
# into Debian.
#
# TODO: Most Go packages have tags of form 'v1.0.0', but must be double-checked.
upstream-vcs-tag = v%(version%~%-)s
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO is used elsewhere in these templates so we should use that instead of FIXME. But I agree that a TODO comment recommending to verify that it is correct would be good.

Maybe also this line should be commented if we detect that there are no tags yet (the same way it is done in the watch file).


# If upstream publishes tarball signatures, git-buildpackage will by default
# import and use the them. Change this to 'on' to make 'gbp import-orig' abort
# if the signature is not found or is not valid.
#
# Most Go packages don't publish signatures for the tarball releases, so this is
# not enabled by default.
#upstream-signatures = on
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a good change, and commenting it out by default seems like the safest option, indeed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


# Ensure the Debian maintainer signs git tags automatically.
sign-tags = True
`)
return nil
}

Expand Down