Johannes,
Thanks for your feedback.
I'm not looking closely at submodules, as it's my understanding that
VFSForGit does not support them. A VFS would be a killer feature for us.
If VFSForGit were to support submodules, we'd look at them. They would
provide access control in a way that's
On Thu, Dec 6, 2018 at 12:09 PM Johannes Schindelin
wrote:
>
> Hi,
>
> On Wed, 5 Dec 2018, Jeff King wrote:
>
> > The model that fits more naturally with how Git is implemented would be
> > to use submodules. There you leak the hash of the commit from the
> > private submodule, but that's
Hi,
On Wed, 5 Dec 2018, Jeff King wrote:
> The model that fits more naturally with how Git is implemented would be
> to use submodules. There you leak the hash of the commit from the
> private submodule, but that's probably obscure enough (and if you're
> really worried, you can add a random
On Thu, Dec 06, 2018 at 10:17:24AM +0100, Ævar Arnfjörð Bjarmason wrote:
> > The other major user of that feature I can think of is LFS. There Git
> > ends up diffing the LFS pointers, not the big files. Which arguably is
> > the wrong thing (you'd prefer to see the actual file contents diffed),
On Thu, Dec 06 2018, Jeff King wrote:
> On Thu, Dec 06, 2018 at 10:08:57AM +0900, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > In my opinion this feature is so contrary to Git's general assumptions
>> > that it's likely to create a ton of information leaks of the supposedly
>> >
On Wed, Dec 05, 2018 at 11:42:09PM +, Coiner, John wrote:
> > For instance, Git is very eager to try to find delta-compression
> > opportunities between objects, even if they don't have any relationship
> > within the tree structure. So imagine I want to know the contents of
> > tree X. I
On Thu, Dec 06, 2018 at 10:08:57AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > In my opinion this feature is so contrary to Git's general assumptions
> > that it's likely to create a ton of information leaks of the supposedly
> > protected data.
> > ...
>
> Yup, with
Jeff King writes:
> In my opinion this feature is so contrary to Git's general assumptions
> that it's likely to create a ton of information leaks of the supposedly
> protected data.
> ...
Yup, with s/implemented/designed/, I agree all you said here
(snipped).
> Sorry I don't have a more
On Wed, Dec 05, 2018 at 04:01:05PM -0500, Jeff King wrote:
> You could work around that by teaching the server to refuse to use "X"
> in any way when the client does not have the right permissions. But:
>
> - that's just one example; there are probably a number of such leaks
>
> - you're
inline...
On 12/05/2018 04:12 PM, Ævar Arnfjörð Bjarmason wrote:
> On Wed, Dec 05 2018, Duy Nguyen wrote:
>
>>
>> Another option is builtin per-blob encryption (maybe with just
>> clean/smudge filter), then access control will be about obtaining the
>> decryption key (*) and we don't break object
On Wed, Dec 05 2018, Coiner, John wrote:
I forgot to mention this in my initial reply in
<878t13zp8y@evledraar.gmail.com>, but on a re-reading I re-spotted
this:
> - hashes are secret. If the hashes from a protected tree leak, the
> data also leaks. No check on the server prevents it
On Wed, Dec 05 2018, Duy Nguyen wrote:
> On Wed, Dec 5, 2018 at 9:46 PM Derrick Stolee wrote:
>> This directory-level security is not a goal for VFS for Git, and I don't
>> see itbecoming a priority as it breaks a number of design decisions we
>> made in our object storage and communication
On Wed, Dec 05, 2018 at 08:13:16PM +, Coiner, John wrote:
> One obstacle to moving AMD to git/VFSForGit is the lack of access
> control support in git. AMD has a lot of data whose distribution must be
> limited. Sometimes it's a legal requirement, eg. CPU core designs are
> covered by US
On Wed, Dec 5, 2018 at 9:46 PM Derrick Stolee wrote:
> This directory-level security is not a goal for VFS for Git, and I don't
> see itbecoming a priority as it breaks a number of design decisions we
> made in our object storage and communication models.
>
> The best I can think about when
On 12/5/2018 3:34 PM, Ævar Arnfjörð Bjarmason wrote:
On Wed, Dec 05 2018, Coiner, John wrote:
I'm an engineer with AMD. I'm looking at whether we could switch our
internal version control to a monorepo, possibly one based on git and
VFSForGit.
Has anyone looked at adding access control to
On Wed, Dec 05 2018, Coiner, John wrote:
> I'm an engineer with AMD. I'm looking at whether we could switch our
> internal version control to a monorepo, possibly one based on git and
> VFSForGit.
>
> One obstacle to moving AMD to git/VFSForGit is the lack of access
> control support in git.
Hi,
I'm an engineer with AMD. I'm looking at whether we could switch our
internal version control to a monorepo, possibly one based on git and
VFSForGit.
One obstacle to moving AMD to git/VFSForGit is the lack of access
control support in git. AMD has a lot of data whose distribution must be
17 matches
Mail list logo
