Re: ctrl-z ignored by git; creates blobs from non-existent repos

[Crls <kaploceh@gmail.com>]

On Sun, Jan 15, 2023 at 10:45:19AM -0500, Theodore Ts'o wrote:
> On Fri, Jan 13, 2023 at 05:01:01PM -0500, Crls wrote:
> > Ctrl-Z is ignored by git; Git-clone injects blobs even with non-existent
> > repos
> > 
> > Steps to reproduce 1- git clone github whateverrepo/whatevernonexistentrepo
> > or 1- git clone gitlab whateverrepo/whatevernonexistentrepo 2= Git prompts
> > for a username
> 
> % git clone github whateverrepo/whatevernonexistentrepo
> fatal: repository 'github' does not exist
> 
> I think what you meant was:
> 
> % git clone https://github.com/whateverrepo/whatevernonexistentrepo
> Cloning into 'whatevernonexistentrepo'...
> Username for 'https://github.com': 
> 
Yes. That's what I meant… thank you. I was having a problem with the formatting while sending the message to the mailing list

Content-Policy reject msg: The message contains HTML subpart, therefore we consider it SPAM or Outlook Virus. TEXT/PLAIN is accepted.! BF:; S229631AbjAMVJQ (in reply to end of DATA command)


> > 3- Press Ctrl-Z to stop *git* from running either on the virtual console/tty
> > *git* automatically creates blobs with directories and disregards
> 
> So it's not that Control-Z is being ignored.  It's that by the time
> you see the prompt for "Username for 'https://github.com': ", the
> directories already exist.  Try looking at
> whatevernonexistentrepo/.git as soon as the prompt shows up.  You'll
> see that the .git directory has been greated.
> 
> Now, when you type ^Z, the git processes are stopped --- but the
> objects are created already.

The directories exist not because ^Z is used, but because by the time git-clone prompts for a username, git is already set on what to do next. Correct? in other words, the process is shoved down my throat. Or the user's throat in this case. Or going by another analogy, it certainly sounds as if I meant: «Git, please git-clone such and such repo, but let me fix just a typo on the repo name before submitting it, pretty please» and then Git replies: «too late for that chick-a-doodle» and there it goes. It injects blobs all over (well, not all over but on the dir specified).


> 
> Username for 'https://github.com': ^Z
> [1]+  Stopped                 git clone https://github.com/whateverrepo/whatevernonexistentrepo
> % ps aux | grep git
> tytso       5097  0.0  0.0   9736  4480 pts/0    T    10:41   0:00 git clone https://github.com/wha
> tytso       5098  0.0  0.0   9736  3992 pts/0    T    10:41   0:00 /usr/lib/git-core/git remote-htt
> tytso       5099  0.0  0.1 102332 16104 pts/0    T    10:41   0:00 /usr/lib/git-core/git-remote-htt
> tytso       5140  0.0  0.0   6332  2072 pts/0    S+   10:43   0:00 grep git
> 
> 
> The 'T' means that the processes are stopped.
> 
> > Expected: The same issue does not happen with other non-existent repos e.g.,
> > git clone git.zx2c4/ it returns the message of fatal repo not found
> 
> So what's going on is that github.com is not returning a non-existent
> repo error; it's prompting for a username/password, as _if_ the
> repository exists.  That's presumably to prevent disclosing
> information as to whether or not a private repository exists or not.

I agree with you there. Coincidentally speaking, why does a username warrants a prompt from git, is simply beyond me. I mean, that is certainly the more far-fetched reasoning of implementation I've read in a long long time.

Can you git-clone a user? What about the user's settings? What about the remainder its gpg tokens and so forth? In other words, if a user's repo is not found, why even prompting for a username? The latter, that is, the user's repo, is redundant,  when the prompt is clearly asking for a username, and not a repo.


> 
> Once the authentication fails, git will remove the partially created
> repro, so it's really not a problem in practice.
> 
> Cheers,
> 
> 						- Ted

Not true. Preventing the disclosure of information has nothing to do with the issue here. If anything seems clear to me, is that prompting for a username, does indeed disclose usernames, private, public and whatnot from either github or gitlab.

And Technically speaking, yes, I agree with you in that if ^Z main operation is to suspend the process, there's not much further ado. Right?

p.s

I consulted this issue with Thomas Dickey, before sending an email through this interface, and he acknowledges that the operation from git occurs before. Thus confirming some of your statements, and also… that by the time git exits and it's done with,  in whatever dir of my choosing, ^Z couldn't do anything else about it. But I beg to differ. While ^Z may not do anything about it, then git should instead. Or so I think.

running stty -a returns:

swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;

take care Ted

Carlos


-- 
Seems a computer engineer, a systems analyst, and a programmer were
driving down a mountain when the brakes gave out.  They screamed down the
mountain, gaining speed, but finally managed to grind to a halt, more by
luck than anything else, just inches from a thousand foot drop to jagged
rocks.  They all got out of the car:
        The computer engineer said, "I think I can fix it."
        The systems analyst said, "No, no, I think we should take it
into town and have a specialist look at it."
        The programmer said, "OK, but first I think we should get back
in and see if it does it again."