Hacker News Reader

Comment by gnaffle | Hacker News Reader

> You grant that permission to the person legitimately checking out code, but not to the person finding or stealing a laptop with a clone of a repository. The latter is a side-effect of how a DVCS works.

I'm not sure what you're getting at. What difference is there (not that you would allow checkouts on unencrypted laptops anyway)?

> In SVN you don't even need to expose the full history, you can grant access to the last revision only.

> In SVN for example you can restrict people to single directories (or even files - I don't remember exactly). That at least is impossible in git. I can prevent pushes using hooks but not reads.

These restrictions may be useful in some cases, but I would wager that they are far more seldom than some of the advantages of git (like being able to work offline).

View on HN

> I'm not sure what you're getting at. What difference is there

A checkout from SVN/CVS only contains the last version. Files that were deleted in an earlier version are only on the server. A clone of a DVCS contains all versions and all files that ever were in the repo (unless you use BFG or git-filter-branch, but people tend to forget that). So a clone can contain secrets that people are not aware of, such as accidentally committed and deleted files. An interested party could find stuff that you're not aware off by looking at HEAD.

> (not that you would allow checkouts on unencrypted laptops anyway)?

That's not my call to make, but I agree on that regard. Reality sadly different from what we both wish.

> An interested party could find stuff that you're not aware off by looking at HEAD.

Well, that goes without saying. But I don't think that security argument is a very poor one compared to the huge benefit of having the history locally to inspect.

We've had instances where secrets were committed to local repositories by accident. It never got past review and into the master branch. If it had, we would probably had taken the effort to rewrite that commit out of the history.

> Well, that goes without saying. But I don't think that security argument is a very poor one compared to the huge benefit of having the history locally to inspect.

If you go further upthread you'll find that I said "a valid tradeoff, but one I'd keep in mind"

> We've had instances where secrets were committed to local repositories by accident.

That's laudable, but countless examples show that not everyone is that diligent. I'd love if I could lock down some parts of some repos so that they're only accessible by people that I have an elevated level of trust in. (and where I can enforce a certain security level on the laptop).

> That's laudable, but countless examples show that not everyone is that diligent.

Sure, then again I would guess that the ones who are not that diligent are not likely to apply those access restrictions that you mention (although the "one revision" advantage is something they would get "for free" with SVN).

In any given larger organization there are people that have exert control over only parts of the whole. I could possibly argue to tighten down security on parts of a repository for some people within boundaries (like declare some folders as unreadable to some folks that don't need access to those) but I can't deny them all access since they need some of the content stored in the repo. With git that's currently all or nothing which exposes a flank that I'd prefer closed. In this particular case it's not a terrible issue, but for other folks with other data that can quite well be, so the tradeoffs may end up being in favor of SVN. I can imagine that that's one of the reasons I still see SVN deployed in corporate installations.

Reply on news.ycombinator.com