foundation for 'trust' model #386

Byron · 2022-04-15T04:40:33Z

See https://github.com/libgit2/libgit2/releases/tag/v1.4.3 and https://github.blog/2022-04-12-git-security-vulnerability-announced/

Tasks

a shared trust model via git-sec
a way to figure out if a path is owned by the process user
- get it to work [Cry for help by gitoxide]: Why can this code not determine that the file it just created is indeed owned by it? microsoft/windows-rs#1697
~~crates that launch external applications use trust model to potentially deny running binaries~~
- This will happen once the credentials helper is needed via git-repository, which happens when cloning is integrated and moves from gitoxide-core into git-repository
make trust configuration available in git-repository open and discover

It will hold the current credentials helper implementation and might contain more one day. Primarily meant to interface with `git-sec` when needed, even though currently it deals with git directly.

Otherwise we wouldn't know if the dependency resolution breaks.

It's shared across crates.

…d `identity::UserId` (#386) As the fewest consumers will be able to deal with multiple identities, remove the enumeration approach in favor of individual type which deal with one specific way of identifying a user.

For posterity, using the windows API is absolutely terrible and I hope I don't have to do it again anytime soon. More importantly, I hope that it works nonetheless.

Inspired by this suggestion. microsoft/windows-rs#1697

…386)

Is it desirable have permissions tagged like this? These would typically show up in options, and I have a feeling it makes them more descriptive. That's all really.

…ory (#386) There is also the notion of a 'main' worktree, the one we usually get when cloning non-bare. And we can currently instantiate a Repository from a worktree that isn't the main one.

Hence, when opening a repository permissions are already derived from Trust, and next up is to figure out how to get there so that open/discover can decide what to do while being configurable in full.

…ion failure. (#386) Evidence from CI suggests that on windows 'AlreadyExists' isn't the common error code. Instead, maybe due to racyness, it can also emit PermissionDenied errors which we now handle specifically.

…#386)

That way it's possible to ignore repositories which effectively aren't owned by the current user, or to not ignore them (default) but assign tigher permissions to the repository.

It should be possible to control which configuration files are loaded and contribute to the overall configuration. This goes along with at some point allowing to obtain only values which are from trusted configuration files, based on the trust specification passed when loading the configuration.

Thanks microsoft/windows-rs#1697 (comment) for figuring this out.

Byron added 18 commits April 15, 2022 12:39

An empty crate for git-sec (#386)

96a922c

Release git-sec v0.0.0

07efb6f

add frame for git-credentials crate (#386)

be7a9cf

It will hold the current credentials helper implementation and might contain more one day. Primarily meant to interface with `git-sec` when needed, even though currently it deals with git directly.

Release git-credentials v0.0.0

7db45ab

force re-installing from crates.io (#386)

670fb9b

Otherwise we wouldn't know if the dependency resolution breaks.

fill git-credentials with existing impleemntation (#386)

6016c22

better package size display; add new crates to size-check (#386)

0dfbeea

reduce API surface (#386)

6df2881

feat: add Identity type (#386)

cdf3c3e

feat: use git-sec::Identity type (#386)

3d339d5

It's shared across crates.

feat!: use git-credentials in git-protocol (#386)

32dc182

fix installation test on windows (#386)

5cf8c27

change!: remove Identity in favor of identity::Account module; ad…

37a607d

…d `identity::UserId` (#386) As the fewest consumers will be able to deal with multiple identities, remove the enumeration approach in favor of individual type which deal with one specific way of identifying a user.

adapt to changes in git-sec (#386)

c5e2346

feat: obtain identities from_path() or from_process() (#386)

f607797

refactor (#386)

a58d2cf

refactor so that the windows implementation can happen (#386)

7bbe44c

For posterity, using the windows API is absolutely terrible and I hope I don't have to do it again anytime soon. More importantly, I hope that it works nonetheless.

turn on fast windows testing of git-sec for now (#386)

d6c6ec6

Byron added a commit that referenced this pull request Apr 15, 2022

see if this makes a difference on windows (#386)

0173b44

Byron added a commit that referenced this pull request Apr 15, 2022

see if this makes a difference on windows (#386)

11be325

Byron force-pushed the git-sec branch from 0173b44 to 11be325 Compare April 15, 2022 12:19

Byron added a commit that referenced this pull request Apr 15, 2022

see if this makes a difference on windows (#386)

0e2f1df

Byron force-pushed the git-sec branch from 11be325 to 0e2f1df Compare April 15, 2022 12:30

Byron added a commit that referenced this pull request Apr 15, 2022

see if this makes a difference on windows (#386)

467e146

Byron force-pushed the git-sec branch from 0e2f1df to 467e146 Compare April 15, 2022 12:49

Byron added a commit that referenced this pull request Apr 15, 2022

see if this makes a difference on windows (#386)

0387efc

Byron force-pushed the git-sec branch from 467e146 to 0387efc Compare April 15, 2022 13:03

Byron added a commit that referenced this pull request Apr 15, 2022

see if this makes a difference on windows (#386)

e91450b

Byron force-pushed the git-sec branch from 0387efc to e91450b Compare April 15, 2022 13:20

Byron added a commit that referenced this pull request Apr 15, 2022

see if this makes a difference on windows (#386)

ce6855c

Byron added a commit that referenced this pull request Apr 15, 2022

see if this makes a difference on windows (#386)

872c941

Byron force-pushed the git-sec branch from cdcf7b9 to 872c941 Compare April 15, 2022 13:58

Byron added a commit that referenced this pull request Apr 15, 2022

see if this makes a difference on windows (#386)

1fdf39f

Byron force-pushed the git-sec branch from 872c941 to 1fdf39f Compare April 15, 2022 14:13

Byron added a commit that referenced this pull request Apr 15, 2022

see if this makes a difference on windows (#386)

48f76cc

Byron force-pushed the git-sec branch from 1fdf39f to 48f76cc Compare April 15, 2022 14:24

see if this makes a difference on windows (#386)

0dac74e

Byron force-pushed the git-sec branch from 48f76cc to 0dac74e Compare April 15, 2022 14:32

Byron added a commit that referenced this pull request Apr 16, 2022

See if checking for membership instead works (#386)

ded5555

Inspired by this suggestion. microsoft/windows-rs#1697

See if checking for membership instead works (#386)

de5ff1b

Inspired by this suggestion. microsoft/windows-rs#1697

Byron force-pushed the git-sec branch from ded5555 to de5ff1b Compare April 16, 2022 00:17

Byron added 8 commits April 16, 2022 11:41

refactor (#386)

9a3f0ba

a sketch on how to deal with permissions for executables (#386)

c066069

more details for path permissions (#386)

ca26659

abstractions which should be powerful enough to handle our use-cases (#…

b0d06ca

…386)

refactor (#386)

0e74c71

fully typed access control with tagged permissions (#386)

a43e25b

Is it desirable have permissions tagged like this? These would typically show up in options, and I have a feeling it makes them more descriptive. That's all really.

don't assume repos with work-trees are non-bare; make git-sec manadat…

9c4516d

…ory (#386) There is also the notion of a 'main' worktree, the one we usually get when cloning non-bare. And we can currently instantiate a Repository from a worktree that isn't the main one.

A first PoC to show how the permissions model works in practice (#386)

67d5837

Hence, when opening a repository permissions are already derived from Trust, and next up is to figure out how to get there so that open/discover can decide what to do while being configurable in full.

Byron added 6 commits April 17, 2022 17:19

more expressive and fuiture-proof handling of git dir access controls (…

b1d319b

…#386)

change!: path::discover::existing() -> path::discover() (#386)

2e39b0e

refactor (#386)

b9e307b

change!: integrate trust model into repository discovery (#386)

80e8fd4

That way it's possible to ignore repositories which effectively aren't owned by the current user, or to not ignore them (default) but assign tigher permissions to the repository.

change!: simplify Permission type radically `(#386)

f00f4a4

Byron merged commit 2fe70f9 into main Apr 17, 2022

Byron deleted the git-sec branch April 18, 2022 02:40

Byron added a commit that referenced this pull request Apr 23, 2022

Use strict ownership semantics on windows as well (#386)

84023cb

Thanks microsoft/windows-rs#1697 (comment) for figuring this out.

EliahKagan mentioned this pull request Aug 29, 2024

Fix gix-sec check for administrators group folder ownership #1429

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

foundation for 'trust' model #386

foundation for 'trust' model #386

Byron commented Apr 15, 2022 •

edited

Loading

foundation for 'trust' model #386

foundation for 'trust' model #386

Conversation

Byron commented Apr 15, 2022 • edited Loading

Tasks

Byron commented Apr 15, 2022 •

edited

Loading