From: "brian m. carlson" <sandals@crustytoothpaste•net>
To: ynckz <yanckezcs@gmail•com>
Cc: git@vger•kernel.org
Subject: Re: Git private branch Feature Suggestion
Date: Thu, 11 Sep 2025 00:00:59 +0000 [thread overview]
Message-ID: <aMIRO83CyG_qtKez@fruit.crustytoothpaste.net> (raw)
In-Reply-To: <CAGyVUB5QLV+HQMWT+0kDu1_H0uXHK7kTy35WqhXQaETZ5if5EQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2974 bytes --]
On 2025-09-10 at 23:28:54, ynckz wrote:
> Hi Git developers,
>
> I have a request for you. Could you please add private branches? This
> is a really useful thing.
> Imagine that you want to publish your project as open source, but you
> need to hide the .env file in a separate repository. It's easier to do
> everything in one repository, but in a different branch. Maybe there
> is another way, and I'm just dumb as fuck, but here's another example:
> Say you don't want to release a new feature yet. To do so, create a
> private branch, make the feature there, then merge it into the main
> branch.
The reason we haven't added this is that it isn't secure. Git has a
feature called namespaces, which basically implements the feature you
want. There are different namespaces and references can be stored in
any one of them.
Here's what the gitnamespaces(5) manual page says about this:
The fetch and push protocols are not designed to prevent one side
from stealing data from the other repository that was not intended
to be shared. If you have private data that you need to protect from
a malicious peer, your best option is to store it in another
repository. This applies to both clients and servers. In particular,
namespaces on a server are not effective for read access control;
you should only grant read access to a namespace to clients that you
would trust with read access to the entire repository.
It then goes on to explain the kinds of approaches that can be used to
exploit this, but basically, if an attacker can find an object ID that
it thinks the server has, it can acquire information about that object.
Now, you might say, well, the object ID is private. But it's very
common to leak those in issues, build logs, or as part of a version
identified in a build, so in general we can't base security on that.
Cryptography tells us that cryptographic hashes of general data are not
secrets, so we cannot rely on them for access control.
It could be possible to allow this _if_ Git had some way to know that
the client was only allowed to access certain refs _and_ Git were
configured to only allow access to objects that were reachable from
those refs. However, Git doesn't have that information and that's in
general expensive to determine, so it would make things like partial
clone perform really terribly. It would also require a lot of changes
to Git's internals and security model, and nobody has so far volunteered
to do that.
I will note that in general, secrets should never be checked into a
repository. It's too easy to accidentally expose a repository, and when
that happens, you leak every secret in the entire history, and then
rotating them all is a colossal hassle. (I know, I've had to do it.) If
you use a secret store, which is a security best practice, then this
doesn't happen.
--
brian m. carlson (they/them)
Toronto, Ontario, CA
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
next prev parent reply other threads:[~2025-09-11 0:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-10 23:28 Git private branch Feature Suggestion ynckz
2025-09-10 23:54 ` rsbecker
2025-09-11 0:00 ` brian m. carlson [this message]
2025-09-11 0:13 ` Henrique Soares
2025-09-11 8:15 ` Kristoffer Haugsbakk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aMIRO83CyG_qtKez@fruit.crustytoothpaste.net \
--to=sandals@crustytoothpaste$(echo .)net \
--cc=git@vger$(echo .)kernel.org \
--cc=yanckezcs@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox