Jeff King writes:
> So I think the in-between answer is "it is OK to push to an
> untrustworthy place, but do not do it from a repo that may contain
> secret contents".
Yes, that sounds like a sensible piece of advice to give to the
readers.
On Mon, 2016-11-14 at 11:00 -0800, Junio C Hamano wrote:
> Matt McCutchen writes:
>
> >
> > >
> > > Yup, and then "do not push to untrustworthy place without
> > > checking
> > > what you are pushing", too?
> >
> > If there is no private data in the repository, then there is no
> > need
> > fo
On Mon, Nov 14, 2016 at 11:00:04AM -0800, Junio C Hamano wrote:
> Matt McCutchen writes:
>
> >> Yup, and then "do not push to untrustworthy place without checking
> >> what you are pushing", too?
> >
> > If there is no private data in the repository, then there is no need
> > for the user to che
Matt McCutchen writes:
>> Yup, and then "do not push to untrustworthy place without checking
>> what you are pushing", too?
>
> If there is no private data in the repository, then there is no need
> for the user to check what they are pushing. As I've indicated before,
> IMO manually checking eac
On Sun, 2016-11-13 at 18:57 -0800, Junio C Hamano wrote:
> Matt McCutchen writes:
>
> >
> > Documentation/fetch-push-security.txt | 9 +
>
> A new (consolidated) piece like this that can be included in
> multiple places is a good idea. I wonder if the original
> description in "namespa
Matt McCutchen writes:
> Documentation/fetch-push-security.txt | 9 +
A new (consolidated) piece like this that can be included in
multiple places is a good idea. I wonder if the original
description in "namespaces" thing can be moved here and then
"namespaces" page can be made to also
A malicious server may be able to use the fetch and push protocols to
steal data from a user's repository that the user did not intend to
share, via attacks similar to those described in the gitnamespaces(7)
man page. Mention this in the git-fetch(1), git-pull(1), and git-push(1)
man pages and reco
7 matches
Mail list logo
