Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change example for the -F file uploading option #752

Closed
wants to merge 1 commit into from
Closed

Change example for the -F file uploading option #752

wants to merge 1 commit into from

Conversation

tbodt
Copy link
Contributor

@tbodt tbodt commented Apr 5, 2016

It's a very, very, very bad idea to upload your password file anywhere, especially over http. I know it's just an example, but we certainly don't want anyone copy-pasting it.

It's a very, very, very bad idea to upload your password file anywhere, especially over http. I know it's just an example, but we certainly don't want anyone copy-pasting it.
@bagder
Copy link
Member

bagder commented Apr 6, 2016

I'd hold back a bit on the "verys", since the /etc/password file doesn't contain any actual passwords in operating systems shipped during the last 20 years or so. The /etc/shadow that contains the password hashes was introduced in 1987(!).

If a user actually would be tricked by the curl man page to send his/hers actual passwords over HTTP to a remote server, that user won't be saved by this edit.

But okay. For the remote possibility that we someone would encourage silly behaviors with this example I don't mind changing it to something more benign. I would however prefer not to use a dot file and not a vimrc basically since it isn't a known file to many users. I'll instead modify your update to use an image file.

    Example: to send an image to a server, where 'profile' is the name of the
    form-field to which portrait.jpg will be the input:

    curl -F profile=@portrait.jpg https://example.com/upload.cgi

@deltaray
Copy link

deltaray commented Apr 6, 2016

Thanks to both of you. I noticed that mypasswd.com was registered possibly after this example was put into the man pages. I couldn't find the exact date as the repo logs don't go back that far. Had you ever had any encounters with the domain owner Griffin de Luce? Looks like he wasn't a contributor or anything and eventually lost interest in harvesting /etc/passwd files from this example. My guess is that very few people ever really ran this so the problem is minimal. But I'm glad its fixed.

BTW, putting encrypted hashes into /etc/shadow was still an option in some versions of Linux in the late 90s at least. I remember Red Hat Linux had an option for enabling it and the default was not to enable it. So there could have been some password hash leakage, albeit, a long time ago.

@bagder
Copy link
Member

bagder commented Apr 6, 2016

I honestly doubt anyone, ever, ran that command line verbatim. Well, until now when about 7 users had to try it out when they learned about this man page example.

I don't know Griffin and he/she has never been involved in the curl project as far as I can recall. I've never tried that command line myself and I've never visited that domain. I don't believe that the domain was registered or used because of that appearance in our docs.

@lock lock bot locked as resolved and limited conversation to collaborators Jan 19, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Development

Successfully merging this pull request may close these issues.

None yet

3 participants